Need advice: Choice of environment for a new C/C++ project

[Beach Potato]

Dear Y'all:

I'm about to start porting a big old project written in anscient version
of Delphi to something more stable, robust, supportable and maybe even
portable. Since I haven't seriously touched C for large implementations,
I'm seeking advice on what to use for development.

My ultimate goal is to spend as less time on it as possible.
I'll be writing it in Windows 32-bit environment, probably Win2000 or
Win98. Planning to use a lot of scientific computation and a serious
presentation layer. I'll be very dependent on high speed of data output
and calculations as well. I already have GNU C++ & Visual C++ v6.0

So here's my questions:
1) Does it make sense to use C++ at all
2) Is there any good reason to resort to MFC as a fast code generator
3) What to do with memory management (it was plaguing me in the old
version). I'd be using a lot of dynamic memory allocations
4) If not MFC, then will I have to connect to all major GUI components
by hand, as I used to? Like in order to create a toolbar, status bar,
menus I would need to call Windows DLLs directly?
5) If not MFC, should I code everything from scratch, like a starting
application window, window classes, file classes or there's a better way
to do it
6) If making the application portable, what could I use for GUI in terms
of possibly reusing the code under Unix later
7) Can I use resources if I don't use MFC, and can I use resources if
I'm not on Windows
8) Which compiler/environment could be best to work with?

I'm much more interested in fast implementation & execution speed, than
in portability, which would be just a nice addition.

I'm sorry if some questions sound retarded, I've been off serious
desktop programming for a while.

Thanks in advance.

 

[Peter van Merkerk]

I'm about to start porting a big old project written in anscient
version

of Delphi to something more stable, robust, supportable and maybe even
portable.
Since I haven't seriously touched C for large implementations,
I'm seeking advice on what to use for development.

You have to decide whether you want to use C or C++. These are two
different languages.

My ultimate goal is to spend as less time on it as possible.
I'll be writing it in Windows 32-bit environment, probably Win2000 or
Win98. Planning to use a lot of scientific computation and a serious
presentation layer. I'll be very dependent on high speed of data output
and calculations as well. I already have GNU C++ & Visual C++ v6.0

So here's my questions:
1) Does it make sense to use C++ at all
Possibly.

2) Is there any good reason to resort to MFC as a fast code generator

No. Making GUI's with MFC isn't as easy as productive as with
Delphi/VCL, though Visual C++'s classwizards do help.

3) What to do with memory management (it was plaguing me in the old
version). I'd be using a lot of dynamic memory allocations

Carefully consider ownership issues and use smart pointers. If this is
to difficult for you may have to resort to a language with garbage
collection (e.g. Java, C#...)

4) If not MFC, then will I have to connect to all major GUI components
by hand, as I used to? Like in order to create a toolbar, status bar,
menus I would need to call Windows DLLs directly?

No, Visual C++'s has classwizards for that, but it is not as easy as in
Delphi.

5) If not MFC, should I code everything from scratch, like a starting
application window, window classes, file classes or there's a better way
to do it

No, Visual C++'s classwizards can do that for you. However you will
still have to understand what those classwizards do for you.

6) If making the application portable, what could I use for GUI in terms
of possibly reusing the code under Unix later

If you want your application to be portable, the first thing I would do
is to separate UI code from non-UI code (the code that does the actual
computing), so that the non-UI code is independant from the UI code.

Secondly you might want to use a platform independant GUI toolkit such
as Qt (www.trolltech.com) or wxWindows (www.wxwindows.org).

7) Can I use resources if I don't use MFC, and can I use resources if
I'm not on Windows

I'm assuming you are talking about resouce files. Those are MS-Windows
specific. Some GUI toolkits do have their own version of those "resouce
files"

8) Which compiler/environment could be best to work with?

Depends on your requirements and preferences.

One of the biggest problems with MS Visual C++ 6.0 is its poor standards
compliance. Version 7.1 of this compiler has improved a lot in this
area. If you intent to use the MFC library, MS Visual C++ is the best
choice. If execution speed is a big concern you may also want to look
for the latest version of the Intel C++ compiler. It is available as a
plugin for the MS Visual C++ environment, and has good standards
compliance. You have to be willing to spend some money on it though.

The latest versions of GNU compiler (I believe the lastest version is
3.3) are pretty good. There is also IDE's for this compiler like DevCPP
(http://www.bloodshed.net/devcpp.html ). For GUI development this
environment is somewhat less productive, and you probably want to use a
separate tool for this.

Porting Delphi code to C++ would is easiest with Borland C++ Builder 5,
as it supports the VCL library. For GUI development it is one of the
most productive C++ environments I know. However using the VCL library
also makes the code highly unportable, since it requires Borland
specific extentions to the C++ language. Also the future of VCL with
Borland products is uncertain. The standards compliance of BCB5 is
better than MS Visual C++ 6.0, but not as good as the other compilers I
mentioned. An other problem I have with BCB is its IDE, it is very
unstable especially when working with large projects. Sometimes it even
crashes with an eccess violation when starting up. Projects that take
longer than about 2 minutes to build, cannot be build reliably because
it tends to crash before the build finishes. Also its debugger has the
nasty tendancy to get out of sync with the source code and has several
other issues.

I'm much more interested in fast implementation & execution speed, than
in portability, which would be just a nice addition.

If execution speed is important for you C++ is a good choice. As far as
implementation speed it depends. If you separate the UI code from the
non-UI code, you have also have the option to write the UI code in a
different than the non-UI code which really relies on the execution
speed. For UI code execution speed is usually not a major concern, so
other language which may be not as fast but with better support for GUI
stuff and can be bind to C++ code may be an alternative.

 

[llewelly]

Projects that take
longer than about 2 minutes to build, cannot be build reliably because
it tends to crash before the build finishes.

[snip]

What?!? Are you sure this is true? If it is true, how can anyone
contemplate using such a compiler for a large project?

 

[Peter van Merkerk]

[snip]

Projects that take
longer than about 2 minutes to build, cannot be build reliably because
it tends to crash before the build finishes.

[snip]

What?!? Are you sure this is true? If it is true, how can anyone
contemplate using such a compiler for a large project?

Yes, me and my colleagues have run into this problem many, many times on
many, many different PC's and OS versions.

Note that the Borland compiler itself is not the problem, you can build
large projects (that take two hours to build) without problems outside the
IDE. It is just the IDE itself that is very unstable and buggy. Sometimes
when you build from the IDE you get suddenly all kinds of compiler errors
that suggest there is something terribly wrong with your code. If you
restart the IDE and try to compile the same code again the errors are
suddenly gone. Unfortunately for some things like GUI building and debugging
you need the IDE.

I think it is funny that the part you can download for free (the command
line compiler) is actually quite good, and that the part you pay for (the
IDE) is at best alpha version quality.

 

[Agent Mulder]

Unfortunately for some things like GUI building and debugging
you need the IDE.

</Peter van Merkerk>

GUI building is possible without IDE. Not in Delphi perhaps, with
funny files all over, but it is fun to program Windows with C++ from
vi. And debugging, I never did it since debug.com. Perhaps someone
can advise me on a command line debugger?

-X

 

[llewelly]

[snip]

Projects that take
longer than about 2 minutes to build, cannot be build reliably because
it tends to crash before the build finishes.

[snip]

What?!? Are you sure this is true? If it is true, how can anyone
contemplate using such a compiler for a large project?

Yes, me and my colleagues have run into this problem many, many times on
many, many different PC's and OS versions.

Note that the Borland compiler itself is not the problem, you can build
large projects (that take two hours to build) without problems outside the
IDE. It is just the IDE itself that is very unstable and buggy.

Ok. Thank you. I was sure there was some aspect I didn't
understand. As long as the compiler can be made to work apart from
the IDE, any competent programmer can find a quality alternative
code editor.

Sometimes
when you build from the IDE you get suddenly all kinds of compiler errors
that suggest there is something terribly wrong with your code. If you
restart the IDE and try to compile the same code again the errors are
suddenly gone. Unfortunately for some things like GUI building

The gui should be seperate from the rest of the code anyway.

and debugging
you need the IDE.

You can replace debugging with code review. You can also replace it
with tracing logging statements.

I think it is funny that the part you can download for free (the command
line compiler) is actually quite good, and that the part you pay for (the
IDE) is at best alpha version quality.

 

[Peter van Merkerk]

</Peter van Merkerk>

GUI building is possible without IDE. Not in Delphi perhaps, with
funny files all over, but it is fun to program Windows with C++ from
vi.

It maybe fun (for awhile) but not very productive. Though theoretically one
could make GUI's with just notepad (even with Borland VCL), it is not very
practical; just like it is possible but not very practical to create
executables with just a hex editor. And in spite of all of its failings
building non-trivial GUI's with the Borland IDE is still at least an order
of a magnitude faster than doing it all manually.

And debugging, I never did it since debug.com. Perhaps someone
can advise me on a command line debugger?

Depends on which compiler you are using, just about every compiler uses its
own debug file format. If it is GCC, you could use GDB. And when you get
tired of the command line, there are also great UI front-ends for GDB like
Insight and DDD.

 

[Peter van Merkerk]

[snip]

Projects that take
longer than about 2 minutes to build, cannot be build reliably because
it tends to crash before the build finishes.
[snip]

What?!? Are you sure this is true? If it is true, how can anyone
contemplate using such a compiler for a large project?

Yes, me and my colleagues have run into this problem many, many times on
many, many different PC's and OS versions.

Note that the Borland compiler itself is not the problem, you can build
large projects (that take two hours to build) without problems outside the
IDE. It is just the IDE itself that is very unstable and buggy.

Ok. Thank you. I was sure there was some aspect I didn't
understand. As long as the compiler can be made to work apart from
the IDE, any competent programmer can find a quality alternative
code editor.

The editor is not that important as can be easilly replaced, it is the build
environment that counts. For large scale projects a build environment that
operates independant from IDE's is a requirement anyway. But IMHO it should
be possible to build small to medium scale from the IDE. If not what is the
point of having an IDE?

The gui should be seperate from the rest of the code anyway.

Yes, but if you invest in a GUI building environment it is nice if you can
use it too.

You can replace debugging with code review. You can also replace it
with tracing logging statements.

That is a bit like saying we don't need cars because we can walk too. Code
reviews may reduce the need for debugging, but do not completely eliminate
it. Even if you have the same code reviewed by five different people and run
it through pclint, you sometimes still need to debug to see what is really
going on. One reason is that (third party) libraries not always do what they
say they do. Trace logging (as replacement for a debugger) is often
impractical, too time consuming and too limited in a production environment.

 

[nahpets]

[snip]

Projects that take
longer than about 2 minutes to build, cannot be build reliably because
it tends to crash before the build finishes.

[snip]

What?!? Are you sure this is true? If it is true, how can anyone
contemplate using such a compiler for a large project?

Yes, me and my colleagues have run into this problem many, many times on
many, many different PC's and OS versions.

Note that the Borland compiler itself is not the problem, you can build
large projects (that take two hours to build) without problems outside the
IDE. It is just the IDE itself that is very unstable and buggy. Sometimes
when you build from the IDE you get suddenly all kinds of compiler errors
that suggest there is something terribly wrong with your code. If you
restart the IDE and try to compile the same code again the errors are
suddenly gone. Unfortunately for some things like GUI building and
debugging you need the IDE.

I think it is funny that the part you can download for free (the command
line compiler) is actually quite good, and that the part you pay for (the
IDE) is at best alpha version quality.

Just a suggestion for your GUI interface. I've used JAVA to create my GUI
and the Java Native Interface (JNI) to connect to my C/C++ backend. I find
GUI building with Java to be very easy (especially if you use an IDE like
JBuilder/Netbeans/Forte). An added benefit is that your GUI will also be
portable...

Stephan

 

[llewelly]

[snip]
Projects that take
longer than about 2 minutes to build, cannot be build reliably because
it tends to crash before the build finishes.
[snip]

What?!? Are you sure this is true? If it is true, how can anyone
contemplate using such a compiler for a large project?

Yes, me and my colleagues have run into this problem many, many times on
many, many different PC's and OS versions.

Note that the Borland compiler itself is not the problem, you can build
large projects (that take two hours to build) without problems outside the
IDE. It is just the IDE itself that is very unstable and buggy.

Ok. Thank you. I was sure there was some aspect I didn't
understand. As long as the compiler can be made to work apart from
the IDE, any competent programmer can find a quality alternative
code editor.

The editor is not that important as can be easily replaced, it is the build
environment that counts. For large scale projects a build environment that
operates independant from IDE's is a requirement anyway. But IMHO it should
be possible to build small to medium scale from the IDE. If not what is the
point of having an IDE?

I do not know that there is any point to an IDE. Many good independent
code editors I know of can launch builds, interact with version
control repositories, debuggers, etc. But I do agree that the
problem you describe is serious one - were I choosing to buy or
reccomend a new set of tools, it would weigh heavily against
borland.

Yes, but if you invest in a GUI building environment it is nice if you can
use it too.

Here I was being somewhat sarcastic. Seperating the gui code would
help, I think, but probably not a lot. I've used gui tools that
crash several times a day (note, not borland's, but in-house gui
building tools), and I quickly find myself wishing I'd never used
them.

That is a bit like saying we don't need cars because we can walk
too.

[snip]

I was being a little sarcastic. Not completely sarcastic; I've worked
on large projects entirely without debuggers, and I've found I'm
more productive if I review code before starting the debugger.

 

[Simon Turner]

Just a suggestion for your GUI interface. I've used JAVA to create my GUI
and the Java Native Interface (JNI) to connect to my C/C++ backend. I find
GUI building with Java to be very easy (especially if you use an IDE like
JBuilder/Netbeans/Forte). An added benefit is that your GUI will also be
portable...

You can also build (more or less) portable GUIs in native C++ using toolkits
like wxWindows or Qt.

http://www.wxwindows.org/
http://www.trolltech.com/products/qt/index.html

AFAIK, wxWindows is entirely free, although it looks like you can pay for
support if you want it. Qt used to be free for non-commercial use on Unix/Linux
IIRC, but I couldn't tell if it still is. I've used (and largely liked) Qt, and
heard good things from others about both that and wxWindows.

Stephan

Simon.