Slashdot Mirror

(In common vernacular, you're smart and I have the stupid.)

It's probably more accurate that you have the ignorant. There's no shame in not knowing, right?

Where's a good place to get into C++?

I honestly don't know! The best I can suggest is borrow a Scott Myers book from a library (latest edition of Effective C++), have a copy of the FAQ at the ready and join a reasonably welcoming open source project.

Why Scott Myers? Because one of his books will give you a sense of the difference between C and C++.

This is just hipster crap - science because its cool or whatever (see maddox's recent discussion).

Also, for the love of god, http://www.parashift.com/c++-faq-lite/using-namespace-std.html

(in this case, I guess its OK, but can we stop putting that globally?)

If you use C, it's "large enough to hold any member of the basic character set of the execution environment". That can be a fair bit larger than 8 bits in some implementations.

Look at the libstdc++ for GCC and some of the boost project code.

That code has production quality, is written in a style that actually utilizes c++. Beware that c++ recently got quite a few new features that have not gotten too much usage in libstdc++ and boot you may want to read up on that separately.

There is an *excellent* FAQ on most of the fine-grained aspects of c++ at http://www.parashift.com/c++-faq-lite/

In general, stay away from tutorials on the web, they are mostly written by people who have little or no experience and thinks they should teach the world about for loops or whatever because they just made one that doesn't crash themselves.

As a side note: that goes doubly for javascript, a much better search term to find quality code is ecmascript, unfortunatly there is no such good discriminating search-word for c++.

I never understood the need for a destructor. For 99% the GC is just fine and for other resources besides memory I have a close method. If you really need a custom memory management, then you can hack the OpenJDK.

http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.9
"[17.9] How can I handle a destructor that fails?
Write a message to a log-file. Or call Aunt Tilda. But do not throw an exception! "

So RAII is completely useless for any kind of resources. That's why I also don't understand the hype about RAII.

From Wikipedia:

~file() {
                if (std::fclose(file_)) { // failed to flush latest changes. // handle it
                }
        }

void example_usage() {
        file logfile("logfile.txt"); // open file (acquire resource)
        logfile.write("hello logfile!"); // continue using logfile ... // throw exceptions or return without // worrying about closing the log; // it is closed automatically when // logfile goes out of scope
}

And what if the std::fclose method of the log throws an exception? Where should I log that? In the worst case nothing is flushed to the file and the log is empty. The exception is not logged so you can spend hours to find your bug. That is true for all other kinds of resources, be it sockets, pipes, etc.

"Using RAII-enabled resources simplifies and reduces overall code size and helps ensure program correctness."

Except where the methods in the destructor throwing an exception in this case almost all developers just ignore it, how is that to "ensure program correctness".

I was basing my information on this:

      http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.9

but apparently I hadn't read it thoroughly enough :). Good to know that it's a least technically possible.

Still, even if it is technically permissible to throw in destructors, it seems too fraught with danger to actually contemplate seriously. I wonder if the standard fstream classes do something like this if running in "exception mode"...

You can't put method bodies in a separate .cpp file if you use templates. When your library is mostly templates (like Boost), then all its code must necessarily be in the header files.

This does not mean that the code in the headers can "still be reduced to just the interface facts".

You are misinfromed. Yes you can, see this example. You can separate the template interface and implementation; However, in order to instantiate a template you must have access to the implementation. Libraries can provide just the template interface and a .so with commonly used instantiations to link against, and as long as you only use the explicit instantiated template forms you will not need the template implementations.

Lets say you have some LGPL function template that has its implementation in the .h file. I can reduce that to just the interface facts:

mylib.h
template <T> int someFunc( T * aVar );

Here is the .cpp implementation that has been split out (still LGPL) -- A derivative of the original combined template interface / impl.
mylib.cpp
#include mylib.h
template <T> bool someFunc( T * aVar) {
if ( aVar != NULL ) return true;
return false;
}

// Add Explicit template instantiations commonly needed -- prevents multiple instantiations of these:
template <int> bool someFunc ( int * aVar );
template <float> bool someFunc ( float * aVar );
// etc..

I can then compile a mylib.so that falls under the LGPL. I can then link NON LGPL programs to it via the sanitized .h file.

In order to use the template with types other than float or int I must have access to the mylib.h & mylib.cpp and include both. Or, I can use just the .H and recreate my own .CPP implementation to provide a compatible yet non-derivative, non-infringing library that I can license however I choose.

Once I have created (& possibly extended ) my own non-infringing lib, I am free to distribute the stripped down mylib.h file along with the mylib.so binary and other programs that only use the explicitly instantiated float, int and MyNewClass variants will not need to include the mylib.cpp code.

In the case of Boost, you'll end up re-creating much of the template implementation, but this does not mean that one can not separate the template implementations and interfaces, and subsequently create a compatible, non-infringing library that is compatible with Boost.

Or, you can separate the boost interface from its implementation, explicitly instantiate the template forms you will be using in a derivative .so binary (same license as Boost), then create your non-derivative application that simply uses the instantiated template forms and distribute it under a different license.

TL;DR: You are wrong. My point stands that I can reduce any .h files to their implementation facts then create non infringing .cpp file to link my own non-infringing / separately licensed code against.

The reason that op.ov. is generally bad is not efficiency, is not whether it's a good name or good style. It's maintainability. Why obscure the code with op.ov.? Why not state very clear in the code what you are going to do?

As example, a very abused operator is the <<. You write file << "text" It's look very cool, but what does it mean? Why not state clearly what it means: file.append("text") or file.save("text").

You will read code more then you are going to write it and with op.ov. I need to study every class I use what is the meaning of each op. C++ is probably the first language with build in obfuscater.

The only thing around it is just forbid op.ov. because no operator is a good name for an operation, except the build in operators. The build in op. are well documented and are only with build in types, so everybody can known what they are mean. But with custom op. you have to study each new interface.

It's the same reasoning why the named constructor idiom is a good practice. Because ctors. are like operators, they don't have a name, so you can't state clearly what the code means. Point p1 = Point::rectangular(5.7, 1.2); // Obviously rectangular

Ahhh. I forgot about the macro problem. I wish I could mod you up, but that's against the rules.

For those not in the know, macros are interpreted very literally by the preprocessor. A macro with multiple lines in it generally requires a stupid trick like enclosing the code within a do { ... } while(0) to prevent just this problem. Or a if (true) {...} else (void)0.

Ugh. See this for more info.

The C++ FAQ can be quite an eye opener in that regard:

Why is cos(x) != cos(y) even though x == y?

The only time when using == with floats should be ok, is when comparing it to zero and only then if the zero comes from a direct assignment, instead of a calculation, i.e.:

float x = 0.0f;
if (x == 0.0f) { /* do stuff */ }

But even then its bad practice, as its abusing 0.0f as magic number, which should be avoided if possible.

C++ FAQ Lite

I used this site a bunch when I found myself doing some c++ work after almost exclusively working in java.

I say that, because I was asking myself pretty much exactly those same questions just a few months back.

1. You want to learn OpenGL
2. You want to broaden your horizons to C++

Both are good goals, but they're also two distinctly different goals.

Pyglet is a simple python gaming library that is an excellent resource for learning OpenGL. You get all the goodness of python, yet you're using the same OpenGL calls you'd use in a "real" programming language. It probably isn't stable enough for production, but it's much faster to learn when you have the command interpreter and don't have to wait around for the compiler/linker.

There are other OpenGL implementations for python, but I had the best luck learning by using pyglet. Probably because it's very low level and doesn't hide implementation details like, say, SDL does.

The NeHe tutorials are good for what they are. Like other posters have mentioned, they're a little out of date, and the programming style isn't all that great. But they're good, quick examples of getting something set up and seeing results pretty much immediately. Which makes them a good place to start...as long as you remember the grain of salt.

I definitely share your pain when it comes to setting up things like the rendering context, the camera, etc, etc, etc. There are tons of options, the man pages were not written for the beginner. Again, as has been mentioned over and over, the Red Book is probably your best bet.

Learning C++ is (really) a different question. I can't recommend the C++ FAQ Lite highly enough. You can find their recommendations at http://www.parashift.com/c++-faq-lite/how-to-learn-cpp.html

As opposed almost everyone fussing about "teh M$" and nuances of "freedom", I decided to take a look as see this professionalism.

The first, the first, line I read had a pre-processor no-no. Here:

#define ReleaseStr(pwz) if (pwz) { StrFree(pwz); }

You can read all about it here: http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-39.4

Here's how it doesn't work:

if ( something )
        ReleaseStr(pwz)
else
        foobar;

So there. The code might look professional. It might but it doesn't mean that it is.

(I should probably keep this in a text file on my desktop, it's a "batch of advice" which I frequently have to re-write, and it doesn't change much)

I mentioned the term "modern C++" above, though really it's better to call it "sane C++". By this I mean C++ that won't drive you nuts trying to figure out what went wrong, when something inevitably *will* go wrong. Practices that make programs more safe, and introspective.

If you already know C++ (the foundations, I mean), it'll be easier to shift to STL-dependent C++. If you're completely new to C++, these resources will still be very important, but you'll need to learn the lower-level stuff in parallel, so you can understand how STL containers/templates are built from the inside (which is important when you need to choose which ones to use).

A website that should very often sit in the background while you're coding/learning: C++ FAQ Lite. Following these rules will make it much easier to design and maintain your programs.
Another very useful website: cplusplus.com. It's a huge reference site, with a lot of examples.

The books I'd recommend:
Accelerated C++ -- higher-level to lower-level approach.
C++ Coding Standards -- similar to the C++ FAQ Lite in the nature of the advice, but covers more ground and is probably better organized.
C++ Common Knowledge -- This is for a few months down the line, delves into some nuances.

Software:
Windows: Visual Studio C++ Express -- You can force it to stick to ANSI C++. It's still the best IDE for C++ on windows (IMO).
Linux/Mac: Eclipse, probably Eclipse IDE for C/C++ Developers. Remember though that you can tweak Eclipse into just about anything.

If you're writing end-user applications, keep in mind two frameworks: Qt and wxWidgets.

Quick note about Boost: If you can create a structure using some combination of STL components, do that before resorting to Boost. Boost is highly abstracted, and you should only use the parts which would otherwise be extremely complicated to create from scratch (like regexp).

Poorly thought out argument.

Any policy needs to consider desired effects and undesired effects. In this case we have the contention or thought that allowing someone to play a video game depicting an action might increase the chance that that person will engage in that behavior in the real world. There isn't strong evidence that this is the case, so it's possible that outlawing virtual child pornography will have absolutely no positive effect.

On the other hand, forbidding virtual child pornography is a form of censorship. Child pornography, virtual or no, is pretty fucking creepy, especially depicting the rape of a twelve year old. It's probably hard to make the claim that this software is a form of artistic expression deserving of protection. But forbidding virtual child pornography will have chilling effects on artistic expression. When Nabokov wrote Lolita, he caught flak for it, but he was a respected author, and it has an obvious artistic merit, so it was accepted as art relatively quickly. When Crumb started doing his stuff, people thought he should be locked up. It was certainly more extreme than Nabakov's stuff, and it was in a medium - comics- which most people didn't consider an art form. But now Crumb is a pretty well respected artist. Some of his stuff is very clearly disturbing virtual child pornography. It involves parents having sex with their kids, a guru getting his dick sucked by a giant 18 year old baby with monster tits. It's really disturbing and creepy. It's also a powerful interesting look into some of the more disturbing aspects of human nature and deserves to be considered art.

Right now interactive entertainment has a hard time getting taken seriously as an art form. Just like comics are treated very differently from novels at the judicial level, so too are video games. But any medium can be used as a medium for artistic expression, and all forms of artistic expression or communication (free speech, remember that?) deserve protection

If I start a blog advocating reducing the age of sexual consent to 12, and actively work to that goal, maybe start a forum discussing the morality of sex with 12 year old boys, that's pretty creepy disturbing behavior. It might increase the chance that some middle aged middle manager starts raping little kids. But a strong democracy requires us to tolerate even that kind of speech. Remember everyone, Hitler and Stalin included, supported free speech as long you said what they liked to hear. Free speech means tolerating speech you don't like. If you are censoring speech because it's creepy and disturbing to your sensibilities, you no longer have free-speech.

Finally, it's dangerous to make policy based on obscure, touchy feely emotional reactions. It's not clear at all what effect legislating against virtual child porn will really have. For example, there may be merits to softening the taboos associated with depicting child rape. Free expression of such themes might make it easier for people with harmful appetites (i.e. the desire to have sex with kids) to seek help. It might make it easier for victims to seek help and report abuse. Censoring virtual child-porn will also censor graphic, disturbing depictions which have an anti-child-rape message.

Looking at the example of violent video games: I'm a total pacifist, vegetarian hippy type. When I find myself frustrated by life (don't we all), I find playing violent, horrible video games a terrific release from my stresses and frustrations. It's harmless way to exorcize my violent tendencies. Who's to say that video games can't be used in a similar fashion?

As a general rule, Censorship is evil, and should only be applied to situations where there is a direct, observable, harmful impact: shouting fire in a crowded room, real child pornography, etc.

the reason that you can do this is because you have destructors

Let me rephrase that for you: the reason you have to to do that is that there's no other way to guarantee that anything will be called, specifically: if an exception is thrown.

RAII is the poster child of making a virtue out of a necessity. The fact is that the only guarantee C++ makes WRT exceptions is that destructors will be called, meaning that the only way to reliably close() anything is to put it on the stack. I guess we should be glad that there a way to do it at least, but that doesn't hide that:

a) you can't throw an exception from a destructor. Well, you can, but on real systems where your object is going to get wrapped into other RAII's object, you'll end up with a core dump. There's no such problems with close() methods because, one, you can always reliably catch exceptions in Java as opposed to C++, and two, you still the finalizer to clean up. Reference

b) the siblings explaining how close() "break the abstraction" or destructors allow you to "release [...] at the exact moment they are not used anymore" make me laugh. At the exact moment is what close() does. To do the same in C++ you have to wrap the code in an "artificial" block so that the destructor gets called when you want to instead of when you return, 5 minutes later. Which incidentally breaks the whole "abstraction" business - as if pretending a disk, or worse, network, resource with an access time of the order of 10 ms was 5 orders of magnitude faster memory ever was a good idea - because now you have this block standing there for no obvious reason. At least try/catch/close makes is self describing.

If you used an std::vector, you couldn't have a bottleneck, for the simple reason that the std::vector is an array.

There might be systems on which this is true, but not on the c++ libraries on my mac. When I was trying to figure out what was going wrong with my vector-based program, I got to look at a lot of vectors from within gdb, and they have a neat bucket system going on that I'm sure is very fancy and clever, but let me tell you, it is not just an array, and good luck figuring out from the data alone what is stored in it unless you already know an awful lot about the underlying implementation...

The storage for a std::vector is required by the C++ standard to be an array. See http://www.parashift.com/c++-faq-lite/containers.html#faq-34.3

Here's what I got, so far. Sorry it's not tabbed and cross-referenced...

http://ask.slashdot.org/article.pl?sid=08/09/17/224230 -- in case anyone wants this page, too
http://www.quickref.org/
http://gotapi.com/
http://www.regular-expressions.info/ -- regular expressions
http://www.perlmonks.org/
http://www.rosettacode.org/wiki/Main_Page
http://perldoc.perl.org/
http://www.perlbuzz.com/
http://java.sun.com/reference/
http://forums.sun.com/index.jspa
http://developer.mozilla.org/ -- javascript
http://www.w3.org/MarkUp/Guide/
http://www.w3.org/MarkUp/Guide/Advanced.html
http://www.w3.org/TR/html4/
http://www.w3.org/TR/xhtml1/
http://www.w3.org/Style/Examples/007/
http://www.w3.org/Style/Examples/011/firstcss
http://www.w3.org/Style/CSS/learning
http://en.wikibooks.org/wiki/Programming:Tcl
http://www.acm.uiuc.edu/webmonkeys/book/c_guide/
http://cprogramming.com/
http://www.cplusplus.com/
http://cm.bell-labs.com/cm/cs/cbook/
http://www.parashift.com/c++-faq-lite/
http://en.wikibooks.org/
http://developer.apple.com/
http://cocoadev.com/
http://www.cocoabuilder.com/

http://www.parashift.com/c++-faq-lite/ A great place to start when you're stumped.

C++ FAQ Lite is an excellent site for C++ information.

Wow, I'm not sure if you did it intentially, but you linked to the C++ FQA, *not* the C++ FAQ. I'll assume from context that's what you meant, and just labeled it wrong.

In any case, both are very useful reads:

http://codemines.blogspot.com/2007/10/no-updates-for-6-months-then-two-in-day.html
http://www.parashift.com/c++-faq-lite/
http://yosefk.com/c++fqa/index.html

If the constructor throws, the memory gets cleaned up automatically.
Don't write destructors that leak exceptions.
Just don't.

For example, if you declare even one virtual member function, you HAVE to declare your destructor virtual.

I don't know where you got this idea. If you have virtual member functions, you probably want a virtual destructor, but it's neither a requirement, nor a given.

From the C++ FAQ lite, read [20.7] When should my destructor be virtual?

In case anybody got confused, that's FQA above, not FAQ. This is FAQ: http://www.parashift.com/c++-faq-lite/index.html

You're welcome, Bruce. Mr. Kreinin explains the issues with C++ much better than I could.

For those who don't know, the main part of his site is the C++ FQA Lite, which is meant as a commentary on Marshall Cline's C++ FAQ Lite.

I refer to both sites whenever I have to program in C++.

I agree. It was probably not a good decision in the first place to make C++ compatible with C. That's one of the factors that led directly to the entire unwieldy context-sensitive C++ syntax. The sad reality is that if a language is difficult for the compiler to understand, then it will be difficult for the programmer to understand. As the specification grows, I become more and more convinced that C++ is a puzzle where the object is to try to figure out how to be productive using the language.

I don't doubt that it had a definite effect. Making an entire OS in the early days of C++ is not something that sounds like a good idea. I think that most of the blame lies directly with the choice of index card color, however. :)

Many programmers do not understand the importance of different rounding rules, and even think that add .5 then truncate is always correct.

Please to explain when adding .5 to a floating point number and truncating to an integer does not correctly round up. Is this going to be one of those platform-dependent problems like y = x; cos(x) != cos(y)? If this is a bad method of rounding up, what do you suggest?

Don't use macros. Macros are evil. A roving band of them kidnapped my parents when I was young.

We now return you to your regularly scheduled topic.

I wouldn't say Java has "strong typing". It's stronger than C, but it has some nasty flaws:

1. Strings and integers can be added together.
2. A parameter or other variable of object type (or rather pointer-to-object type) can always be null, so far as the language is concerned. This weakens the type invariants of any pointer-to-object type. Worse, it encourages the use of null as a special case whose implementation is scattered across users of the class, instead of the null object pattern.
3. int can be coerced to float, losing precision. There are no run-time checks against this.
4. There are no static or run-time checks against integer overflow.
5. A value of type A[] can be converted to type B[] where A is a subclass or implementer of B. However, a container-of-subclass is not a container-of-superclass unless the container types are immutable. Any attempt to assign an object of type B into an array-of-A that's pretending to be an array-of-B will result in an ArrayStoreException at run-time. The same problem applies to other container types, not to mention the pre-generic containers-of-Object.

Not that Java is particularly bad in this. Comparing with my favourite languages: C++ has problem 1 for the built-in string type (but not std::string) with weird semantics, a worse version of problem 3 (narrowing numeric conversions are all implicit), and a worse version of problem 4 (undefined behaviour on overflow); Python has no static type checking at all, so it suffers from problems 2 and 5 (though entirely dynamic type checking aka "duck typing" can be a very useful feature if you get used to it).

The point I was getting at is much better detailed in the C++ FAQ at http://www.parashift.com/c++-faq-lite/const-correc tness.html#faq-18.12 -- const overloading is very easy to get into trouble with because it breaks virtual overrides easily and without warning.

It does nothing of the sort. The use of so-called const-overloading is a natural consequence of the concept of const correctness, which in turn is a simple yet powerful idea that prevents several otherwise-common classes of programmer error. I have never in my life "got into trouble" with this concept, and nor has anyone else whose code I've reviewed. If you really think this is a problem, perhaps you should stick with C#... or maybe knitting.

yes, my example was made up as I typed so it would of course not compile. I though the reader would use their imagination to understand the problem I was hinting at instead of nitpicking about adding things like public: qualifiers which would have made the example longer. The point I was getting at is much better detailed in the C++ FAQ at http://www.parashift.com/c++-faq-lite/const-correc tness.html#faq-18.12 -- const overloading is very easy to get into trouble with because it breaks virtual overrides easily and without warning. It's a definite misfeature, and newer (and frankly better designed) programming languages like C# makes it impossible to make this mistake.

You are mistaken.

See http://www.parashift.com/c++-faq-lite/containers.h tml#faq-34.3

Yes, standard c++ and standard C define a byte as the minimum addressable unit and sizeof(char)==1, but there are some non-standard compilers, especially on exotic platforms.
Example: the CPU in an HP48 addresses 4-bit nibble, not bytes. The operating system handles pointers to nibbles, but a char needs at least 8 bits, so a pseudo-C compiler for that platform might have sizeof(char) ==2, and a special nibble type where sizeof(nibble) ==1. It's non-standard, but not everything out there is standard...

Why are you throwing by pointer?
http://www.parashift.com/c++-faq-lite/exceptions.h tml#faq-17.8

• Write unit tests. Make a policy to include one test for each new function/method introduced to the base code.
• Run Valgrind tests on the unit tests periodically.
• Use Smart Pointers, maybe from Boost. Do not allocate new naked (regular) pointers in the heap.
• Re-use code. Re-factor as much as possible. Do not allow for large, obscure, zillion-line functions.
• Use well known, well debugged libraries such as the stlport (for STL) as much as possible. Maybe Qt.
• Be const-correct. Pass const-references as much as possible.
• Make simplicity and readibility of the code a strong requirement. Good code should look damn clean.
• Don't ask in ./, we are a bunch of asses after all ;-)

Do not refer to "C/C++." Some people get testy about that, and will (unfortunately!) ignore everything else you say just to correct you with something like, "There is no such language." It borders on pathetic, but you'll probably be okay if you say "C or C++" instead of "C/C++." Sigh.

My bad, it was here that I saw it: http://www.parashift.com/c++-faq-lite/coding-stand ards.html#faq-27.5

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

ur comment Callbacks are everywhere in C++ although these days gives an impression as if, callbacks are part of standard C++ way.

Well, callbacks are a fairly straightforward concept. They're most commonly used in things like GUI programming, where you do a lot of (asynchronous) event handling.

But more generally, callbacks are just a very specific example of functional programming, which is just another style of programming that emphasises functions as first-class elements. And because C++ supports several programming paradigms, you can do object-oriented programming, functional programming and/or generic programming - often all at the same time.

Just like in Perl, there's more than one way to do it. And there isn't any one "correct" way - whatever gets the job done is fine.

If u r aware, OOP was first implemented on pascal (rather than C).

No.

Object-oriented programming is widely recognised as first being implemented on a language called Simula in the 1960s. 1962 to be precise - for Simula I - though Bjarne Stroustrup based C++ most closely on the OO concepts in Simula 67 (1967).

Pascal was first implemented in 1970, though the original Pascal didn't support object-oriented programming.

And Pascal had inherent capability, while C++ did not.

I'm not quite sure what you mean by that. Most implementations of Pascal don't support object-oriented programming at all, much less have "inherent capability". Those implementations that do support OO-style programming usually aren't called Pascal - eg. Delphi, Oberon, Modula-2.

I could go with the list of many things. For example: C++ did not provide any mechanism to identify whether this object is instance of *THAT CLASS*.

You're using your terminology confusingly here, so it's difficult to work out exactly what you're saying. But I can say that I've only seen a few occasions where it'd be useful to work out if Base* p is actually pointing at a Derived object, and usually those cases arise when you've started out with a bad design or bad logic. Usually the whole point of having a (pointer-to) Base is that you're supposed to rely on using Base functionality. You're not supposed to care if it might actually be a Derived, the only thing that should matter is that it is substitutable-for a Base. If you need to access Derived functionality, you should have a Derived.

But anyway, in those cases where you're dealing with someone else's badly designed code, a dynamic_cast should be enough to get around it. Take your Base* and try to dynamic_cast it to a Derived* - if that fails, you haven't got a valid pointer-to-Derived. Go find the person that built the code you're using and kick them. Hard. :-)

here are some C/C++ references. The chip documentation is not public AFAIK, although google picks up occasional hints.

When you say, clean OOP, you must mean, rigid, classical OOP with single inheritance for object-classes and multiple inheritance for abstract-interfaces.

C++ has a much more flexible OOP model. It is just unfortunate that most of it is written off as confusing, evil and/or dangerous.

I used to think C++ had an ugly object model. Then I sat through the C++ FAQ and realised that Multiple inheritance isn't neccessarily evil, nor most of the so-called evil C++ bloat.

And now, we have prototype-oriented object models. No classes, just objects. I'm still trying to wrap my head around it, but I have this intuitive feeling that it isn't so bad.

