C++ IDE with graphical application building and good portability

[Linonut]

* James Kanze peremptorily fired off this memo:

I've used Rose to generate code in some projects. I find that
I'm a lot more productive using it that writing my headers by
hand.

Well, based on what I've seen from other developers, they will then
not write complete comments, nor will they leave the code in
a nicely-formatted state.

If you can't do a seamless round trip, I'd rather refine the code
by editing and then regenerated the diagrams.

The point of class diagrams (and requirements specifications,
and a lot of other documentation) is to define what you are
going to write in the code. I'm very sceptical of people who
code first, and write the documentation later. I've seen a lot
of code developed that way, and it's always pretty bad.

Only for larger projects. Smaller projects don't need the overhead
UML.

Obviously, you need a specialized tool. Because I've usually
started with class diagrams, I've not been able to experiment
with CWeb, but I think some combination of CWeb, embedded in
Rose, would be just about perfect.

We call it "Crational" around here. Even Rose. I'm finding umbrello to
be reasonable.

I still don't think UML is up to the task of generating code. And you
have to become an expert in the UML process to actually create a real
design that will result in compilable and working code.

What I find works best for me is to do a lot of the skeletal header
files up front, until I start to lose the picture of their
relationships. Then I reverse engineer, find the obvious flaws, then
continue coding, then reverse engineer again.

It's too bad there isn't a diagramming tool that will make only
/incremental/ changes to your code, preserving the rest of the
documentation and code without the need to use arcane markup.

Maybe a method where each item is a database entry in a relational
database, and you edit the items, and then can assemble them into
code that you examine, compile, and then throw away until the next round
of database updates.

There's a similar problem with requirements. How does Rational handle
it? With a stinking-awful Microsoft Word-based user interface.

 

[James Kanze]

* James Kanze peremptorily fired off this memo:

Well, based on what I've seen from other developers, they will then
not write complete comments, nor will they leave the code in
a nicely-formatted state.

That's more or less my point. I've had no problems with the
formatting of the code, but they don't integrate seemlessly a
good text editor, for the textual parts of the design. Still,
I'm significantly more productive with Rose than with any of the
alternatives I've tried.

If you can't do a seamless round trip, I'd rather refine the
code by editing and then regenerate the diagrams.

You do the diagrams first, regardless.

Only for larger projects. Smaller projects don't need the overhead
UML.

It's not really overhead. Do the UML first, and you're more
productive.

Of course, there is a break-even point---I don't bother with UML
(or C++, for that matter) for things less than about 500 lines
of code. I'll just bang it into shell script and awk, without
really much design up front.

We call it "Crational" around here. Even Rose. I'm finding
umbrello to be reasonable.

Rose is really the only such tool I've used to any extent. (I
did try Together a little---it has some nice points as well, but
it doesn't seem to work well in my environment---a very small,
very slow Sparc, with not very much memory.)

I still don't think UML is up to the task of generating code.
And you have to become an expert in the UML process to
actually create a real design that will result in compilable
and working code.

As I said, I've used Rose for code generation in several
projects. Including one very small one (about 50 KLOC). It's
always resulted in significantly improved productivity.

What I find works best for me is to do a lot of the skeletal
header files up front, until I start to lose the picture of
their relationships. Then I reverse engineer, find the
obvious flaws, then continue coding, then reverse engineer
again.

How do you know what classes you're going to need, if you
haven't done a few class diagrams, scenarios, etc.? (I find
scenarios particularly useful in the early stages of design.
But I think part of what I use them for might better be handled
with CRC cards.)

It's too bad there isn't a diagramming tool that will make
only /incremental/ changes to your code, preserving the rest
of the documentation and code without the need to use arcane
markup.

I'm not sure what your problem here is. Rose separates the code
fairly cleaning into the part it maintains, and the part you
maintain. It never modifies the part you maintain.

As for the mark-up---you want something, so you know what you
can modify, and what you can't (or if you prefer, what's yours,
and what's Rose's). The last time I used it, I set up the
editor (I was using emacs at the time) so that it displayed the
mark-up very discreetly, unlike normal comments. (I use a dark
green background: the Rose generated mark-up was dark-gray,
normal comments yellow.)

Maybe a method where each item is a database entry in a
relational database, and you edit the items, and then can
assemble them into code that you examine, compile, and then
throw away until the next round of database updates.

There's a similar problem with requirements. How does
Rational handle it? With a stinking-awful Microsoft
Word-based user interface.

We didn't handle requirements with Rose. On the last project I
used Rose on, they came from outside. In Word format (which
was a pain, because we didn't have any PC's in the development
group---just Sun Sparcs---and only had it in hard copy form).

But again, that's the weakness I've been talking about:
integration of text and diagrams.

 

[Nick Keighley]

Lars Uffmann <[email protected]> wrote in comp.lang.c++:

First of all, an IDE for programming in C++. I wholeheartedly recommend
"Dev-C++" by Bloodshed. You can get it for Windows and for Linux, (and
probably for other OS's too). It uses gcc and g++ by default. I've been
using it for years, even before I dabbled in cross-platform.

maybe I was unlucky. But
- the debugger works, sometimes
- it's picky where you install it
- the IDE is pretty clunky looking


<snip>

Visual C++ (Express) 2008 is free and detects more problems.

 

[Nick Keighley]

"Ole Nielsby" <[email protected]>
wrote:>Lars Uffmann <[email protected]> wrote:

    [...]

My 2 cents: If you have a small application without a lot of
classes, you don't want these guis. You probably don't need a
gui. A decent text editor and command line builds are better.
If you have a large application and lots of classes, a gui is
useful. Expect some headaches. You may be better off with the
gui as a text editor and building/debugging with the command
line tools.

For editing code (or text documentation), a classical editor is
probably the ideal tool.  

classical? vi?

these things are a matter of perference but graphical
editors can be nice. I use ConText.

For building, you need a command line
interface anyway---
why?

you'll want to trigger your complete rebuilds
at a time when no one is using the system.

I can do this with a gui

 For anything but the
smallest project, however, you'll really want some graphical
documentation---things like class diagrams, etc.  And that
supposed some sort of graphic tool.

yes

 

[Nick Keighley]

I've used Rose to generate code in some projects.  I find that
I'm a lot more productive using it that writing my headers by
hand.

but sometimes it's a pain.

- no! no! I don't want a cpp file".
- no, I don't want all the setters and getters generated automatically
- nor do I want all the setters to return a reference
- is it *really* quicker to dig though 3 or 4 dialog boxes,
find the obscure setting (maybe have to read the help)
just to make a method const? I only have to type 5 characters to
do it in c++!

yes you can do these things, but is it easy?

<snip>

when I'm not forced to use Rose. I write the header first.
Then copy it into the cpp file and hack in the code.
The cpp and h files automatically match.

I have a large Rose model (legacy code). But if I want
to find something I search for it in STI's Understand for C++.
Understand is far easier to jump around in than Rose's UML.
Maybe its a bad model.

 

[Nick Keighley]

On 2008-01-13 07:44, EricF wrote:

[...] getting a console project setup is not intuitive. I find that
most things work fine, but then I run into a usability issue.

I usually create an empty console application and that works fine. Of
course there are a number of compiler settings that have to be changed
but you run into that with any compiler that I know of.

Yes, the empty console app is the key. I made the mistake of letting the
wizard set up the console project, naively assuming a wizard would set it up
right. After doing that, it was impossible to compile without including some
ms specific header. :-(

"beware of wizards, for they are subtle and quick to anger"

"meddle not in the affairs of wizards"

 

[Paul M. Dubuc]

The point of class diagrams (and requirements specifications,
and a lot of other documentation) is to define what you are
going to write in the code. I'm very sceptical of people who
code first, and write the documentation later. I've seen a lot
of code developed that way, and it's always pretty bad.

But at least the documentation tends to be more accurate.

 

[Linonut]

* James Kanze peremptorily fired off this memo:

You do the diagrams first, regardless.

Sorry dude, although our process calls for diagrams/design first, I
personally use code as they way to get a jumpstart on the diagrams.

Anyway, I think the whole Rational thing is a bit of a sinkhole, and I
have trouble understand how it was desirable enough to support the huge
cost. Rose is the best tool of the bunch in the "Suite", but it is
still buggy in the version we have.

It's not really overhead. Do the UML first, and you're more
productive.

Of course, there is a break-even point---I don't bother with UML
(or C++, for that matter) for things less than about 500 lines
of code. I'll just bang it into shell script and awk, without
really much design up front.

It really depends how your mind works.

Also, once the stuff gets out in the lab, you probably will find stuff
that was not thought of up front.

Rose is really the only such tool I've used to any extent. (I
did try Together a little---it has some nice points as well, but
it doesn't seem to work well in my environment---a very small,
very slow Sparc, with not very much memory.)

I haven't found the perfect one yet. I've tried Rose, umbrello, argouml
(Java based), and bouml (a one-man project, but not bad).

And they all generate a different flavor of UML XML.

How do you know what classes you're going to need, if you
haven't done a few class diagrams, scenarios, etc.? (I find
scenarios particularly useful in the early stages of design.
But I think part of what I use them for might better be handled
with CRC cards.)

