What do you like in your libraries

Member
Posts: 24
Joined: 2008.01
Post: #16
OneSadCookie Wrote:It's about code correctness. Exceptions hide control flow, and in fact, allow alteration of the implementation of functions you call to change your control flow in unanticipated ways.

Basically, if any function in your app can throw an exception, *every* function in your app must be coded in such a way that *any* exception thrown from *any* function it calls produces a correct result. This is not an easy thing to do, and not an easy thing to test.

I understand where you're coming from but you're talking about global-scope exceptions which are common misuse of the mechanism. A better method is to keep exceptions scoped within a function (ie the try and catch); after all that function will be the most likely candidate to handle the exception. You can then return an error code C-style which the caller can use or ignore. The big advantage is that (within each function) all the error-handling code is one, easy-to maintain block rather than being spread out all over the place in hundreds of if-statements.

Only true 'exceptional' conditions should be thrown - out of memory, disc errors etc. Combined with new() and the standard library (bounds checking etc) they provide a common and consistent error-handling system. You should NOT simply throw exceptions out of a function.

Quote:C++ fanatics might get a kick out of writing RAAI wrapper classes for fopen/fclose, glPushMatrix/glPopMatrix, glBegin/glEnd, new/delete and every other matched pair in order to make their code exception-safe, and introducing a million new scopes to get destructors called at appropriate times, but it doesn't appeal to me.

Again this is a misuse of C++; shoe-horning C-functions into C++ structures. The big advantage of C++ is the ability to hide code, not add to it. Unfortunately a lot of people adopt a 'purist' attitude; if you use C++ you must use ALL of C++ which is simply untrue. C++ can be a 'better' C if nothing else.

Quote:Java more or less gets this right. The most common "matched pair" in C++ is new/delete, and it's not a matched pair in Java due to garbage collection. Most exceptions in Java are used to indicate logic errors, and are not expected to be caught.

I disagree; Java's exception handling is a mess, especially when you introduce threading issues. The very fact that Java does not expect exceptions to be caught overrides their utility by blurring the lines between what does and does not constitute as an exceptional condition. I do miss finally() though. C++ is a strongly-type language where exceptions and const-correctness can save you from yourself.

Quote:Bottom line: with C++ exceptions, code might *look* clean, being in a straight line, but its control flow is probably spaghetti, unintelligible, and hiding hundreds of latent bugs. Maintenance is an absolute nightmare, because whenever you introduce a throw statement, you have to examine every function that could appear in the call chain above this one and check it copes with the new exception.

It's a mechanism that can be abused, as with any language. However, used consistently, it simplifies things considerably. Most IDEs provide the means to break on an exception when it is thrown. All too often I have to work with old code written in C++ in the style of C, where error-returns are ignored, memory allocations not checked, or boundaries-verified. Exceptions provide a means to recover from these situations; without them it's totally up to the individual developer and more often than not it's a crash that occurs far from the offending code.

Quote:There are other reasons to dislike C++ too, such as speed of compilation, size of compiled code, and sheer impossibility of understanding the language, but I think they pale in comparison.

C++ code, written well with templates and careful use of the STL, beats the pants of C code at runtime, and with the speed of computers these days, the cost of the compilation is kinda mute. Why role your own data structures when the pros have done all hard work for you? I agree that C++ is one language that few will ever master - it's always evolving - but gives a level of flexibility impossible with C. Don't like exceptions? don't use them! Don't like STL? Don't use it! How about overloading that operator so that:

a.x += b.x;
a.y += b.y;
a.z += b.z;

becomes simply a += b? If your code has a lot of maths (matrices!) this can become a god-send. And inlined-functions avoid the cost of a function call.

Want to handle memory or check it's usage? Override new() and delete(). What about adding default parameters to avoid having to change every function that calls that routine? Overridden functions? Destructors that are called when objects go out of scope? References and smart pointers?

You can argue that C is 'simpler' and more verbose, but I guarantee you'll end up writing far more code and more code = more bugs, more maintenance, and more hassle. It's taken me a long time to become comfortable with the language and for high-performance app development and standardization, it really can't be beat.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #17
Danny77uk Wrote:I understand where you're coming from but you're talking about global-scope exceptions which are common misuse of the mechanism. A better method is to keep exceptions scoped within a function (ie the try and catch); after all that function will be the most likely candidate to handle the exception. You can then return an error code C-style which the caller can use or ignore. The big advantage is that (within each function) all the error-handling code is one, easy-to maintain block rather than being spread out all over the place in hundreds of if-statements.

That's not an exception, that's a goto. C's had 'em for years, with less code bloat and less performance penalty.

Quote:Only true 'exceptional' conditions should be thrown - out of memory, disc errors etc. Combined with new() and the standard library (bounds checking etc) they provide a common and consistent error-handling system. You should NOT simply throw exceptions out of a function.

I'm confused. You should throw exceptions you have no intent of handling (why not just crash, it's all the same to the user?), and you shouldn't throw exceptions that you would handle (what's the advantage of C++ over C?)

Quote:Again this is a misuse of C++; shoe-horning C-functions into C++ structures. The big advantage of C++ is the ability to hide code, not add to it. Unfortunately a lot of people adopt a 'purist' attitude; if you use C++ you must use ALL of C++ which is simply untrue. C++ can be a 'better' C if nothing else.

I don't know what you thought I was saying here. RAAI is a standard C++ design pattern, the only one which solves the "matched pair" problem in the face of exceptions. If you're using exceptions in C++, you're using RAAI classes to balance the matched pairs of operations. It's ugly, and unavoidable.

Quote:I disagree; Java's exception handling is a mess, especially when you introduce threading issues. The very fact that Java does not expect exceptions to be caught overrides their utility by blurring the lines between what does and does not constitute as an exceptional condition. I do miss finally() though. C++ is a strongly-type language where exceptions and const-correctness can save you from yourself.

Threading doesn't impact exception handling in the slightest; exceptions never escape the thread they're thrown in.

C++ doesn't expect exceptions to be caught, Java frequently does. I'd vastly prefer that Java *always* required exceptions to be caught (everything becomes a checked exception) but it's still a better situation than C++.

C++ is a weakly typed language which lets you do anything you want (including crash) with a simple cast to void*... Java is strongly typed, and an immutable object is better than a const-correct object any day.

Quote:It's a mechanism that can be abused, as with any language. However, used consistently, it simplifies things considerably. Most IDEs provide the means to break on an exception when it is thrown. All too often I have to work with old code written in C++ in the style of C, where error-returns are ignored, memory allocations not checked, or boundaries-verified. Exceptions provide a means to recover from these situations; without them it's totally up to the individual developer and more often than not it's a crash that occurs far from the offending code.

If you've got poorly-written code, exceptions won't help you. At least it's easy to teach people that writing array[i] requires them to assert that i is less than the size of the array. The implications for action-at-a-distance that exceptions have are much harder to communicate and spot.

The bottom line is, if you want safe code, neither C nor C++ is the right language for the job. In either case, the language will assist you in shooting yourself in the foot.

Quote:C++ code, written well with templates and careful use of the STL, beats the pants of C code at runtime

Nonsense. I've yet to meet a C++ compiler that's capable of eliminating the abstraction overhead of C++. The STL is particularly vicious, because it's too easy to make assumptions about efficiency that simply aren't true. std::map is particularly poor.

Quote:and with the speed of computers these days, the cost of the compilation is kinda mute.

To a point. C compilation time is almost negligible these days, C++ takes substantially longer, and encourages you to place more code in headers where it'll further reduce compilation time. The last C++ project I worked on (250k lines) had an incremental build time on the order of 20 minutes. That's not a moot point.

Quote:Why role your own data structures when the pros have done all hard work for you?

If only that were the case. Where efficiency is required, I've had to replace the STL with hand-rolled, optimized versions far too often.

Quote:I agree that C++ is one language that few will ever master - it's always evolving - but gives a level of flexibility impossible with C.

The evolution of the language is not the issue. It's basically been stagnant for the last ten years. The complexity of it is. Can you explain the difference between public, protected and private inheritance? Virtual and nonvirtual inheritance? Give detailed rules about the usage of "typename"? Explain partial template specialization? Explain how the compiler chooses which implicit cast operators to use? It's the most complex language in serious use. Complexity is not a good thing.

Quote:Don't like exceptions? don't use them! Don't like STL? Don't use it! How about overloading that operator so that:

a.x += b.x;
a.y += b.y;
a.z += b.z;

becomes simply a += b? If your code has a lot of maths (matrices!) this can become a god-send. And inlined-functions avoid the cost of a function call.

Operator overloading in math is the only reason I'll use C++ these days. C has inline functions.

Quote:Want to handle memory or check it's usage? Override new() and delete(). What about adding default parameters to avoid having to change every function that calls that routine? Overridden functions? Destructors that are called when objects go out of scope? References and smart pointers?

All "solutions" to problems that don't exist in saner languages.

Quote:You can argue that C is 'simpler' and more verbose, but I guarantee you'll end up writing far more code and more code = more bugs, more maintenance, and more hassle. It's taken me a long time to become comfortable with the language and for high-performance app development and standardization, it really can't be beat.

More code is a bad thing, but C++ doesn't offer a substantial abstraction benefit over C. Most things in C++ can be written similarly briefly in C ("OO" and operator overloading notably aside). As a high-performance solution, C++ utterly fails, because one can't trust the compiler to produce good code from C++ constructs, and when it fails, you end up writing C anyway. The rest of the time, you're paying a massive mental toll to work at such a low level, for no measurable run-time benefit.

You come off as someone who likes C++ only because they have never used anything else. Have you written substantial amounts of code in Ruby? Python? Lisp? Haskell?
Quote this message in a reply
Moderator
Posts: 623
Joined: 2007.09
Post: #18
I've got a solution! You two can build a 3D game engine; OSC in C, and D77UK in C++! I'll judge which one is better!Rasp
Quote this message in a reply
Member
Posts: 72
Joined: 2006.10
Post: #19
OneSadCookie Wrote:Virtual and nonvirtual inheritance?

This little thing right here is a perfect example of what annoys me in C++. The whole language is riddled with constructs that exist only to help people get out of corners they never should have painted themselves into. The same goes with the "friend" keyword or const-casting. If you need to use these things, you are doing something wrong, so why the hell do they exist in the first place? There should be NO WAY to cheat the system.

All these concepts and constructs are useless and downright dangerous because people get used to using them.

- Sohta
Quote this message in a reply
Member
Posts: 24
Joined: 2008.01
Post: #20
OneSadCookie Wrote:That's not an exception, that's a goto. C's had 'em for years, with less code bloat and less performance penalty.

Gotos are evil, evil, evil. I know. I've worked with VB (no exceptions) and I've had to debug them in C. Plus, you cannot throw a 'goto' as there is nothing to throw; nor can you attach data to it. Nor can you use exception-breaks. Plus no-one will ever take you seriously again if they see f**king gotos in your code! Grin

Quote:I'm confused. You should throw exceptions you have no intent of handling (why not just crash, it's all the same to the user?), and you shouldn't throw exceptions that you would handle (what's the advantage of C++ over C?)

A individual function cannot make assumptions as to whether or not an exceptional condition should be handled, or how it should be handled. That's up the caller. If a function cannot handle it, it throws and gives the caller a chance to deal with the situation. You can't do that with goto. Plus, the calling code can ignore an error-return value; it's much harder to ignore an exception.

Quote:I don't know what you thought I was saying here. RAAI is a standard C++ design pattern, the only one which solves the "matched pair" problem in the face of exceptions. If you're using exceptions in C++, you're using RAAI classes to balance the matched pairs of operations. It's ugly, and unavoidable.

I'm not so familiar with RAAI, but in Java, by comparison, there is a new() operator but no corresponding delete() (as you mentioned). This strikes me as crazy. You're totally reliant on the automatic memory management (which is another can of worms that C++ does not impose on you).

Quote:Threading doesn't impact exception handling in the slightest; exceptions never escape the thread they're thrown in.

Try debugging them Rasp

Quote:C++ doesn't expect exceptions to be caught, Java frequently does. I'd vastly prefer that Java *always* required exceptions to be caught (everything becomes a checked exception) but it's still a better situation than C++.

C++ does require exceptions to be caught, even if they're not handled.

Quote:C++ is a weakly typed language which lets you do anything you want (including crash) with a simple cast to void*... Java is strongly typed, and an immutable object is better than a const-correct object any day.

Yes, so how is C any better? C needs casts. There are no references so you have to use pointers with all the danger that entails. Good C++ design rarely requires casts, and where it does, it provides dynamic_cast and friends which are far safer than a C-cast. Immutable is not the same thing as const-correctness. I can pass a pointer as const, but the object itself can be changed and so on. Java does not have this flexibility.

Quote:If you've got poorly-written code, exceptions won't help you.

And what will? Rasp Bad code is bad code in any language.

Quote:At least it's easy to teach people that writing array requires them to assert that i is less than the size of the array. The implications for action-at-a-distance that exceptions have are much harder to communicate and spot.

Not at all. std::vector.at() will throw an exception if the index exceeds the bounds. No assertion is needed. A C array will not complain, and your code will carry on writing out of bounds until the app crashes, sometimes elsewhere. Ditto for new(). C++ is far safer as it was designed specifically to avoid forcing the user to carry out these kinds of checks everywhere as they do in C.

Quote:The bottom line is, if you want safe code, neither C nor C++ is the right language for the job. In either case, the language will assist you in shooting yourself in the foot.

Agreed 100%.

Quote:Nonsense. I've yet to meet a C++ compiler that's capable of eliminating the abstraction overhead of C++. The STL is particularly vicious, because it's too easy to make assumptions about efficiency that simply aren't true. std::map is particularly poor.

Then what do you suggest? Role you're own dynamic containers and hope they're faster? The C++ STL has strict performance requirements and you would be hard pressed to best them. Map is slow, I agree, for which std::hash_map exists! Its not part of the standard I admit, but it will be soon. Still std::map is fine for most uses.

Quote:To a point. C compilation time is almost negligible these days, C++ takes substantially longer, and encourages you to place more code in headers where it'll further reduce compilation time. The last C++ project I worked on (250k lines) had an incremental build time on the order of 20 minutes. That's not a moot point.

Citing the superiority of a language by it's compilation time is like comparing Macs to PCs based on how fast they boot (check youtube!). In my experience, slow compiles are the result of poor management of dependencies. Forward declarations and the 'pimpl' method can reduce it substantially. In my day-job, I have to work with code where hundreds of .cpp files average between 1000 and 15000 lines of code (AutoCAD). Through the use of precompiled headers and aggressive forward declarations, it takes about 10 mins max to build the whole thing. And we rarely need to to that. The power and [i]safety that C++ gives you more than makes up for it.

Quote:If only that were the case. Where efficiency is required, I've had to replace the STL with hand-rolled, optimized versions far too often.

I am surprised at that, but then the stl was intended as a generic solution. Still, with careful design and the use of reserve() etc it's possible to write very tight standard code. More often than not, a bad algorithm is the cause of bottlenecks (unless you're writing a ray-tracer or something).

Quote:The evolution of the language is not the issue. It's basically been stagnant for the last ten years.

Rubbish! The latest C++ standard (TR1) will add optional automatic memory management, new container classes, random number generators, hash classes, regular expressions, polymorphic function wrappers and other features common to the Boost library. C, by comparison will never be updated. The only people developing with C commercially these days are embedded-device developers and those poor sods who have to maintain code from 1990.

Quote:Can you explain the difference between public, protected and private inheritance? Virtual and nonvirtual inheritance? Give detailed rules about the usage of "typename"? Explain partial template specialization? Explain how the compiler chooses which implicit cast operators to use? It's the most complex language in serious use. Complexity is not a good thing.

Public - visible to all.
Protected - visible to this class and subclasses only.
Private - visible to this class only.
Virtual inheritance - functions intended to be overridden.
No-virtual inheritance - functions that are not (they are hidden and some compilers will issue a warning).
'typename' states that the name that follows should be treated as a type. Otherwise, names are interpreted to refer to non-types.
Casting is complex, but C++ allows you to use 'safe casts' based on the type of cast, as opposed to C which lets you do what you want, consequences be damned. Type-safety is one of C++'s biggest strength over C.

It IS a complex language in use (that goes with power), but the point is the developer doesn't need to know any of this! You can program in C++ and use C-style casts all you want. You never need to use private or protected. You can take as much from C++ as you like; it does not force any of this on you. Unlike Java or some other languages.

Quote:All "solutions" to problems that don't exist in saner languages.

I would hardly call function overriding, defaulted parameters or destructors 'solutions to problems that don't exist'. Imagine trying to write class-constructors without overridden names! Impossible!

Quote:Most things in C++ can be written similarly briefly in C ("OO" and operator overloading notably aside).

We must agree to disagree. At best you would have to write functions for every operation where a single overloaded operator would do. And as C has no overriding of function names, you'd have to give the same operator a different name for each data type. C has no namespaces so you'd have to use prefixes or something else to avoid possible clashes with other identifiers.

Consider OpenGL's glVertex3f(), glVertex3i(), glVertex3d(), glVertex3v(), glVertex2i()....

In C++, you could have one function, namely OpenGL::Vertex() with a defaulted 3rd parameter. Simpler, no? And every overload could call the same function internally to simplify maintenance. The developer is released from caring about what function to use based on type.

Quote:As a high-performance solution, C++ utterly fails, because one can't trust the compiler to produce good code from C++ constructs, and when it fails, you end up writing C anyway. The rest of the time, you're paying a massive mental toll to work at such a low level, for no measurable run-time benefit.

It can be abused, but it's miles better than the bare-bone semantics of C. I've written template-based class factories in C++ that allow me register and instantiate class-types at runtime without the need to differentiate for every class-type. 1000s of lines of code become a dozen. In C that would be impossible; say hello to type codes and big switch statements. And C has no RTTI for runtime-class introspection... Fun fun fun.

Quote:You come off as someone who likes C++ only because they have never used anything else. Have you written substantial amounts of code in Ruby? Python? Lisp? Haskell?

On the contrary, I started out with C, then python, pearl, VB, prolog (!), Java and then C++. Each language has its advantages depending on what you want to do. In terms of application development (particularly games), C++ is the best I've used.

I'm not trying to convert you back to C++, but rather to give an alternate viewfor other readers of a language that has suffered mainly as a result of lackluster vender-adherence to the standards (*cough* Microsoft *cough*). I suspect a lot of C++ haters are driven be memories of trying to debug templates in VC++ 6.

C is so basic, so limited, that it's like comparing color to B&W. C doesn't even have a 'bool' datatype. But it's as complex as YOU make it. No one is forcing you to use exceptions, even if you call a library that can throw them. Want to ignore the exceptions? Just enclose your apps entry-point (main or whatever) in an empty try-catch. TWO lines of code.

C forces you to think at very low-level; the number of bytes to allocate with malloc, casts and bounds-checking. Even something as simple as writing out data to the console or a file is made error-prone because printf() and friends are not type-save. std::cout et el will output data for any type the defines the '<<' operator. There really is no comparison. Why use C++? Why NOT use it? Wink
Quote this message in a reply
Member
Posts: 24
Joined: 2008.01
Post: #21
sohta Wrote:This little thing right here is a perfect example of what annoys me in C++. The whole language is riddled with constructs that exist only to help people get out of corners they never should have painted themselves into. The same goes with the "friend" keyword or const-casting. If you need to use these things, you are doing something wrong, so why the hell do they exist in the first place? There should be NO WAY to cheat the system.

