Slashdot Mirror

Still.. as fast as modern computers are I think we may be reaching a point where raw speed is less important and well designed microkernels can probably run almost as fast as monolithic kernels.

I like Dr. Dobbs Journal, C/C++ Users Journal, Communications of the ACM and IEEE CGA.

If you haven't heard of DDJ or CUJ before, give them both a try. DDJ covers all sorts of stuff and (as an example) the October '05 CUJ had the best accidental intro to template metaprogramming I've ever seen.

One of CACM's selling points is that the articles are regularly featured on slashdot. :p

IMO, IEEE CGA is much more useful to me than any of ACM's SIGGRAPH stuff. This is only relevant if you're into computer graphics at all.

I'm thinking of joining the Association of C/C++ Users for it's C-Vu journal, I dunno.

I read 2600 for the hell of it.

Your mileage will vary.

future of cross-platform development

You know, after a while, ignorance isn't even amusing anymore. gcc, nasm, qt, gtk, wxwidgets, more, then even more perl, python, ruby, ... ... ...
 

Here are some keywords to plug into Google if you want to read up on the basics of synchronising threads and sharing resources: semaphore, mutex, baton passing.

The "isnot" operator was proposed for the D Programming Language as a replacement for the !== operator already in use in D. The !== operator determines if two references are at the same address or not. Both the "isnot" reference and the !== operator well predate the patent application.
isnot proposal
earlier D specification

Everything else I get on-line.

MikroBitti, Suomen Kuvalehti, Dr Dobb's Journal, Software Development, Embedded Systems Programming, C/C++ Users Journal, National Geographic and Time

Almost all extant C practitioners would benefit greatly if they gradually abandoned C-style and learned multi-paradigm C++. The world would be a better place.

This is not a troll, and before all of you fundamentalist fanatics pull out your flamethrowers, inform yourselves:

C++ FAQ

C vs. C++

The case for the continued existence of C is tenuous at best.

If you accept the notions that
1. scripting languages speed development
2. high-level code does not need to be optimized

Then for an app like Neverwinter Nights, it would make sense to use a scripting language for the high-level code (e.g. menu handling code), while leaving the performance-critical code (e.g. 3-D rendering) in C, C++ or assembler.

Coded like this, NN might not crash as frequently because either
- The crashy code would be implemented in a scripting language, and so memory handling would not be a problem

- The crashy code would still be in C/C++, but since the other code had been written more quickly, there would be more time to fix it.

The current issue of the C/C++ Users Journal is all about mixed-language development.

You can get the same effect using Smart Pointers and not give up the control that using a garbage collection system entails. See Boost and Alexandrescu, Andrei. Modern C++ Design. There is also a nice article on CUJ.

I ran across an article a couple of years ago by Chuck Allison in C/C++ Users Journal about the The Simplest Automated Unit Test Framework That Could Possibly Work. It included test frameworks written in C, C++,and Java and opened my eyes to doing best practices to the extreme. It also showed me how I could apply unit testing to my C code. You can download free Test Frameworks (Test Suites) for other languages.

Unit testing was the first XP key practice that I started to use. When I would have to make a change in my mature code, I would add a unit test section to the module I was changing (using #define TEST), and add a main() to execute the unit test (using #define TEST_MODULENAME). See examples of this on my software page. I then began using test-first programming by writing the unit test first, seeing it fail, then writing just enough code to make it pass.

Other extreme programming sites that have been useful have been extremeprogramming.org , which has a great tutorial that includes an introduction and overview, and the site Extreme Programming.

It's time for c++ to move into the 90s and get rid of the preprocessor. It's unnecessary with modern compilers, and it's a pain in the ass.

Why do I have a feeling that you never really used a preprocessor when you do claims like that? Preprocessor is most useful feature, see for example enforcer idiom by Alexandrescu and Marginean, even if it's just for __LINE__ and __FILE__.

My only complaint for C++ preprocessor is that it's actually C preprocessor, not C++ (performed at the stage before C++ parsing), and is not flexible enough (postponing conditional compilation until macro expansion would be nice).

There should be a rule... Everyone complaining about C++ should know it. Complain about overloading functions, be ready to cite Chapter 13 of ANSI/ISO C++98... It would really reduce S/N.

The C/C++ Users Journal has an excellent editorial article about the low qulity of software. The premise is that a lot more people became software professionals than could be properly mentored into high quality developers. Also, a lot of people went into the profession who were simply not skilled at all. I think the article is right on the money when they say a main reason for low quality is that a lot of code has been written by people who just know VB or HTML and suddenly think they're hot-shot software architects.

The C/C++ Users Journal has an excellent editorial article about the low qulity of software. The premise is that a lot more people became software professionals than could be properly mentored into high quality developers. Also, a lot of people went into the profession who were simply not skilled at all. I think the article is right on the money when they say a main reason for low quality is that a lot of code has been written by people who just know VB or HTML and suddenly think they're hot-shot software architects.

Am I the only C and C++ programmer who finds the "C/C++" label annoying as hell?

I have heard this kind of complaint before, and it is from people with a chip on their shoulder.

I guess you don't read the "C/C++ Users Journal" .

Stop being such a dick. YOU are as annoying as hell.

You're also being left behind in the dust. Modern C++ is all about exploiting templates to simplify development, and even reduce code bloat (by making it easier to reuse common code) and increase performance (through automatic compile time generation of heavily inlined versions of algorithms).

If you make a huge template with lots of code that could be easily generalized for all types, then you're writing a bad template: You should factor all common code into a base class and make a template that contain the few parts of the code that are type specific. On the other hand, if your code can't easily be generalized for the types you need, templates save you the tedious and error prone task of maintaining multiple versions of your code specialized for multiple types.

In that respect templates dramatically reduce the amount of work you need to do, if applied properly.

As mentioned above, template techniques can dramatically improve performance over a generic algorithm by providing you with an automated way of generating heavily optimized inlined versions of an algorithm. The C++ template syntax is not really ideal for this, but the benefits from using templates for this are tremendous enough to make it worthwhile. Do a search for Vandevoorde's work on expression templates, or for Alexander Alexandrescu on Google to find more, or read Alexandrescu's articles in CUJ.

Continue to believe your prejudices if you want, but consider that if you can't use or write templates you've essentially shut yourself out of a huge segment of the C++ development job market. I would certainly never hire a "C++ developer" that don't at the very least have thorough experience with the STL, and preferrably understand how to write (and when to write) templates.

You could use Java's RMI for this Jav architecture, which is the second fastest distrubited call framework available, and second only to sockets...SOAP, DCOM, and CORBA are respectably slower, CORBA being the slowest of the bunch.

Second, RMI runs over JRMP (a Java native protocol) or IIOP (CORBA's protocol). JRMP is slightly faster than IIOP, but both are comparable. In a multi-langauge environment IIOP would allow you to use CORBA to integrate your Java apps with apps written in other languages.

This is not to say that SOAP is useless, or even bad. The broad base of support SOAP enjoys means it could become a lowest common denominator; a kind of the middleware for middle. But it by no means replaces CORBA. There are many good articles on this topic from both the pro-SOAP and the pro-CORBA sides. As another poster said, when making these sorts of decisions it is important to research both sides rather than trying to measure the oppinion of slashdot.

I firmly believe that SOAP and CORBA are complimentary technologies.

MOJO. This is a link to a detailed report on how to handle unneccessary copying of temporaries and why the compiler can't do it for you.

Now we see the basis for Bobby Schmidt's "Hell Freezes Over" column in the latest CUJ. The next Visual C++ is standards-compliant by vacuuming up a quality comptetitor...
No, that's a troll.
But Borland has a lot of Java product, and owning that would help to maneuver it out of the C# path...
No, that's a troll, too...
Borland's CLX library has the potential to do what QT could not, popularize GUI-applications that run under 'Doze and X, so you could blunt that attempt to compete if you owned the product... (seriously, I can't name a single application on the local CompUSA shelf using QT, please educate me)
No, that's YAT (Yet Another Troll)
The fact that the DOJ is a singleton-class, MS server application running inside the Beltway box means that MS can do whatever the fsck it likes and laugh about it...
Ah, now that is a sufficiently gratuitous troll...

Actually export has turned out to be a sort of misfeature. Most C++ gurus have now realised that it doesn't really do what it was hoped it would do. See this - http://www.cuj.com/current/index.htm?topic=current
(Scroll down to bottom)
"Sutter's Mill -- 'Export' Restrictions, Part 2 Until further notice: the tariffs on export are too high for everyday use."
(The whole article is only available in the print version)
In fact the very first implementation of export has turned out to be a very pyrrhic victory as said by the developers themselves. Turns out that export will need some serious redisign before any of the other C++ vendors will use it. Certainly the intent was good and one needs something like export. But export as it stands today doesn't quite cut it. The basic problem. Its too complex to implement and use and it breaks some other very basic C++ rules when you use it. Also its implementers say that it would be very difficult to give the users a consistent set of rules/advice on how to use it without getting shot in the foot. So looks like we can all forget export for a while. No need to worry about GCC or others not supporting it. Lets all wait for export v2 for that. In any case the C++ comittee agrees that they did too much of an invention with that feature without having the requisite expereince inspite of C++ compiler vendors warnign against it.

Here's a CUJ article with a freeware script to "decrypt" STL error messages. I haven't tried it, but it seems the author keeps it up-to-date, and supports a good range of compilers including gcc 2.95.x/3.x and MSVC++ 6/7.

Two things. One, programming takes a lot of time and work, and you will be well rewarded for the time you put in to learning C++.

Two, no one uses every feature of C++. I don't think any compiler even now supports the full ANSI C++ standard. I was just reading a CUJ article about separate template compilation and how it's just now being implemented, since it's doesn't really work as many people thought it would. People still do great things with C++ though. The C++ philosophy is to enable you to do what you want; if Bjarne sees something that might improve 5% of programs with a 5% speed hit on the other 95%, he'll add it (I'm thinking of multiple inheritence here, and don't quote my numbers). So don't worry about the complexity of C++, just use what you like.

Hyslop and Sutter on Hungarian

(In summary, don't.)

The purpose of design patterns is not to specify an absolute framework to work from, but to describe a way that collections of code can work together to provide a solution for a type of problem... You can translate OO solutions in to non-OO environments, go see Cuj for an example involving UnitTests.

For technical questions about C++, you really can't beat comp.lang.c++.moderated. I browse it a lot, but rarely post. Despite studying the langauge for 3 years, my knowledge of the langauge is like nothing compared to the better posters there.

Google Groups for the comp.lang.c++.moderated

A lot of very knowlegible people post there, people who have sold quite a few books about C++ and members of the C++ standardization committee.

Another good site for advanced C++ stuff is the C/C++ Users Journal, a lot of the aforementioned C++ authors post articles, often that are chapters from books.

Read the test results of the C/C++ User Journal's compiler roundup.

Read the test results of the C/C++ User Journal's compiler roundup.

I've lost count of the number of times companies have claimed to be "standards compliant" only for this to turn out not to be the case when close scrutiny is applied to the product.

A USENET thread claiming that a product is standards complaint has 0 credibility in my book regardless of who stated it. On the other hand passing the C/C++ User Journal's compiler roundup's set of conformance tests from Dinkumware, Perennial and Plum Hall with flying colors is worthy of comment.

That said, EDG has long been producing the best C++ language compiler in the industry and if anyone could have achieved this I'd expect it to be them. However, running a front page story on Slashdot based on a USENET post lacks editorial judgement.

I've lost count of the number of times companies have claimed to be "standards compliant" only for this to turn out not to be the case when close scrutiny is applied to the product.

A USENET thread claiming that a product is standards complaint has 0 credibility in my book regardless of who stated it. On the other hand passing the C/C++ User Journal's compiler roundup's set of conformance tests from Dinkumware, Perennial and Plum Hall with flying colors is worthy of comment.

That said, EDG has long been producing the best C++ language compiler in the industry and if anyone could have achieved this I'd expect it to be them. However, running a front page story on Slashdot based on a USENET post lacks editorial judgement.

For those of you complaining about the huge error messages that the STL can sometimes cause, you might want to try this:
http://www.bdsoft.com/tools/stlfilt.html

I haven't tried it because I haven't done anything with the STL in a while, but it seems pretty nifty. It's basically a Perl script that you can use to decipher the error messages into something useful. There's even instructions on how to make it work with VC++.

This article has a better description and an example, in which a 20-line error message is reduced to plain English.

There was an article in the C/C++ Users Journal a year ago testing for compiler conformance. No compiler made 100%. The areas that some of the more advanced compilers lack are probably deep, dark recesses of the STL you'll never use, but there are still gaps in the implementations.

Herb wrote an article with Jim Hyslop on standards-conforming compilers: Conversations: So Who's the Portable Coder?. In it they address the loop variable scoping issue which plagued many C++ compilers (and was discussed on /. some time ago).

Microsoft definitely needs to boldly go where C++0x goes, which will be in part derived from C99. C99 is cool. Can you say "complex"? Yeah =)

I just hope VC++'s next compiler is the last one that is not compliant... it's too freaking painful sometimes.

Microsoft definitely needs to boldly go where C++0x goes, which will be in part derived from C99. C99 is cool. Can you say "complex"? Yeah =)

I just hope VC++'s next compiler is the last one that is not compliant... it's too freaking painful sometimes.

The beauty of Mono is that it would allow you to call the Perl module that you really like from Python (and vice versa). You could write an XML parser (for example) in C# (or Python or Perl or C, etc.) and call it from whatever language you like because all of these languages would rely on the CLR (common language runtime).

You do realize that CORBA not only allows you to do the same thing, but is significantly more efficient at doing it?

CORBA ORBs exist for Perl, Python, Smalltalk, LISP, C, C++, Objective-C, etc and they all communicate with eachother.

I am completely dumbfounded by the argument that CORBA, COM/DCOM, RPC and even RMI are somehow less efficient than SOAP when the exact opposite is true. A wonderful article on SOAP vs CORBA is available at the CUJ.

GCC can already do that, or at least it does an reasonably OK job. It's really more a question of having a good STL implemenation, IMHO. Here are a couple of links (shamelessly ripped from the compilers part of Bjarne Stroustrup's C++ FAQ):

C++ conformance roundup and boost.org's compiler status page.

I think gcc-3 meets or exceeds the steep C++ support that these clients require

The C/C++ user's journal ran a very interesting roundup regarding this. The STL situation seems a bit on the bad side, but the compiler itself seems to be pretty much standards conformant. Having to swith between SGI's MIPSpro, HP's aCC and gcc is sometimes painful but you can usually fix one compiler's complaining and still have it work with the other two.

However, Java is a different deal all together. First of all, if you are familiar with C++ you now about 90% of Java right of the bat. So you don't really need a "from scratch" Java book. All you really need is reference material, and some basic guides on how key things work in the JVM, like threading, synchronization, etc.

My recommendation is the web on this one. Download the latest JDK (1.3 or 1.4). That is full of great references, API's, HOWTO's and guides. This will be the source of 95% of your Java knowledge.

Next, I'd start checking out C/C++ User's Journal's Java Solutions. You can subscribe to the magazine, but frankly I'd stick to the online version. These guys are C++ freaks who talk about java from the C++ perspective, so you will feel at home with the discussions there.

The only books that I would recommend, are for specific applications. For GUI work, get O'Reilly's Java Swing, and Topley's Core Swing Advanced Programming. Either one will do; they are both excellent. For Serlvet's, O'Reilly's Java Servlets is OK, but slightly out of date (maybe mine is and they have updated). Also, Professional JSP by Wrox is excellent for both serlvet and JSP work (even touches on EJB).

What is interesting for me about Java, is that I find myself using online resources much more than I ever do with C/C++ applications. Java documentation is so standardized (javadoc) that it lends well to this approach.

Has anyone else out there sort of grown up with Perl during this dot.compost era and now started to check out C and the real guts behind ''world domination?''

I'm finally getting into C by taking a night class at UCLA, and my god, this stuff only gets cooler and cooler. To see the community RFC type thing go on with Perl6 and to watch/hear/readof the ISO committee floundering with other languages is very interesting too.

Of all the uninspiring things happening with government, the economy, environment, etc these days, I really recommend that any inclined kid such as myself out there get back to basics and check out what their local community college/college extension has to offer. I have, and every time I walk out of class it's like "oh, no shit, that's friggin sweet." Maybe it's just me, but for some of these things, it's just easier to be in an engaging classroom environment rather than to be all by your lonesone with Conway's ''OOP.''

Anywho, back to coding..

Is the absence of C++ standards due to gcc not having a ISO C++ compliant release? I know that 3.0 is in the works and that Red Hat ships a snapshot of GCC in an attempt to get better libstdc++. Is this lack of a viable free option the reason for no C++ standardization?

I'm grabbing my copy of C/C++ User's Journal, April 2001, which had a Compiler Conformance check (see it online). They have always avoided rating compilers, but now that there is a standard, they decided there was now a somewhat objective means to judging a compiler - conformance to standards. They go on for about 5 pages, explaining the tests and giving justifications for testing. The folks who create the test suites get to comment, the folks who wrote the compiler get to comment, and it looks like everyone involved will work toward meeting the standard in the next release.

Gnu gcc 2.95.2 was tested, as well as Borland BCC 5.5, Microsoft's Visual C++ 6.0, Intel's C/C++ 4.5, as well as 6 others. While just about everyone else commented on the results, there was no spokeperson for gcc.

You'll have to go to the web-site for full results, but here's a few. Three test suites were used, from Dinkumware, Perennial, and Plum Hall. The compiler was tested as well as the library, and results were given as percentage compliance.

Borland
Dinkumware: library - 75%
Perennial: compiler - 63%, library - 67%
Plum Hall: compiler - 89%, library - 74%

Gnu C++
Dinkumware: not tested
Perennial: compiler - 98%, library - 41%
Plum Hall: compiler - 94%, library - 21%

IBM C++
Dinkumware: library - 99%
Perennial: compiler - 99%, library - 97%
Plum Hall: compiler - 95%, library - 85%

Intel
Dinkumware: not tested
Perennial: compiler - 96%, library - 72%
Plum Hall: compiler - 90%

Microsoft
Dinkumware: library - 84%
Perennial: compiler - 77%, library - 64%
Plum Hall: compiler - 83%, library - 74%

You can look up the other number if you so desire.

As you can see, as far as compliance goes, Gnu C++ is pretty good for a compiler, but is lacking in the library department. I find it interesting, and I'm sure the GNU C++ team is looking at the numbers, considering how important the library is to the standard (it really does make C++ more powerful).

Many cases of virtual function calls can be completely optimized away at compile/link time. Read, for example, here.

This past weekend I picked up The C++ Standard Library by Josuttis. I've found this to be a wonderful reference, with sections not only covering the STL, but also strings, numerics, iostreams, i18n and allocators. It has a good TOC and index. I've not read it straight through (or even made an attempt), but it is very easy to find what I need. Explanations are clear and concise. Reading one page of the iostreams chapter halped me successfully derive a new stream buffer and class in five minutes. All previous documents were either too esoteric or verbose -- I couldn't get my head around the problem.

Sounds like the C++ version of Plauger's like book for C. Something very useful.

Perhaps you'd be interested in the following books:

• Large-Scale C++ Software Design
• Inside the C++ Object Model
• The Design and Evolution of C++

I've only read D&E. This is probably where you should start. It is very small. It's whole purpose is to explain why things are they way they are (i.e. you don't pay for what you don't use).

I have D&E and read some of it. It didn't seem to be useful for learning C++ at all. I saw LSC++SD in a "brick and mortor" bookstore, but wasn't impressed enough to hold on to it for more than about 20 seconds. However, Inside the C++ Object Model sounds from the title like it might be worth looking into.

In addition, journals like DDJ and the (now-defunct) C++ Report have good articles about practical software development. I hear many of the C++ Report folk are heading over to the C++ User's Journal.

I've rarely ever found magazine articles to be much helpful in things.

The most important thing to remember about C++ is that it is complicated. But only as complicated as you make it. For all intents and purposes, you can write C in C++. A good place to start is using it as "C with classes" to get encapsulation, then move on to polymorphism. It's also important to understand when to use language features (i.e. templates and specialization vs. inheritance) and books like Effective C++ help in that regard.

That I can write C in C++ is probably one of the big negatives for C++ for me. I would be so tempted to just do what I know. Why do I need to "get" encapsulation when I already have it in the abstract sense of the design? C is just the vehicle I use to bridge the abstraction-to-reality gap. Don't assume that because I code in C, that I didn't do anything object oriented in the design (I do to varying degrees in many projects).

Most of the documentation out there for so much stuff is written with the idea of sequential reading in mind. I don't have the time to do that in most cases, so documentation that gives an introductory concept explanation (without the usual sales talk that most use as introductions), and has all the rest as a well indexed reference, would do better for me (and a lot of people I know).

This past weekend I picked up The C++ Standard Library by Josuttis. I've found this to be a wonderful reference, with sections not only covering the STL, but also strings, numerics, iostreams, i18n and allocators. It has a good TOC and index. I've not read it straight through (or even made an attempt), but it is very easy to find what I need. Explanations are clear and concise. Reading one page of the iostreams chapter halped me successfully derive a new stream buffer and class in five minutes. All previous documents were either too esoteric or verbose -- I couldn't get my head around the problem.

In a previous post, you suggested:

If you still want to convert C programmers to use C++ then I suggest writing a book ... a short one, that explains every concept in C++ ... not just language syntax, but practical concepts ... clearly and concisely. Don't drag it out for newbies; focus on experienced C programmers. Explain how it is that C++ takes basic OO design concepts and puts them into a programming language. Explain how C++ behaves with each concept at higher abstract as well as lower real levels. Include a full reference section. And make sure there are examples of whole programs, not just snippets everywhere. Maybe then you might see more converts. But until someone does this, I doubt you will see very many.

Perhaps you'd be interested in the following books:

• Large-Scale C++ Software Design
• Inside the C++ Object Model
• The Design and Evolution of C++

I've only read D&E. This is probably where you should start. It is very small. It's whole purpose is to explain why things are they way they are (i.e. you don't pay for what you don't use).

In addition, journals like DDJ and the (now-defunct) C++ Report have good articles about practical software development. I hear many of the C++ Report folk are heading over to the C++ User's Journal .

The most important thing to remember about C++ is that it is complicated. But only as complicated as you make it. For all intents and purposes, you can write C in C++. A good place to start is using it as "C with classes" to get encapsulation, then move on to polymorphism. It's also important to understand when to use language features (i.e. templates and specialization vs. inheritance) and books like Effective C++ help in that regard.

Hope this helps!

--

Here is a nice article.