There is probably no language right now that is truly ideal for thinking in these terms.

2004-11-26 8:07 am

“[…] we spent most of the semester saying ‘now I know C++ does this, but you should avoid it like the plague’.”

Out of curiosity–could you say a little more about those issues?

2004-11-26 11:04 am

1) It’s far too flexible, so much so that it’s pretty multi-paradigm: C++ programs can be in the C-With-Classes Style; the Java style; or lately the STL/Simula style which is like nothing else out there, and takes a lot of getting used to. This means you can be a good C++ programmer and still find it quite hard to follow a C++ program.

2) C++ provides exceptions, but they’re vulnerable to all sorts of allocation errors because C++ doesn’t provide a “finally” block to take care of resource de-allocation when exceptions are thrown. Delphi, Java, C#, they all have finally blocks. See this for more: http://www.octopull.demon.co.uk/c++/dragons/index.html

3) C++ was developed before multi-threading was the norm, it lacks the built-in support most other modern languages have

4) C++’s complexity means there are several very tricky situations a programmer can find themselves in, which can lead to awkward bugs. E.g. to cast something you can use five different methods: either the C cast or one of dynamic_cast, static_cast, const_cast or reinterpret_cast. This complexity also means that most compilers don’t completely follow the standard.

5) The language doesn’t come with a core standardised class library. While the STL should plug this gap, it’s implementation by compiler manufacturers can sometimes leave stuff to be desired, and its comparitive strangeness these days means that programmers often use other class libraries instead.

6) C++ allows operator overloading, but provides very little control over how operators are overloaded, which can result in difficult to read code by people who get carried away with their own sense of genius (I’m really not a fan of operator overloading).

7) C++ doesn’t have any sort of easy memory management. And for people who think garbage collection is slow, consider the overhead as several destructor functions call each other every time an object is deleted. Some programmers advocate creating object pools, but surely this sort of stuff should be provided by the langauge itself

Now, before the flames commence, I should state that it is possible to program C++ well, and that it can be used to great effect. The problem is, it’s extraordinarily easy to write quite bad code with it as well. Other languages (Delphi, Java, C#) are a bit more polished and easy to use.

2004-11-26 11:45 am

disclaimer: I am a C++ guy.

my nit to pick (I agree with most of your points): “finally” is not needed. destructors are finally. resource acquisition is initialization, resource release is destruction. this makes quite readable and efficient progs.

2004-11-26 2:10 pm

i’m a java programmer but still don’t know what “Javolution” is and what it suppose to do could someone explain what it is and what it does?

thx

2004-11-26 2:47 pm

as far as i understand The key difference is, there is no Garbage Collection, which ensures the predictibility of the timing of the applications and threads. Real time applications has to conform that processes must be react in a certain and defined time delay. Actually modern garbage collectors (like Java5’s) has much little impact than the previous models to the application, but stil there is no guaranty for timings and impact of the colection. Also this library provides faster string manpulation and Collections, but this has nothing to do with being real time. However, i am not sure if you can use other java libraries together with this library.. i mean there must be a drawback.

2004-11-26 2:59 pm

Actually being real time is not only related with JVM or the garbage collection. Operating system should be real time too. So, ths library is more suitable for real time OS’es.

2004-11-26 3:03 pm

You’ve got a point, other options include declaring vulnerable objects on the stack or using auto_ptr<>. This comes back to the central point, though. You’ve got to know an awful lot to use C++ well, and a there’s a lot of people who for various reasons, including the simple lack of time, don’t.

2004-11-26 3:20 pm

Addition:

– stlport

– boost

using this stuff (consequently), a lot of the problems you mentioned can be avoided…

Still you have a point and i find myself ditching c++ for python et.al. more and more…

2004-11-26 3:27 pm

In my opinion, the Garbage Collection in Java5 still seems like what it was in the first version of Java…I really think they need to rewrite that part of Java from the ground up; because esentially the Garbage Collection is what is giving Java so much memory usage. I will of course try Javolution to see how it compares to vanilla Java.

mv * > /dev/null

2004-11-26 4:44 pm

As for point 7, “having destructors being called all the time can take some time”, remember that in C++, most temporary objects live on the stack, and have their code inlined. I guess a small enough instance is even likely to end up in registers.

Contrast this to java which throws everything on the heap (ok, I guess a smart jvm can avoid some of these, but given how slow and memory consuming java apps often turn out to be, I have my doubts regarding this)

My point is that construction/destruction of small objects amount to nothing in the compiled code. Of course, if you routinely create huge amount of objects on the heap and destroy them, then yes, destructions are going to be painful.

The other problems you mention, like too much flexibility and stuff hilight the fundamental philosophy difference between c++ and java: where C++ just give you a lot of tools and the freedom to do what you want with them (including shooting yourself in the foot if you’re so inclined), java locks you to what their designers consider to be the be all, end all programming techniques and style: only OOP to do everything, garbage collection, etc.

As for your second post, “you have to know a lot about c++ to use it correctly”, I think it’s the real curse of c++. If the c++ courses I had at school as well as the way peope I knew from other schools programmed, too many people don’t think of it as something more than just C with classes…

So, they either don’t bother teaching properly if they’re teachers, and they just reuse mostly the same techniques they used in C.

2004-11-26 5:15 pm

well if thats the only thing not much point because u can disable the garbage collector in the jvm anyway!

2004-11-26 5:24 pm

Thats why for driver development and kernel development we stick to C. C gives much better control on memory management and code execution.

C++ is good for user mode programming. I agree that C++ syntax is too flexible but then “With great power comes great responsiblity” C++ programmers like great power and C++ gives you that great power with its flexible syntax. A good programmer would never like to be tied down with language symantics like Java. C++ has a best practices approach if u want to write too pure code but it lets you do things as you want and thats what i like. To be in complete control.

The ONLY thing i prefer in Java over C++ is finally block. I really think that stroustrup should have added it, instead of forcing his mentality on people. Thankfully Microsoft’s Visual C++ added structured exception hadnling which has finally block and i love it.

2004-11-26 5:41 pm

The ONLY thing i prefer in Java over C++ is finally block.

RAII is the way this is handled in c++. Once you have a RAII container for a resource, you shouldnt have to worry about it again, just use this container and cleanup is “automatic”

2004-11-26 6:12 pm

Man, get out of the 90’s.

2004-11-26 6:26 pm

I know that post already and thats why i said, “I really think that stroustrup should have added it, instead of forcing his mentality on people.”

I believe its bull. Many people won’t like to manage their points using auto_ptr and crap. Resources are not only files and I dont want the resource to be freed all the time when the object gets destroyed. I want control. I want a function whcih will be called when my function is exiting and to have this, i need a finally block.

The usual practice now we do to avoid this kind of problem is to have a single exit point from the function and do our cleanup there.

2004-11-26 8:16 pm

>> I know that post already and thats why i said, “I really

>> think that stroustrup should have added it, instead of

>> forcing his mentality on people.”

and instead force the finally to the people ??

>> I believe its bull. Many people won’t like to manage

>> their points using auto_ptr and crap.

ok, the the auto_ptr semantics are slightly of ( ‘=’ for change of ownership instead of assignment), but that doesnt change the underlying and in my opinion very good system.

Maybe there are also people that dont like “finally and crap” ( havent used java much so cant say something about that

(btw i think teh boost libary has some ‘better’ RAII containers)

>> Resources are not only files and I dont want the resource

>> tobe freed all the time when the object gets destroyed.

then dont destroy the object ?

>> I want control. I want a function whcih will be called

>> when my function is exiting and to have this, i need a

>> finally block.

guess when dtors of locals are called … right, at the and of the function

>> The usual practice now we do to avoid this kind of

>> problem is to have a single exit point from the function

>> and do our cleanup there.

no, the practise is to let the destructor of local objects do the cleanup, then you can jump out of your funvtion where you want ( if you want … there are other reasons why you want one single exit point, for example its easier to prove algorithms that way ( i believe ))

if you have dependencies between your resources (that is ‘a’ should be released before ‘b’ ) then you should pack these into a object that handles these dependencies.

if you feel the need to not release a resource in the fuction where you got it then this is even more a reason to make an object around this resource. thats what objects are for, to handle some internal state, like the status of a resource.

or you might even rethink about your design as in my oppinion resources should only be taken in the smallest scope possible. not releasing resources where you get them might be a sign of unwanted or unneeded coupling somwhere in your design.

( and my apologies for helping to turn this java thread into a c++ thread, i will shut up now )

2004-11-26 9:26 pm

1. I was not saying or asking to force finally. I want to have an option of having finally in the language.

2. A legitimate use for finally is when on a failure u want to free some of the global pointers and for other failures u want to free all the global pointers allocated in that function. If you have finally block, you can simply set the error code and say return and you are guranteed that you will get a chance to do cleanup.

By the way dtors of objects are called at function return, there is nothing per function. Another simple use for finally can be function exit logging. If you use a try block from start then you are gurantteed that your function has only ONE exit point. Its so much more useful.

What is it which makes you feel that addition of finally will be bad…after all its optional to use it. Can you give some specific points where finally will cause problems?

Stroustrup forced his mentality because he thought finally is not needed, everything should be an object but not, sorry it doesn’t work like that. I hate him for not adding finally in C++, what would you lose by adding it? Microsoft added it to their C++ http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vc… . Programmers need all the tools to use them in a way which makes things efficient for them.

2004-11-26 9:37 pm

in C++ you can have dtors run before the end of the function: by setting the object’s scope with those curly braces’ {….}’

Dtors will be run at the ending brace, no matter what.

2004-11-26 9:47 pm

The author must be kidding when sez that J2EE containers can benefit too. Container typically run lots of threads, are complicated pieces of software that allocate as little as possible, but still have to do it at lots of place.

You will not prevent GCs while your code is being run!

Real time is all about predictability. What about the rest of the stack, OS, drivers, protocols?

What is the latency in java? What about locks priority w.r.t thread priority?

Now if the author meant performance, a run of java -jar javolution.jar perf yields: