Slashdot Mirror

Waiting for approval is a valid point, but anyone who spent time using MFC probably has their own list of things that drive them bonkers, and most likely know where the fix needs to be. Screw approval, fix it in your code and ship the result linked statically.

No joke, even the C/C++ headers in MSVC 6 are broken, and due to licensing issues Microsoft can't release a patch for it. People just fix it locally and it's done. Of course, this is mostly STL, so it's not in the runtime DLL files so you could still dynamically link these updates.

http://www.dinkumware.com/vc_fixes.html

If you choose you can install the source code to the MFC library, and step through it like your own code. Just like you can go through the C/C++ runtimes. You're not supposed to fix and re-build it, they did not release the build/project files, only the code so the PDB files could tell the debugger where to look.

If you have spent time in MFC, you quickly learn that every other line of code is likely to have some quirk that you didn't expect. Adding simple overrides requires hacks on top of hacks. And you learn how it works, even if you don't install the code.

I left MFC a long time ago, but I guarantee I could find and fix one bug a day for the next week, maybe two, just based on working with it for maybe 5 years. On top of my normal workload, not just hacking away on bugs for 16 hours. Entire websites are dedicated to working around how MFC doesn't work like it should.

The Petzold equivalent book for MFC starts out with making an MFC app in notepad, no wizards or GUI. If you understand what you are writing, and what the wizard does for you, you can make your own workarounds. All it takes is having the code to see where it is screwing up what you did to it. "The time it takes to find the bug in a program you didn't write" is negligible compared to working around it every time you write a program that works around the same problem.

http://www.amazon.com/Programming-Windows-MFC-Second-Edition/dp/1572316950

cplusplus.com?

good lord no. use it for iostreams quick reference at most.

http://www2.roguewave.com/support/docs/sourcepro/edition9/html/stdlibref/index.html

http://www.dinkumware.com/manuals/Default.aspx?manual=compleat

note that dinkumware wrote much of msvc's c++ standard library.

http://www.gotw.ca/gotw/

http://www.faqs.org/faqs/C++-faq/

One thing I've noticed in the few years I've been using Ubuntu is that each release quietly fixes at least one major annoyance -- drivers, multimedia, configuration, etc. Since Ubuntu 8.04 will be released on April 22, you might try a clean install of that and see if it fixes some of your problems. If not, then I agree with the other commenter who recommended Ubuntu Forums.

Programming: It sounds like you're interested in lower-level systems programming. A good book is "Linux Application Development" by Michael K. Johnson and Eric W. Troan. Most of the GNU and Gnome stuff is actually done in C, not C++, and GNU offers a thorough tutorial on C for the uninitiated. For C++, if you're committed to learning it, try "Effective C++" and "More Effective C++"; bookmark the standard library reference, and -- I notice you haven't listed any object-oriented languages -- read the "Case Study" section of the book "Design Patterns". Another language that you may find more enjoyable, and which occurs pretty regularly in GNU/Linux and especially Ubuntu, is Python.

IDEs: Eclipse is popular. Anjuta is very Gnome-ish and forms a nice collection of all the various programming utilities (autotools, gettext, glade, lint, indent, ...) that are worth getting to know. I actually just use GVim and the command-line tools -- if you're used to mainframes, you might be happy with that already.

Partial implementation is available from Boost.
A commercial full implementation can be purchased from DinkumWare.

How many times have you heard the word "innovation" from a microsoftie?
(uncountable)

How much money does it spend on research?
http://it.slashdot.org/article.pl?sid=06/12/06/204 2218
http://www.networkworld.com/news/2006/120606-micro soft-research.html

How many times has it innovated?

http://www.dwheeler.com/innovation/microsoft.html
http://hea-www.harvard.edu/~fine/opinions/msinnova te.html
http://www.vcnet.com/bms/departments/innovation.sh tml
http://www.mcmillan.cx/innovation.html