All these concepts and constructs are useless and downright dangerous because people get used to using them.

I understand that, especially 'friend' and mutable'. But there are occasions, rare occasions, where they can get you out of a bind. We don't always have the luxury of re-writing code he 'right' way.
Quote this message in a reply
Member
Posts: 312
Joined: 2006.10
Post: #22
Yes, I wouldn't mind you releasing your libraries Smile
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #23
Danny77uk Wrote:Gotos are evil, evil, evil.

Not when used as you indicate exceptions should be. Then they're purely local.

Quote:Plus no-one will ever take you seriously again if they see f**king gotos in your code! Grin

Because popular opinion is a good benchmark for what you should be doing? If you believe popular opinion, we should be programming in Java and C#. Not that those are bad choices as such things go (certainly vastly better than C++) but they're scarcely the best choices, either.

Quote:A individual function cannot make assumptions as to whether or not an exceptional condition should be handled, or how it should be handled. That's up the caller. If a function cannot handle it, it throws and gives the caller a chance to deal with the situation. You can't do that with goto. Plus, the calling code can ignore an error-return value; it's much harder to ignore an exception.

Yet you say that exceptions should not be thrown out of functions, only handled locally...

Quote:I'm not so familiar with RAAI, but in Java, by comparison, there is a new() operator but no corresponding delete() (as you mentioned). This strikes me as crazy. You're totally reliant on the automatic memory management (which is another can of worms that C++ does not impose on you).

Garbage collection is not a can of worms, the manual memory management C++ makes you do is a can of worms. When was the last time you had a memory error in Java? Oh wait, you can't, the worst you can do is grow without bound, and even that's hard. When was the last time you had a memory error in C++? In the last ten minutes?

Sometimes GC has a performance profile that's not appropriate (eg. some real-time applications) but my experience is that Java's collector is very good and this is rarely an issue.

Quote:[re: threads and exceptions] Try debugging them Rasp

I did, for a year, on a large codebase I wasn't involved with writing originally. I never had any problems.

Quote:C++ does require exceptions to be caught, even if they're not handled.

Nonsense. C++ exceptions are not checked, and std::unexpected_handler or whatever handles exceptions that are not caught.

Quote:[re: type safety] Yes, so how is C any better?

I didn't claim it was, I claimed Java was.

Quote:Immutable is not the same thing as const-correctness. I can pass a pointer as const, but the object itself can be changed and so on. Java does not have this flexibility.

Java does have the flexibility, though you have to manage it yourself with interface declarations.

C++ is not const-correct, because you're always a const_cast away from breakage. Immutability is absolute, and a much more powerful and useful concept.

Quote:And what will? Rasp Bad code is bad code in any language.

Unsurprisingly, programmers will make fewer memory errors in a language which prevents memory errors, for example. Yes, a good programmer will be a good programmer in any language, and a bad programmer will be a bad programmer in any language, but there is a substantial degree to which the tools help or hinder.

Quote:Not at all. std::vector.at() will throw an exception if the index exceeds the bounds. No assertion is needed. A C array will not complain, and your code will carry on writing out of bounds until the app crashes, sometimes elsewhere. Ditto for new(). C++ is far safer as it was designed specifically to avoid forcing the user to carry out these kinds of checks everywhere as they do in C.

And yet, std::vector::[] is what actually tends to be used, either for performance reasons or because the syntax is nicer. A language where all the "safety" features are one lazy moment away from being broken is not a safe language.

Quote:Then what do you suggest? Role you're own dynamic containers and hope they're faster? The C++ STL has strict performance requirements and you would be hard pressed to best them. Map is slow, I agree, for which std::hash_map exists! Its not part of the standard I admit, but it will be soon. Still std::map is fine for most uses.

No, I suggest if you're using C++ that you use the STL until it proves problematic. I'm just saying that you shouldn't expect that it will be unproblematic in code where performance is sensitive, and performance isn't sensitive, you wouldn't be using C++ in the first place.

Quote:Citing the superiority of a language by it's compilation time is like comparing Macs to PCs based on how fast they boot (check youtube!).

Not at all; my computer is booted once every few weeks, I compile tens of times an hour. Double the boot time wastes a couple of minutes a month, double the compilation time wastes substantial amounts of a working day.

Quote:In my experience, slow compiles are the result of poor management of dependencies. Forward declarations and the 'pimpl' method can reduce it substantially. In my day-job, I have to work with code where hundreds of .cpp files average between 1000 and 15000 lines of code (AutoCAD). Through the use of precompiled headers and aggressive forward declarations, it takes about 10 mins max to build the whole thing. And we rarely need to to that. The power and safety that C++ gives you more than makes up for it.

I don't disagree that our dependencies were poorly managed, however C++ encourages you to write code this way, with templates, inline functions, inheritance, by-value fields, etc. all requiring full inclusion of headers rather than forward declarations.

Quote:I am surprised at that, but then the stl was intended as a generic solution. Still, with careful design and the use of reserve() etc it's possible to write very tight standard code. More often than not, a bad algorithm is the cause of bottlenecks (unless you're writing a ray-tracer or something).

Yes, we were writing high-performance real-time mathematical code. If we weren't, why would we have cared about performance?

Of course the STL isn't *often* a performance problem, 90+% of all code in *any* language will never be a performance problem.

Quote:Rubbish! The latest C++ standard (TR1) will add optional automatic memory management, new container classes, random number generators, hash classes, regular expressions, polymorphic function wrappers and other features common to the Boost library. C, by comparison will never be updated. The only people developing with C commercially these days are embedded-device developers and those poor sods who have to maintain code from 1990.

The C++ standard that's been in development for four years now, having had only one minor update since 1988, and is still not scheduled to be ratified for at least another one year? If that's not stagnant, I don't know what is. Heck, even Java's released new versions in that time.

The people still using C today are the people who care about universality of interface and efficiency of implementation -- anyone who's writing an OS or a library.

The people who are using C++ these days are large companies with products dating from the mid-90s who have sufficient inertia that they haven't been able to move to more suitable languages yet...

Quote:Virtual inheritance - functions intended to be overridden.
No-virtual inheritance - functions that are not (they are hidden and some compilers will issue a warning).

Wrong. It's to do with coalescion of common base classes during multiple inheritance.

Quote:'typename' states that the name that follows should be treated as a type. Otherwise, names are interpreted to refer to non-types.

I'm not entirely sure of this one, but that doesn't explain the situations where you're *not* allowed to use typename, or the situations where it's a synonym for "class"..

Quote:Casting is complex, but C++ allows you to use 'safe casts' based on the type of cast, as opposed to C which lets you do what you want, consequences be damned. Type-safety is one of C++'s biggest strength over C.

I was referring to the "implicit conversion" member functions (operator char * for example).

Quote:It IS a complex language in use (that goes with power)

Depends how you define power. Personally, I define power as the amount of functionality you can get with a certain amount of code, which makes C++ excessively weak. If you define power by execution speed, C++ looks better, but still no better than C.

Quote:I would hardly call function overriding, defaulted parameters or destructors 'solutions to problems that don't exist'. Imagine trying to write class-constructors without overridden names! Impossible!

Funny, Objective C and SmallTalk manage just fine...

Quote:In C++, you could have one function, namely OpenGL::Vertex() with a defaulted 3rd parameter. Simpler, no? And every overload could call the same function internally to simplify maintenance. The developer is released from caring about what function to use based on type.

Perhaps simpler to program for (though the uncertainty of what exactly will happen with a given collection of argument may not be worthwhile) but substantially worse for knowing the runtime characteristics of the function.

