Advantages of c++?

[DemonLoad er]

Sometimes i think if (Turbo)c++ is not gonna be of any use to me in future, and i feel as if i'm wasting time studying it

Is it so?

Or is it gonna help me in future?

I mean, it's pretty old, and doesn't have a good memory usage and all that...

So i just wanna know if it is worth the time i'm spending studying this?

[Catfish4]

Sometimes i think if (Turbo)c++ is not gonna be of any use to me in future, and i feel as if i'm wasting time studying it

Turbo C++ is a tool for the C++ language.

C++ has versions just like software:

- C++98 (the first version, from 1998)
- C++03 from 2003
- C++11 from 2011
- and upcoming C++14 of 2014

A version of C++ is called a "standard".

Of course, if you want to learn to write code in the newest standard of C++ (the language), Turbo C++ (the tool) is the wrong choice because it's very old.

Or is it gonna help me in future?

That's up to you. There are many other languages besides C++, each better or worse suited to helping you achieve what you want to achieve. It's up to you to choose your expertise, and then the language that helps you most.

C++ is a popular choice when program performance is important; for example computer games.

So i just wanna know if it is worth the time i'm spending studying this?

I think yes, because things you learn while programming in C++ will apply to other languages as well, so you won't start from absolute zero when you decide to pick up a new language.

For instance, if you learn C++ well, moving to a language such as C, or D, should be very easy because they share a lot with C++.

[jwkNwA7f]

^ +1

[o1vk4iN6]

doesn't have a good memory usage

That's not the fault of the language but of the programmer. Any programming language can in some way misuse memory if the programmer says it to be so.

[Computergeek01]

... doesn't have a good memory usage.

How do you figure? C++ allows DMA, that literally means you have direct control over the memory you allocate and manage with in your application. Have you studied RAII?

[DemonLoad er]

...you won't start from absolute zero when you decide to pick up a new language.

That's something i didn't have in mind. Thanks for the info :)

Have you studied RAII?

Never heard of it before.
I'll check on that soon :)

[Catfish4]

RAII (Resource Acquisition Is Initialization) is an uninspired name for taking advantage of the fact that the destructor of an object gets called automatically when the object goes out of scope or an exception is thrown. (Sounds like advanced stuff but really isn't.)

http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

Computergeek01 brought this up because he thought you were talking about how in C++ memory is managed manually (which is otherwise a valid criticism of a language that dares call itself "high level").

[Computergeek01]

How is manually managing memory a problem? I've heard this before but it's always from Java aficionados and the like. If you can manage to type a close bracket around a statement or function then you're smart enough to remember to type 'delete'. I've just never understood how this is a criticism.

[Disch]

If you can manage to type a close bracket around a statement or function then you're smart enough to remember to type 'delete'. I've just never understood how this is a criticism.

The compiler will complain if you forget your closing bracket.

The compiler will not complain if you forget your delete.


People make mistakes. Mistakes that lead to very difficult to find runtime bugs (like memory leaks) are a lot more common than people think. Especially when working in a team.

To do it effectively, the team has to outline very strict rules regarding how memory is managed by the program, and all developers on the team need to be aware of those rules and follow them to the letter 100% of the time.


This gets more complicated when you start using libraries that may have their own way of allocating memory. Things like WinAPI where it's not about forgetting a delete, but is about forgetting a DeleteObject(x);


So basically.. there are a LOT of pitfalls to managing memory manually. And they happen frequently. And they're difficult to find/fix when they happen. So if that can be made to be more automated, it is a "good thing".

[LB]

EDIT: This post is directed @Computergeek01

It is more than likely that on average a given function will have more ways to exit than by running the last few delete statements and getting to the closing brace. Exceptions, early returns, error cases, having to keep track of which resources you did and did not allocate, all a nightmare.

If you have a case where it's as simple as remembering to write delete before the closing brace, then why are you even using pointers and dynamic memory at all?

[Cubbi]

all developers on the team need to be aware of those rules and follow them to the letter 100% of the time.

Developers don't program in vacuum - there's the guy next to you, there are whiteboards, meetings, and there are code reviews (which, incidentally, I reject if I see even one "delete")

[Computergeek01]

I don't know if your WinAPI example was just an off the top of your head choice or if I'm just in a pedantic mood but things like HANDLE's and sockets aren't (or at least they shouldn't be) treated\used the same way dynamic memory is. They only exist the way that they do because the WinAPI was written for C rather then C++, it's pretty easy to write wrappers around those objects so that the de-allocators are called when they leave scope making RAII a valid option for managing those resources.

I'll concede to the point of working in a team though. I haven't had to face that challenge yet and I could see where differing skill levels and design methods could get messy. I also won't claim that I've never forgotten to write a delete when I should have.

I still think too many people transpose the problems with Java to C++. The reason that memory leaks in Java are such an issue is because the interpreter (JVM) runs in the background making those leaks persistent. For C++ the operating systems garbage collector is perfectly able to free up memory resources (not the system resources that Disch mentioned) after the program has ended.

[LB]

Computergeek01 wrote:

How is manually managing memory a problem?

Computergeek01 wrote:

things like HANDLE's and sockets aren't (or at least they shouldn't be) treated\used the same way dynamic memory is. They only exist the way that they do because the WinAPI was written for C rather then C++, it's pretty easy to write wrappers around those objects so that the de-allocators are called when they leave scope making RAII a valid option for managing those resources.

You seem to be contradicting yourself. Keep in mind that memory is a resource just like handles and sockets, this discussion is primarily about resource management and not only memory management.

[Computergeek01]

I don't think that I am, my stance is that managing these resources isn't difficult. I'll admit I'm a bit biased against Java right now, I'm a Sysadmin and about one third of my day is analyzing JVM crash reports due to an uncooperative\incompetent third party support team.

[LB]

You're right, it isn't difficult. It's incredibly tedious and easy to get wrong.

[Disch]

it's pretty easy to write wrappers around those objects so that the de-allocators are called when they leave scope making RAII a valid option for managing those resources.

You're kind of proving my point.

If RAII is a valid option to manage GDI resources, it's an equally valid option to manage memory resources. All the same reasons for using it in one area apply to using it in the other area.

For C++ the operating systems garbage collector is perfectly able to free up memory resources (not the system resources that Disch mentioned) after the program has ended.

I think you have a slight misunderstanding here. I'm pretty sure that OS's don't have a garbage collector. They generally assigns blocks of memory to a particular process, and when that process exits, the memory it allocated to it is automatically released. There's no runtime examination of memory to see if it's still in use (ie: garbage collection).

But regardless, the dangers of memory leaks are not that they suck up memory after the process exits... it's that they suck up more and more memory over the lifetime of the process.

A memory leak in a program means it might run fine for 15 mins, but then might start consuming unreasonable amount of memory resulting in poor overall system performance. Leaks can cause programs to consume several hundred MB... or possibly even several GB of RAM if run long enough.

EDIT: Also, as a side point... GDI resources like those freed with DeleteObject are also automatically released by Windows when the owning process exits. So they're not as different from memory resources as you seem to think.

[LB]

That implies that you actually relinquish the DLL in a proper manner by calling e.g. FreeLibrary as many times as you called LoadLibrary. The counter is internal to Windows, but incrementing it and decrementing it are still your responsibility.

[N36fSL3A]

Usually older programmers handle memory more efficiently than newer ones.

[LB]

That's funny, because most newer programmers are being taught better ways to manage memory that weren't around when older programmers learned to program.

[N36fSL3A]

My statement is invalid.