This last dude gave up, Last updated 27 June 1999. Basically, it came down to a list of all accepted innovation nominations compared to two accepted: Microsoft Bob (doubtful but accepted) and the fucking talking paper clip. Which is basically Bob redone as a more annoying Help file.

all I did was a google search for "microsoft innovate" without quotes, and I came up with ZERO microsoft sites, and a whole bunch which put "innovate" into the quotes it deserves.

Worthless software company. The only things they did right are SQL server (derived from Sybase, and even though it was apparently recoded it shares similar syntax), which actually has a decent track record on security issues, and of course Visual Studio (IMO until the .NET crapfest, but even that is well done, just a personal preference, except that they are trying to win against Java using an interpreted framework, but Visual Basic was completely reengineered and basically thrown away?) (but it uses a third party C/C++ library from Dinkumware, don't think they came up with any of that themselves) (oh and they didn't make the compiler either, they made it worse). But without microsoft we wouldn't need either of these. I believe they don't suck because they were made by developers, for developers.

Dinkumware info, apparently there is a license dispute so that MS can't package the updates in a visual studio service pack, so Dinkumware tells which lines to edit and how:
http://www.dinkumware.com/vc_fixes.html

std::string causes corruption. Sorry we can't fix it, upgrade to .NET or buy a C++ library:
http://support.microsoft.com/kb/813810
"When you build applications in Microsoft Visual C++ 6.0 that use the supplied Standard Template Library (STL), memory corruption may occur, or your computer may stop responding. "

Origins of MSC compiler
http://www.nimh.org/microsoft/
"`This is just a historical note about the C compiler microsoft sells. In the late 80's I was developing C programs under DOS using the Lattice C compiler. One day I got a letter from Lattice saying they were out of the C compiler business, I should contact microsoft for support. I found out that microsoft bought the compiler and exclusive rights to sell it from Lattice. "

O man I just pissed myself off again rehashing all that ineptitude.

The following code used to be legal, but not any more, since i's scope is now inside the for loop only: ...

There are bugs in the STL shipped by Microsoft. There's some unofficial patches here. The one you're looking for is "Fix to <xtree>."

The problem with on-line C++ is that many people who claim to write about it don't know their subject, and consequently write superficially correct code that actually sucks. I'm sorry to name names, but the much-recommended-here CPlusPlus.com is one such site; their "Hello, world!" program at the start of their isn't even correct. I'd give sites like that a miss if you're seriously interested in learning C++.

One good source of information about C++ (and many other programming-related subjects) on-line is the related Usenet newsgroups, particularly the group specifically for learners if you're just starting out, or the moderated C++ group for more advanced subjects.

Many of these groups also have helpful FAQs, available (as usual) via the Internet FAQ Consortium. Again, for those just starting out, I'd particularly recommend the alt.comp.lang.learn.c-c++ FAQ, which has links to helpful on-line resources, free compilers, etc.

There are a few web sites of which anyone in the C++ field should be aware.

• You can get generally pretty sound book reviews for thousands of books on these and related subjects at the Association of C and C++ Users web site.
• Herb Sutter's web site has lots of informative and thought-provoking C++ articles by one of the guys who's advanced C++ programming technique a lot in recent years.
• Similarly, Scott Meyers' publications page has many worth-reading articles on C++.
• It would be remiss not to mention Boost, a collection of very good general-purpose C++ libraries. If you can't see how to do something with the standard stuff, the answer -- or a useful idea to find it -- may well be here.

There are a few decent on-line references to the standard library:

• Dinkumware make a standard library implementation, which is shipped with Visual C++ amongst other things, and provide some helpful documentation on-line. (NB: The version that shipped with VC++ 6 was flawed in many horrible ways, but that wasn't really Dinkumware's fault given the compiler limitations at the time when they wrote that library; please don't judge them by that alone.)
• SGI's implementation of the "STL" parts of the C++ standard library is excellent, and well-documented on-line.

About the only decent on-line C++ tutorial I know of the electronic version of Bruce Eckel's "Thinking in C++" books. You can find a complete copy of these, and several of his other books, at his books web site. (He also has books on Java, C#, Python amongst other things, and all of his work I've read has been reasonably good.)

