The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

The "best" C++ compiler/linker package

I mostly use Visual Basic to develop applications, but I am needing something that will produce smaller and hopefully faster code.  I have VC++ 6.0 that I got with Dev Studio but I am wondering what all of you think is the best "package" for making C/C++ applications under windows.  It will be either a DLL or console type application.  It is for backend database and network processing. A minimal interface is needed.

I would want one that has a good following so there is support (it doesnt have to be free) and improvements.

Obviously MS Visual C compilers have a huge user base and are supported by the giant Microsoft, but I have this concern that the code made with a MS compiler/linker will be bloated due to the "features" they include for ease of development.

Any thoughts or comments?
Nick Koranda Send private email
Tuesday, October 04, 2005
 
 
Visual C++ 6.0 is probably the "best".  Since it's made by Microsoft, and has that wonderful "MSDN" help, it's probably the most complete package out there.  I think even Microsoft uses it to build their own stuff.

Yes, with Microsoft you have that "undocumented feature" thing, which bites you every so often, but that's what after-market books are for.

And I'd LOVE to recommend Borland, but they've priced themselves out of my market, and I'm not convinced any of their products after Delphi 4 or C++ Builder 5 has been worth the money.

Now that Microsoft has gone off into .NET land, I don't know what their C++ 6.0 support looks like though.
AllanL5
Tuesday, October 04, 2005
 
 
Oh, and note that Visual Basic 6.0 already had improvements to produce small and fast code -- that 'native code' option.  Sure, VB loads every DLL in existence when it comes up (exaggeration), but your actual VB exe code is really small.

While you MAY be able to get an equivalent C++ program to run faster, that's only true if your program is processor bound (in other words, it doesn't put up lots of windows, instead it just crunches data in the background).
AllanL5
Tuesday, October 04, 2005
 
 
Umm -- and "backend Database and Network processing".  The speed of this is usually limited by how fast you can access the database, and access the network -- again, using C++ over VB in this case may not buy you much.

Except for that multi-threading thing that's very difficult to do in VB.  For Multi-threading you probably need C++.
AllanL5
Tuesday, October 04, 2005
 
 
Visual C++ 6.0 sucks.  Assuming you are interested in C++, you should probably go for an actual C++ compiler.  6.0 isn't, Visual C++ .Net2003, aka Visual C++ 7.1, is.  I have not yet tried the .Net2005 beta.

These days, most of my development is done with gcc but I still make extensive use of VC++7.1.
Chris in Edmonton Send private email
Tuesday, October 04, 2005
 
 
What Chris said. Many of the missing features, limitations and deviations from the standard in VC++ 6.0 are painful. I have not used VC++ 7.1 but I do hear it is much improved. Don't start out with VC++ 6.0 today; it is old and due for retirement.
Ian Boys Send private email
Tuesday, October 04, 2005
 
 
Besides, the 2003 MS C++ compiler can be had for free from their site.
Aaron F Stanton Send private email
Tuesday, October 04, 2005
 
 
Okay, so there IS a new release of Visual C++, they just don't call it that.  Fine.

But I still have to say the Microsoft product will be more 'in-tune' with Windows than some other vendor.  Though I certainly share your suspicions.
AllanL5
Tuesday, October 04, 2005
 
 
MS does call it Visual C++ - see http://msdn.microsoft.com/visualc/

As with (almost) all of their other development products, they're using the release year instead of a version number to market it. The version number is still shown by the command-line version of the compiler, however.

Getting a newer version of Visual C++ is a good thing. Some time after VC++ 6 was released, MS finally decided that ISO standards compliance (for C++) was a good thing and they've gonet from being one of the least compliant compilers to one of the most compliant.
RocketJeff Send private email
Tuesday, October 04, 2005
 
 
Aaron F Stanton Send private email
Tuesday, October 04, 2005
 
 
Aaron F Stanton Send private email
Tuesday, October 04, 2005
 
 
Yes I saw they had the free software on the site.  It is VC 7.1 beta 2.  They dont have a full release yet.

It states it is 98% ANSI C compliant  so that is a good thing as well.

It looks like I will take a look at that package.  Thanks.
Nick Koranda Send private email
Tuesday, October 04, 2005
 
 
Sorry, I should have said ISO C++ standard, not ANSI
Nick Koranda Send private email
Tuesday, October 04, 2005
 
 
Perhaps Intel's compiler (I tried it a few years ago, not more recently than that).
Christopher Wells Send private email
Tuesday, October 04, 2005
 
 
The 2003 toolkit is the same as 7.1 release.  The beta 2 is for VC 2005.  Not the same thing.
Aaron F Stanton Send private email
Tuesday, October 04, 2005
 
 
(VC 2005 is version 8.)
Aaron F Stanton Send private email
Tuesday, October 04, 2005
 
 
>> Sorry, I should have said ISO C++ standard, not ANSI

Well, your're actually right either way - ANSI is the US member of the ISO and, as a general rule, adopts the ISO standards without change.
RocketJeff Send private email
Tuesday, October 04, 2005
 
 
Going back to the original question: "concern that the code made with a MS compiler/linker will be bloated due to the "features" they include for ease of development"

This is not really a concern. You have a choice; build with full debug information and source browser files and get big disk usage and slower programs but ease of debugging; build in release mode with no debug info and code optimization and get fast, compact, but hard-to-debug code. In addition, many of the run-time libraries may be dynamically linked as DLLs so the executables can be even smaller.
Ian Boys Send private email
Tuesday, October 04, 2005
 
 
(But then you run into the issue of dll hell.)
Aaron F Stanton Send private email
Tuesday, October 04, 2005
 
 
I say "use the compiler which most other people use".

The reason is that it probably has the least bugs.



I'm using Visual C++ 6.0 because I hate the VS 7.1 IDE and the fact that it takes twice as long to compile anything.

The compiler isn't *that* non-compliant - not once you've taken ten minutes to replace atd::auto_ptr with an ISO version.
Joce
Tuesday, October 04, 2005
 
 
Oh? What's wrong with the VS 7.1 IDE then? I rather dislike the Visual Studio 6.0 IDE and was rather hoping I'd like the .NET style IDE better (I've not had much chance to try it out yet).
Ian Boys Send private email
Tuesday, October 04, 2005
 
 
You're kidding, right?

Visual C++ 6 can't even compile it's OWN implementation of STL without spitting back hundreds of errors.  I suppose VC++6 isn't bad if you stay away from STL (but then, why write in C++?) and from templates in any way, shape, or form.

Really, though, Visual C++ 6 was a good compiler for 1996 or 1997.  It was outdated by the end of 1998, though.  And yes, I'm aware when it was released.
Chris in Edmonton Send private email
Tuesday, October 04, 2005
 
 
> I suppose VC++6 isn't bad if you stay away from STL

If fact VC++6 works very well, provided you stay away from STL. The IDE is also a lot better.

> (but then, why write in C++?)

Because for someone who hates the though of using STL, 6.0 works just fine.

> and from templates in any way, shape, or form.

It has no problems with templates.
Jussi Jumppanen
Tuesday, October 04, 2005
 
 
> It (VC++ 6.0)has no problems with templates.

Oh yes it does. Explicit specialization, for example, can be problematic.
Ian Boys Send private email
Tuesday, October 04, 2005
 
 
VC++ doesn't support partial template specialization at all.
comp.lang.c refugee
Tuesday, October 04, 2005
 
 
Quote:

You have a choice; build with full debug information and source browser files and get big disk usage and slower programs but ease of debugging; build in release mode with no debug info and code optimization and get fast, compact, but hard-to-debug code.


A nice solution to that is to have both versions shipping (debug and release).  Then pick which one you want... release for normal stuff, debug for when you need the information.
Eric D. Burdo Send private email
Wednesday, October 05, 2005
 
 
Eh, atleast on VC++ 6.0(I haven't tried it on VC++ 7.1) the debug symbol can be dumped in a separate file it only adds a couple of kb overhead on your release and you can ship only the exe(with additional DLL:s) to customer.

http://www.cygnus-software.com/papers/release_debugging.html
Unemployed -> back to University.
Wednesday, October 05, 2005
 
 
If all you are interested in is console development I suggest you look at Borland's C++ compiler, which can be downloaded for free from their web site. In my opinion it has much better support for ANSI C++ and the STL than MS.

What does 98% compatible with the standard mean, anyways? Which 2% did they leave out?
A. Nonymous
Wednesday, October 05, 2005
 
 
As I understand it, the "2%" is the export keyword and separate template compilation.

Which, as I also understand it, is #1 on the ISO C++ committee's "Whoops, that doesn't work, does it?" list anyway.

Microsoft currently employs both Herb Sutter and Stan Lippman, the two biggest guys in C++ aside from Stroustrup himself. They're pretty serious about C++ and standards compliance.
Chris Tavares Send private email
Wednesday, October 05, 2005
 
 
I am not surprised that it doesn't support those two things - I don't think there's a single C++ compiler out there that does.  Feel free to correct me if I'm wrong.
Aaron F Stanton Send private email
Thursday, October 06, 2005
 
 
The Comeau compiler supports both.

Honestly though, as much as I love to bash MS I can't blame them for leaving export out. It clashes badly with the usual C++ compiler, and other than Comeau, I can't think of any vendors that have plans to implement it.
comp.lang.c refugee
Thursday, October 06, 2005
 
 
Wow.  I didn't know that.

I wonder how they do it?

Can their binaries link to anyone else's?
Aaron F Stanton Send private email
Thursday, October 06, 2005
 
 
"export"ing is a major thing in the embedded world.  Many embedded operating systems link by ordinal, and try to keep such tables as small as possible, for obvious constraint reasons.

It is also a really big win on the desktop, apparently:
http://www.nedprod.com/programs/gccvisibility.html
new nick, new rep
Friday, October 07, 2005
 
 
The visibility patch seems unrelated to the 'export' keyword, though I could be wrong.

The C/C++ Users Journal had a great article on the problems with the 'export' keyword and why it'll likely be dropped.  It turned out that not only was it breathtakingly hard to implement, it also fundamentally didn't accomplish what the people who proposed it expected it would.
Chris in Edmonton Send private email
Friday, October 07, 2005
 
 
I believe I've heard that VB.NET gives much better performance than VB 6.

Or just learn Ruby and do the whole thing in that.  CPU performance often doesn't matter that much.  The most popular programming language in the world is Javascript, and it has just lousy cpu performance.

Or you could just do it in C.  For fun, read up on Walter Bright's "D" programming language.  It sounds nice.
Warren Send private email
Sunday, October 23, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz