C++ questions

[Daniel Shawul]

This is really ugly.

C++ by itself is already ugly so that's OK

Lucas himself may have said that a month or so ago. But now he is reading a book about it

[kinderchocolate]

Thank you Marco! A very interesting read. I have to admit that Bjarn's book is very well written, and the exercises are very useful.

I started reading the book, thinking that I "knew" C++, and I'll probably finish it realizing that I don't know anything really.

Definitely I maintain that C is a lot easier than C++, and for many applications it is probably more advisable to stick to plain C. But once you start to truly wield its power, then C++ can be very useful. The only problem is that, out of all the people writing C++ code, only a small fraction (including you and excluding me) master it enough to get a benefit out of it.

I think where C++ really shines, is for example, in GUI applications. The OO model is really so well suited to the problem. My first goal is to understand C++ a bit deeper, and play around with GTKmm.

No, No, No, No! C++ and C are the worst programming language for GUI programming!

C# with .Net and WPF/Silverlight is a much better tool.

[mar]

No, No, No, No! C++ and C are the worst programming language for GUI programming!

C# with .Net and WPF/Silverlight is a much better tool.

Good one

[rbarreira]

This is really ugly.

C++ by itself is already ugly so that's OK

Lucas himself may have said that a month or so ago. But now he is reading a book about it

Even if it's ugly it's still worth learning. It can even be fun to program in C++ despite its ugliness...

[Daniel Shawul]

This is really ugly.

C++ by itself is already ugly so that's OK

Lucas himself may have said that a month or so ago. But now he is reading a book about it

Even if it's ugly it's still worth learning. It can even be fun to program in C++ despite its ugliness...

That is what you say when you look at things from outside. I think Lucas is honestly trying to use C++ here and even finds it a great language now. He still thinks C++ is only good for GUI's which it is not (I remember raw windows api and mfc days). Opinions about languages you don't use that much are destined to be biased. So you never know, we may see you appreciating C++ in a month Excuse the swipes I take at you or Lucas, it is light hearted.

[rbarreira]

This is really ugly.

C++ by itself is already ugly so that's OK

Lucas himself may have said that a month or so ago. But now he is reading a book about it

Even if it's ugly it's still worth learning. It can even be fun to program in C++ despite its ugliness...

That is what you say when you look at things from outside. I think Lucas is honestly trying to use C++ here and even finds it a great language now. He still thinks C++ is only good for GUI's which it is not (I remember raw windows api and mfc days). Opinions about languages you don't use that much are destined to be biased. So you never know, we may see you appreciating C++ in a month Excuse the swipes I take at you or Lucas, it is light hearted.

I use C++ every day... I think it's nice if there are good coding standards to force people not to use some of the abominations that C++ permits.

[lucasart]

This is really ugly.

C++ by itself is already ugly so that's OK

Lucas himself may have said that a month or so ago. But now he is reading a book about it

Even if it's ugly it's still worth learning. It can even be fun to program in C++ despite its ugliness...

That is what you say when you look at things from outside. I think Lucas is honestly trying to use C++ here and even finds it a great language now. He still thinks C++ is only good for GUI's which it is not (I remember raw windows api and mfc days). Opinions about languages you don't use that much are destined to be biased. So you never know, we may see you appreciating C++ in a month Excuse the swipes I take at you or Lucas, it is light hearted.

Who knows: maybe I'll become a C++ evangelist some day. But not yet
I'll still respect C forever (RIP Denis Ritchie), even if I someday come to like (or get used to) C++.

[AlvaroBegue]

I used to be a C programmer, but I've been using C++ for over a decade now, and I couldn't go back. There are many horrible things that C++ lets you do that will get you in trouble, including having global variables with non-trivial constructors and destructors . Worse examples are template meta-programming (only for mental contortionists), multiple inheritance and generally abusing inheritance (which most beginners tend to do).

But there are other features that I would have a hard time living without:
* Strings
* Classes that clean up after themselves (for some reason this is called "resource acquisition is initialization", although the name never made sense to me).
* Standard containers

It is also easier to describe interfaces in C++ than it was in C, by specifying what parts of a class are public and which are private.

[wgarvin]

* Classes that clean up after themselves (for some reason this is called "resource acquisition is initialization", although the name never made sense to me).