Well, we do requirements, use-cases, etc. And a lot of the classes are
pretty obvious (at a high-level) based on what you need to do.

I just find the drawing is too slow, and I can't easily add comments.
When I feel I'm losing a grip on the design, then I'll reverse-engineer
it and use the diagrams to reorient.

I'm not sure what your problem here is. Rose separates the code
fairly cleaning into the part it maintains, and the part you
maintain. It never modifies the part you maintain.

Cool. Unfortunately, we don't have a Linux implementation, and probably
never will. Ironic, since the UNIX roots of Rational are so obvious.
The customer had this installation available, so we might as well use

As for the mark-up---you want something, so you know what you
can modify, and what you can't (or if you prefer, what's yours,
and what's Rose's). The last time I used it, I set up the
editor (I was using emacs at the time) so that it displayed the
mark-up very discreetly, unlike normal comments. (I use a dark
green background: the Rose generated mark-up was dark-gray,
normal comments yellow.)

I've gotten used to Doxygen markup. That's all the markup I care to
use. And, since Rose has the bugs, I just don't bother with it anymore.

We didn't handle requirements with Rose. On the last project I
used Rose on, they came from outside. In Word format (which
was a pain, because we didn't have any PC's in the development
group---just Sun Sparcs---and only had it in hard copy form).

Count your blessings. We have to open up a Word document to enter
requirements. And use special add-in menus to save it, or else the
document is corrupted. It's insane.

But again, that's the weakness I've been talking about:
integration of text and diagrams.

Which is why I tend to not rely on UML. It is helpful, but not a
panacea.

 

[Ian Collins]

Normally, that point is *before* you write the first line of
code. Typically, before you even decide on the name of the
class.

Don't get me going on that one!

I've used Rose to generate code in some projects. I find that
I'm a lot more productive using it that writing my headers by
hand.

I've found it more productive to use a small application maintained by
me or my team to generate boilerplate (on our case, class and unit test
header and cc files) and update project build and test files. That way
we get the exact formatting, copyright and stubs we want for a
particular project or client.

The point of class diagrams (and requirements specifications,
and a lot of other documentation) is to define what you are
going to write in the code. I'm very sceptical of people who
code first, and write the documentation later. I've seen a lot
of code developed that way, and it's always pretty bad.

Solve that problem by writing the two together.

Obviously, you need a specialized tool. Because I've usually
started with class diagrams, I've not been able to experiment
with CWeb, but I think some combination of CWeb, embedded in
Rose, would be just about perfect.

My first task in my last job was to review all of the tools available
and select one for my team. Rose would have been a good fit for the
given requirements, but the cost was prohibitive and we didn't like the
idea of having our process driven by a tool.

In the end I concluded that the best tool was no tool, spent the money
elsewhere and took the team on a most enjoyable and successful journey
into the land of Agile.