[pmelendez]

I would recommend you to first read "Tour of C++" or another book that explains better the new features on C++11. Meyers explain very well some of edge cases of move semantics but if you don't understand the concept first then you might not have a good experience reading the book.

>"says that 'don't use malloc and free, unless you want to debug 1980s' problems."

The problem with malloc and free is that they left to the developer to keep track of the references and memory corruptions bug are not pleasant to debug. RAII idiom actually helps a lot in that context, and that is what Strouptrup was referring to.

[throwawayaway]

thanks for the recommendation.

i think malloc and free are a lesser evil than this stuff:

http://thbecker.net/articles/rvalue_references/section_08.ht...

feel free to disagree!

[pmelendez]

The link that you provided does not have to do with malloc and/or free but with perfect forwarding:

http://thbecker.net/articles/rvalue_references/section_07.ht...

Also that example uses a Factory pattern which is actually verbosing the example, but it's like comparing apple and oranges since that's OOP which you actually wouldn't be doing in C.

What you would be comparing is something like:

mystruct * stcVar = malloc(sizeof(mystruct)); free (stcVar);

Vs.

std:shared_ptr<mystruct> stcVar;

Of course that is a stupid example; However things gets more interesting when you have pieces of code sharing the same structure (threads maybe?) and you don't know exactly which code should be the one in charge of releasing the pointer.

[throwawayaway]

i think you misunderstand.

clearly, it is C++, not C.

instead of a simple malloc and free, you will invariably end down the rabbit hole learning about rvalues. perfect forwarding, move semantics, lvalues - the list goes on - these topics arise from the simple concept of RAII.

which i find worse than malloc and free.

[pmelendez]

>i think you misunderstand. >clearly, it is C++, not C.

I got that, what I said is that you wouldn't have that problem in C because it arises when you are doing OOP, and most C devs would not use OOP. Also, keep in mind that it is perfectly fine not using OOP in C++.

> instead of a simple malloc and free, you will invariably end down the rabbit hole learning about rvalues

That's not true. Actually you can be a very decent C++ developer without knowing the notion of what an rvalue is. Move semantics is just an optimization to avoid extra copy of objects, so it is completely optional.

At the moment of writting this, there is an entry on the front page with an example of a modern C++ piece of code. You would notice that there is not a single explicit heap allocation nor any other crazy stuff.

https://news.ycombinator.com/item?id=9560667

[throwawayaway]

i think moving data around in memory is not an exclusive feature of OOP and i hesitate to guess why you think that operations similar to those exposed by the 'move semantics' are not something undertaken (regularly!) by c developers using malloc and free.

> instead of a simple malloc and free, you will invariably end down the rabbit hole learning about rvalues

truth is subjective to me, in my experience, when you program C++ you will end up exploring a myriad of vast expanses of language features. you may feel that someone can be a very decent C++ developer without knowing that, plenty others would be aghast that someone ignorant of rvalues would describe themselves as 'very decent'.

remember the ostensible creator of the language rates himself at 8/10.

i think that front page example is rather interesting, given the number of #using directives - it gives an indication of the time that developer has spent learning the language. most of them are not trivial to understand to the degree that this guy has. also reading his background, i'm quite sure he knows what an rvalue is.

as you can imagine, i don't really mind explicit allocations - as an awful lot of knowledge is required in C++ to deal with implicit allocations.

in my opinion, there's a lot of 'crazy' stuff there, the short linecount is a product of the author having done his homework.

i get the impression that you and i would use very different subsets of C++. mine would be far smaller! i usually confine myself to whatever idoms the libraries i pull in use and go no futher.