Quote:It can be abused, but it's miles better than the bare-bone semantics of C. I've written template-based class factories in C++ that allow me register and instantiate class-types at runtime without the need to differentiate for every class-type. 1000s of lines of code become a dozen. In C that would be impossible; say hello to type codes and big switch statements. And C has no RTTI for runtime-class introspection... Fun fun fun.

Rolling a home-grown object system (c.f. CoreFoundation, gobject, libobjc) in C is work, but once done, tends to provide better infrastructure than C++'s "OO" mess. C macros are remarkably powerful, generic "templated" containers are perfectly feasible in C, with very little more code than C++.

Quote:On the contrary, I started out with C, then python, pearl, VB, prolog (!), Java and then C++. Each language has its advantages depending on what you want to do. In terms of application development (particularly games), C++ is the best I've used.

I'm a little surprised at this, Python and Java are obviously vastly superior to C++ in almost every way. All these languages are very similar, however.

You've notably got no experience in either Lisp or Haskell. Might want to broaden your horizons.

Quote:C is so basic, so limited, that it's like comparing color to B&W. C doesn't even have a 'bool' datatype.

C99 does, actually. _Bool, and #include <stdbool.h> to get bool, true and false.

Quote:C forces you to think at very low-level; the number of bytes to allocate with malloc, casts and bounds-checking. Even something as simple as writing out data to the console or a file is made error-prone because printf() and friends are not type-save. std::cout et el will output data for any type the defines the '<<' operator. There really is no comparison. Why use C++? Why NOT use it? Wink

You're acting as if I'm saying it's sane to write large programs in C, it's not, any more than it is in C++. C is (now) a low-level language for implementing small, performance-critical parts of a system. 90+% of the code will be in some other, higher-level language.

C++ isn't low-level enough (too much abstraction from the hardware as soon as you start using any of its extras), and isn't high-level at all to take up the role for the other 90+%. Why use C++, when another language will be better?

You've said enough now to convince me that you don't understand C++, like it only because you have limited experience with alternatives, and don't understand the experiences you've had. I'm not sure there's any point continuing here.
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #24
Danny77uk Wrote:I'm not trying to convert you back to C++, but rather to give an alternate viewfor other readers of a language that has suffered mainly as a result of lackluster vender-adherence to the standards (*cough* Microsoft *cough*). I suspect a lot of C++ haters are driven be memories of trying to debug templates in VC++ 6.

Well, I for one am not a C++ "hater", but I am not smart enough to use it so it would make little sense for me to recommend others use it (unless I didn't want anyone to talk to me anymore I suppose Sneaky). I will say this though: C++ programmers seem to relish flexibility, no matter what the cost is in complexity. I, on the other hand, value simplicity above all else. My motto is: Less is more! Call it ignorance, but I find beauty in the basics, and C++ just goes 180 degrees against my perception of that. C++ to me is like a fat chick with tatoos and emotional baggage -- she'll do anything for you but she's not welcome to stay past five. I've just had way too many troubles with C++ in the past to mess with it anymore than I absolutely must. Like I said, I don't "hate" it, but I won't use it largely because I *can't* use it, so no C++ library interfaces for me. Sorry.
Quote this message in a reply
Member
Posts: 72
Joined: 2006.10
Post: #25
bronxbomber92 Wrote:Yes, I wouldn't mind you releasing your libraries Smile

That's very kind. However, I have recently realized that there are a number of legal implications that I have to resolve before I can release anything. All the code is mine and most has been written well before my contract started, but I'd like to make sure I'm not getting myself in any trouble with my current employer... I am a professional games developer after all, albeit for consoles, not the Mac. Me releasing stuff, even unrelated to my work, might prove touchy enough that I may not feel like putting myself in any possible future trouble.

- Sohta
Quote this message in a reply
Member
Posts: 24
Joined: 2008.01
Post: #26
Quote:Operator overloading in math is the only reason I'll use C++ these days

So you DO USE C++? Then what are we arguing about? Rasp
Quote this message in a reply
Post Reply