In the early days of C++ usage, they already had classes with constructors and destructors. And they already had rules that when a local variable goes out of scope (i.e. because control flowed out of the scope) that the variable's destructor is guaranteed to run. Then they added exceptions to the language, and the same guarantee applied: if an exception was thrown anywhere within your scope, it would call the necessary destructors for your local (stack) variables while it was unwinding the stack. Before exceptions were part of the language, it was easy to accidentally exit from the middle of a function without remembering to free some memory (or whatever). But after exceptions, it was extremely easy, because you might not even notice the places where an exception could be thrown. C++ doesn't have garbage collection, so memory leaks were an easy mistake to make. And even if it did have garbage collection, resource leaks would still be a problem.

So an idiom developed, for anything you wanted to make sure you could release safely (i.e. any "resource"). You would make a class whose only job was to hold onto that resource. It would grab the resource ("allocate" it) in the constructor, and release it properly in the destructor. Then you could create a local variable somewhere with this class as its type, and know that it would release the resource safely when it went out of scope.

Anyway, the job of a constructor is to "initialize" objects of that class -- before the constructor runs, you just have uninitialized memory (its not an "object" yet). The lifetime of the object starts sometime around the time it is constructed (its hard to be precise about where.. some people might say "as soon as the constructor has finished" but I don't really know). The constructor "sets up" the memory of the object for use, and the destructor "tears down" that memory. Before construction starts, there is no object. After the destruction finishes, there is no object. The object's lifetime is somewhere in between.

So anyway, that's where the "RAII" name comes from. Its an idiom where you make a class that does "resource acquisition" during its "initialization" (construction), and it releases that resource during its destruction, and the reason you would do this, is because the compiler will destroy your RAII object for you at the proper time (which means it will release the resource for you at the proper time).

Not all resources have life-cycles that can be managed like this -- you might need to keep them around for use by other code -- but when they do, it can be helpful. At work, we use it a lot for things like locking threading primitives (if you do it with RAII, you know they will always get unlocked) or starting/stopping profiling timers (same reason). You can also make smart-pointer templates, etc. to get these kind of benefits for heap-allocated objects without losing type safety. You can even make ways to "steal the resource" from the object if you need to extend its life-cycle -- the important part of RAII is that the default behaviour is to free the resource for you in the destructor.

If you think about it, every STL container class (std::string, std::vector, etc.) will free whatever heap memory it is using when the object is destroyed. That's one of the things that makes them so convenient to use -- you can declare them as locals, you can pass them around by reference or even by value, and you never have to worry about them leaking their memory. RAII just brings you the same convenience with any other kind of resource you might need to keep track of.


[Edit]: So to summarize: "resource acquisition is initialization" describes the first half of the idiom, where you grab the resource somehow in the constructor of your RAII object (or when you have a resource, you immediately pass it to the constructor). The reason you do this, is because the compiler is going to call the destructor for you at the right time, so your resource is now "safe from being leaked", even if you return from the middle of its scope (or an exception gets thrown somewhere in its scope). More generally, RAII is a label for a style of programming where you don't keep ownership of resources in "unsafe" local variables such as raw pointers. You can still use raw pointers, but by making an RAII object to own the resource, you get the guarantee that the RAII object will get destroyed at the proper time, and it will then release the resource for you.

[Daniel Shawul]

I use RAII for automatic de-allocation of big vectors. For that I needed to use a lot of nested braces just to put a variable out of scope. At first this looked odd for me but if I used C that forces declaration of all variables at the beginning of functions it would not have run at all due to memory constraints.

Another difficulty with C++ vector/matrix calculations is the number of copy objects it creates. It is not easy to figure out how many copies are being used for a given field equation. Is it using copy constructor,passed by reference etc. With this two combined ,you can save a lot on memory that you need at a time. You can have 20 big vectors but it may be that you need only 3 of them at a time. A naive programmer may need 13 of them ..

Yet another difficult with C++ in vector calculations is making it as fast as fortran. For example a simple C = A + sqrt(B) where A and B are vectors will not be as fast as for(i) {c = A + sqrt(B)). That required some nasty template metaprogramming to achieve same performance. The first version that requires copies was 3 or more times slower IIRC.

Another alternative is use of smart pointers to do garbage collection.