When you say, clean OOP, you must mean, rigid, classical OOP with single inheritance for object-classes and multiple inheritance for abstract-interfaces.

C++ has a much more flexible OOP model. It is just unfortunate that most of it is written off as confusing, evil and/or dangerous.

I used to think C++ had an ugly object model. Then I sat through the C++ FAQ and realised that Multiple inheritance isn't neccessarily evil, nor most of the so-called evil C++ bloat.

And now, we have prototype-oriented object models. No classes, just objects. I'm still trying to wrap my head around it, but I have this intuitive feeling that it isn't so bad.

Good references; some potential gems in there. The replies to my above comment seem to think I was being serious. This was not the case. :p

For POD (plain old data), w/o pointers, it's actually a fine code snippet, albeit slightly too general in the event of arbitrary operators '<<' and '>>' overloading. There are several methods to get around pointers and references -- many of which are outlined in design patterns "memento"'s, collectively with "compositors" and "decorators", to implicitly (in terms of design choices) create serialization.

Another often useful reference, C++ FAQ Lite, Serialization is also a gem, I believe, although I had never bothered to read that section.

I am looking at some of the swizzling googles, now.

First off, macros are generally evil. With that out of my system, you're also not quite correct.

Macros are simply 'cut-n-pasted' into the source, then compiled. Thus, no type checking takes place.

There are many reasons you should try not to use macros. Personally, I try to avoid any preprocessing when I can. The C++ FAQ Lite is much better at explaining it all that I. More specifcially, try Reason 1 Reason 2 Reason 3 Reason 4

First off, macros are generally evil. With that out of my system, you're also not quite correct.

Macros are simply 'cut-n-pasted' into the source, then compiled. Thus, no type checking takes place.

There are many reasons you should try not to use macros. Personally, I try to avoid any preprocessing when I can. The C++ FAQ Lite is much better at explaining it all that I. More specifcially, try Reason 1 Reason 2 Reason 3 Reason 4

First off, macros are generally evil. With that out of my system, you're also not quite correct.

Macros are simply 'cut-n-pasted' into the source, then compiled. Thus, no type checking takes place.

There are many reasons you should try not to use macros. Personally, I try to avoid any preprocessing when I can. The C++ FAQ Lite is much better at explaining it all that I. More specifcially, try Reason 1 Reason 2 Reason 3 Reason 4

First off, macros are generally evil. With that out of my system, you're also not quite correct.

Macros are simply 'cut-n-pasted' into the source, then compiled. Thus, no type checking takes place.

There are many reasons you should try not to use macros. Personally, I try to avoid any preprocessing when I can. The C++ FAQ Lite is much better at explaining it all that I. More specifcially, try Reason 1 Reason 2 Reason 3 Reason 4

First off, macros are generally evil. With that out of my system, you're also not quite correct.

Macros are simply 'cut-n-pasted' into the source, then compiled. Thus, no type checking takes place.

There are many reasons you should try not to use macros. Personally, I try to avoid any preprocessing when I can. The C++ FAQ Lite is much better at explaining it all that I. More specifcially, try Reason 1 Reason 2 Reason 3 Reason 4

Not the best site to find a lot of information, but the FAQ on Bjarne Stroustrup's homepage has a lot of good answers to some more arcane C++ questions.

For a more comprehensive resource, also in FAQ format, check out the C++ FAQ-lite by Marshall Cline.

Interesting. However, many experts do disagree with you, including Bjarne Stroustrup and Marshall Cline.

Would you people please stop talking as if C/C++ were a language?

C and C++ are different languages. They obviously belong to the same family, and share a lot of syntax, but each has features the other does not. More importantly, they require different skills to use effectively. Much good C code would be bad style in C++, and vice versa.

Since the whole point of CS is to teach the underlying skills and not any one tool, this is kinda important. C and C++ are no more the same language than C++ and Java, or Java and C#. OK, forget the latter. ;-)

So, for goodness' sake, at least get the most basic information about these languages by reading some of the FAQs, before trying to comment. Pay particular attention to the last one, please; it was written by Bjarne Stroustrup, so it carries even more authority than the others.

You can safely assume that anyone posting about the "C/C++ language" here is neither an authority on C or C++, nor qualified to discuss the languages taught on a CS course.