Jump to content


Member Since 21 Sep 2013
Offline Last Active Oct 22 2016 11:15 AM

Posts I've Made

In Topic: Criticism of C++

05 January 2016 - 06:20 AM

Yes, because the deprecation of some library features is the same as a 'rethink of the language'...

Who said it is the same? smile.png

As i said, Meyers and alot of great C++ programmer want to break backward compatibility in the language itself, not just in STL. (btw, STL is not just a random library) It would be still C++.

Most of the things which is allowed now (like: uninitialized variables without signing that "Yes, i know what i am doing"), but every static analyzer sign a warning aboit it should be cleaned up. Most problem in C++ is deriving from C, but C compatibility is not that important right now, and anyway we have great refactoring tools (thank you clang), so it's not too hard to change the language. If C++ will be cleaned, everybody will call it C++... just because something is changing it doesn't magically become a whole different language...

In Topic: Criticism of C++

05 January 2016 - 05:54 AM


C++11 broke backward compatibility, C++17 will also do this.

Can you point to any breaks?


There is a bunch of minor things in the stl (and i think there is some in the language itself), i won't search for it, but hanging around cppreference you can find alot of stuff which will be removed in C++17, in C++11 alot of contructor and stuff also changed and i am pretty sure not all in a backward compatible way.


These are for example will be completely removed: http://en.cppreference.com/w/cpp/utility/functional/bind12

Just like auto_ptr and alot of other useless class.


These were mostly unused, so it's not painful to the community, but it still breaks backward compatibility.

As far as i know, the name of this language is still C++.

In Topic: Criticism of C++

05 January 2016 - 05:13 AM


I seriously think someone should re-think C++ from scratch instead of driving away into another language.

A 'rethink from scratch' would just give you another language.

Anything which breaks backwards compatibility is a new language.

End of story.

And people have tried, D which was brought up earlier is this indeed incarnate, yet it has failed to catch on.

A 'rethink of C++' is no longer C++.


C++11 broke backward compatibility, C++17 will also do this.

Just in minor things, but still... this assumption is a fail. smile.png


Anyways Scott Meyers made a blogpost when he encouraged breaking backward compatibility in major things. This is something alot of great C++ programmer waiting for... and no, it wouldn't be a different language, it would be a better version of C++.

In Topic: Practicality of a C++ Garbage collector

05 January 2016 - 02:12 AM

As Stroustrup said, C++ doesn't have Garbage collector, because C++ doesn't generate garbage. smile.png

GC is problematic:

- It gives you the illusion that you shouldn't care about resource management. In real world you still have to (it's more of a beginner trap)

- There are alot of resource type (eg.: memory, files, locks, threads etc), but GC only care about memory.

- It's memory management is also poor, as long as you care about performance it's never acceptable.

- If you doesn't develop performance critical applications GC can be viable, but when you touch C++ you mostly really care about performance.


As long as you write idiomatic C++ code it's impossible to leak anything. What you don't use is released instantly.

The solution is simple:

- Never allocate directly any (non-thread) resource. So never write: new, delete, lock, unlock, open, close etc.

- Use resource handlers -> you will end up with an exception safe code without writing try-catch blocks everywhere.

- The best is if your static analyzer drop you warnings about resource allocation or release.

In Topic: Unsure between 2 books

27 August 2015 - 06:55 AM

For best practices i think Effective C++ is superior.