<sigh>Once again my story gets rejected when it contains more info than the one that gets posted. :-(

To set the record straight, EDG do indeed produce C++ front end compiler tools, and it is these that have just been released.

However, major C++ vendors including Comeau Computing use that in their compilers. Comeau already have a beta of their 4.3.0 compiler available at their on-line compiler. The full version is due later this month.

Dinkumware have also announced a version of their standard library implementation to work with Comeau, which should be available shortly after the Comeau compiler is released. Apparently, it makes extensive use of export, but for little change in performance at compile-time.

That makes their new library implementation a bit academic as far as Joe Developer goes. However, it's excellent news in general, because it shows that using export isn't going to entail a performance hit. We can finally write template code with interface and implementation properly separated out.

"Testing C++ Compilers for ISO Language Conformance" (Dr. Dobb's Journal, May 2002). This article introduces a Python framework that uses example code from the standard. Article and partial code available. Compilers include: GCC 3.0, 2.96, 2.95; Borland 5.5; VC++ 6.0.

"C++ Conformance Roundup" (C/C++ User's Journal, April 2001). This article, referenced by the previous article, analyzed results from Dinkumware, Perennial, and Plum Hall. Compilers include: IBM, Sun, Metrowerks, Intel and KAI, MS, GNU, Borland, and Comeau.

Dinkumware, Ltd. was the company that Microsoft contracted with to write the library files for VC++ 4.2, 5, and 6. Due to a lawsuit involving Dinkumware and not Microsoft, the library was not updated beyond the July 1996 draft standard until VC++.NET was released, which was after Dinkumware trounced Plum Hall, Inc. in that lawsuit. By the way, Dinkumware has a page detailing all the known bugs of the July 1996 draft implementation and how to fix them here.

Dinkumware, Ltd. was the company that Microsoft contracted with to write the library files for VC++ 4.2, 5, and 6. Due to a lawsuit involving Dinkumware and not Microsoft, the library was not updated beyond the July 1996 draft standard until VC++.NET was released, which was after Dinkumware trounced Plum Hall, Inc. in that lawsuit. By the way, Dinkumware has a page detailing all the known bugs of the July 1996 draft implementation and how to fix them here.

Dinkumware, Ltd. was the company that Microsoft contracted with to write the library files for VC++ 4.2, 5, and 6. Due to a lawsuit involving Dinkumware and not Microsoft, the library was not updated beyond the July 1996 draft standard until VC++.NET was released, which was after Dinkumware trounced Plum Hall, Inc. in that lawsuit. By the way, Dinkumware has a page detailing all the known bugs of the July 1996 draft implementation and how to fix them here.

Obviously not, because the containers rely on the safety of the copy constructor and auto_ptr implements RAII through the copy constructor. Conceptually, aren't both part of the "STL" anyways?

This is one of the reasons Boost has a templated shared_ptr, which does reference counting instead of source/sink pointers.

This is covered in Effective C++, but it's also pretty obvious from the APIs.I question designs that want source/sink pointers in containers anyways; part of the idea behind using containers is to centralize the storage of objects.

In practice, the big problem with the STL is that Microsoft doesn't like it. ... So they support it, but badly.

I'm not sure this is a valid criticism:

• Microsoft uses Dinkum STL, which is actually an exceedingly good implementation. The only problems I've had are concurrency issues.
• Compare Microsoft's problem to Solaris. Forte uses bizarro Rogue Wave STL, which is not an exceedingly good implementation of the STL.

Yes, vector<bool> was a horrible mistake. That should be fixed in the next version of the standard. Where performance is important, use vector instead.

Yes, vector<bool> was a horrible mistake. That should be fixed in the next version of the standard. Where performance is important, use vector instead.

"Both the Solaris (actually SGI) and RogueWave implemementations DO NOT match the documented interface, even though Rogue Wave's documentation says it does! So make sure your intended usage is actually supported by the implementation of the STL that you're using."

Uhm, last I checked, that's because Micro$oft doesn't implement the STL standard properly, and their MSDN docs reflect their implementation, not the standard one.

Maybe this has changed, but I doubt it. For a much better (and correct!) STL reference, go see dinkumware, which sells an online reference, as well as a complete library implementation, should you need it. Dinkumware, conveniently, also provides the online docs over the web for free, as long as you promise not to download them to your machine.

A number of postings have complained about the fact that many compilers / platforms / libaries do not follow the STL standard precisely. If that is one of your concerns, I suggest using Dinkumware's standard libary. This is the only implementation of the C++ libraries that is truely 100% specification conformant and well documented. I am not affiliated with this company in any way, but their stuff is kick-ass. So if you need something that works across platforms etc., go with them. As far as I remeber, Intel's C++ compiler also supports the dinkumware libararies, and is very ISO C++ compliant. If you use these two together, then you may end up with 100% ISO C++ / STL compatibility / support. Porting applications from one compiler to another or from one library flavor to another can be a bit painful. I would suggest you pay the price of kick-ass commercial implementations and start with them right from the beginning, if you care about these issues.

I went into a big Visual C++ project this year, after an education mostly on Solaris and BSD, and found the answer to that question: because anything that comes after std:: in the Microsoft libraries, such as the STL, is likely to be riddled with bugs to the point where it becomes unusable in anything but a trivial sample program.
Of course, in retrospect, this is to be expected, because after all things like the STL are supposed to be cross platform, whereas Microsoft provides plenty of Windows-only alternatives. (Not std::string! CString!)


What on earth are you talking about? While I recognize that MSVC++ doesn't have the best template support, you seem to be attacking the libraries themselves. The company that produces those libraries is Dinkumware, not Microsoft. And if you were having problems with the library that you couldn't work around with still-legal code (which I find hard to believe), then you can upgrade those libraries for a small fee (for a company) at http://www.dinkumware.com/libcppvc.html.

Also, STLPort offers a free STL implementation.

I know it's really cool to bash MS, but you just bashed the wrong company.

Microsoft is definitely full of shit when they consider 'export' to be "theoretical" only. But implementing export is hard; witness the number of compilers that have managed to do it so far. I don't blame MS for putting it off; I blame MS for lying about their reasons for doing so. (If they'd just said, "Implementing this is a freakload of work and we'd rather point our engineers in a more revenue-profitable direction," then I could accept that, too.)

The for-loop scoping bug has a command-line switch to toggle correct behavior. Unfortunately, with it on, large chunks of their own MFC code will no longer compile.

Dinkumware was contracted to provide the library for VC++. They have released their own patches (freely downloadable) to the library headers. With those patches applied, your library is as ISO-compliant as it can be given the (immense) deficiencies of the compiler itself.

For me the big killer is templates -- lots of failures in things like partial specialization.

My recommendation to others who have to work under Wintel: there are plenty of good compilers out there, and they're ALL better than VC++. Comeau, IBM, EDG, KAI, you name it...

Absolutely,

As someone using ACE at the moment (well, in another screen). I can say that I've never found a more well-constructed cross-platform middleware package. You can find it here. In addition, the DOC group's TAO package provides a CORBA implementation on top of ACE that works really well for... well, those CORBA things *grins*.

One drawback when using any middleware package that I've seen is that you have to buy in pretty heavily to the package, somewhat adopting the development philosophy of the package's designers. With ACE that hasn't been as much of a problem (For instance, it provides a method of dispatching QT events) mostly because the underlying design is heavily pattern based.

On other fronts, I also continually find the Boost libraries to be very useful. They can be found here.

Probably the last thing to consider is that if you vary your development platform, you are likely going to be changing your C/C++ implementation--and they are not all created equal. Personally, I've found that the cross-platform availability and easy integration of the Dinkumware C/C++ libraries are pretty much worth the middle-of-the-road costs involved. Dinkum's located here.

http://www.dinkumware.com/jproject.html