Five Popular Myths about C++: Postscript • Hacker News Board

Re: Five Popular Myths about C++: Postscript

#31

Post by dragontamer » Tue, Dec 30, 2014, 11:21 PM UTC

StephanTLavavej wrote: post #26

dragontamer wrote: post #20

Earlier quoted context omitted.

shared_ptr a = make_shared (10); What's so hard about managing that? shared_ptr is basically equivalent to Python garbage collection. Shared_ptr were standardized in 2003, and Microsoft implemented CComPtr way back in the 90s for this easy to use reference-counted smart-pointer concept. http://msdn.microsoft.com/en-us/library/aa266806%28v=vs.60%2... So... yeah. Stop doing manual memory management in C++. Something be…

Correction: shared_ptr wasn't in C++98/03. It was originally developed in Boost, then added to TR1 (in 2005), and finally incorporated into C++11. One of the major differences between shared_ptr and CComPtr is that shared_ptr is non-intrusive - it can manage anything, even things like ints that don't know anything about strong/weak refcounts.

My history was off, thanks for the clarification.

Nonetheless, the concepts revolving around CComPtr and all that good stuff can be easily seen in C++98 / STL. STL Strings for instance automatically clean themselves up under the principles of RAII.

Auto_ptr, the first smart pointer, also was standardized in C++98. While crude and primitive by today's standards (especially compared to unique_ptr's explicit RValue semantics), auto_ptr shows me that even in the mid 90s, people understood the principles of RAII.

At least, if you were a learned C++ programmer.

Re: Five Popular Myths about C++: Postscript

#32

Post by sjolsen » Wed, Dec 31, 2014, 1:28 AM UTC

vardump wrote: post #30

sjolsen wrote: post #29

Earlier quoted context omitted.

> the language tries very hard to make sure you can't understand a piece of code out of context The language goes out of its way to make it possible to write code that is understandable with as little context as possible; type deduction, lambdas, range-based for loops— all of these are tools for reducing the amount of context or number of contexts necessary to understand a portion of code. The language also allows yo…

I guess you don't maintain [legacy] C++ code. Occasionally I have to.

I have maintained C++ code that was poorly written, if that's what you're getting at, but I have yet to find myself maintaining C++ code that has been poorly written as a result of the design of the language.

Re: Five Popular Myths about C++: Postscript

#33

Post by vardump » Wed, Dec 31, 2014, 5:27 AM UTC

sjolsen wrote: post #32

vardump wrote: post #30

Earlier quoted context omitted.

I guess you don't maintain [legacy] C++ code. Occasionally I have to.

I have maintained C++ code that was poorly written, if that's what you're getting at, but I have yet to find myself maintaining C++ code that has been poorly written as a result of the design of the language.

That's unfortunately something you can say about any language.

Re: Five Popular Myths about C++: Postscript

#34

Post by frankzinger » Wed, Dec 31, 2014, 6:56 AM UTC

vinkelhake wrote: post #28

frankzinger wrote: post #25

Earlier quoted context omitted.

This is exactly why 'stable' or 'long-term-support' versions of OSes exist. They go out of their way not to break binary compatibility (by not upgrading libraries all the time) so that user code need not be recompiled.

That just means that forced updates are less frequent. The flipside of it is that you are now stuck with, potentially, ancient packages. No matter how you slice it, being tied to the release cycle of the OS has problems. Don't get me wrong, there are definite advantages to sticking with OS-provided packages. I do it for all my personal projects, but it's not a panacea.

That is a tradeoff every software repo is faced with (stability vs. new features). Why would a C++-specific PM be able to do it better? Especially considering that it would have to provide compiled binaries for N versions of M OSes/distros (not to mention multiple CPU architectures).

Re: Five Popular Myths about C++: Postscript

#35

Post by sacado2 » Wed, Dec 31, 2014, 12:09 PM UTC

nawitus wrote: post #19

Iftheshoefits wrote: post #16

Earlier quoted context omitted.

I've encountered each of these myths "in the wild," and I dare say you'll see them thrown up repeatedly here on HN in various contexts. The third item on that list especially is something you can almost certainly see every day in a random HN thread about programming languages (along with counterpoints). In fact, 'safety', of which GC is a subset, is a huge objection, and one of the first, most frequently raised in my…

Note that one can be against a programming language feature without being afraid of them. I think pointers are a bad feature in a programming language because they're not necessary. It's rather unfortunate that Go, for example, supports pointers (which is of course not surprising when you consider who designed it).

It's hard to deal with low-level code without resorting to pointers in some ways, though. I can't think of a low-level language that doens't use them, actually.

Re: Five Popular Myths about C++: Postscript

#36

Post by nawitus » Wed, Dec 31, 2014, 3:06 PM UTC

sacado2 wrote: post #35

nawitus wrote: post #19

Earlier quoted context omitted.

Note that one can be against a programming language feature without being afraid of them. I think pointers are a bad feature in a programming language because they're not necessary. It's rather unfortunate that Go, for example, supports pointers (which is of course not surprising when you consider who designed it).

It's hard to deal with low-level code without resorting to pointers in some ways, though. I can't think of a low-level language that doens't use them, actually.

That's true, although you can always use pointers without pointers being a language-level feature. That said, if the programming language is designed for low-level code then pointers are beneifical in my opinion. But is Go really designed to be a low-level language? I don't think so, and if it is, I will stay away from it if I can..

Re: Five Popular Myths about C++: Postscript

#37

Post by sacado2 » Wed, Dec 31, 2014, 6:50 PM UTC

nawitus wrote: post #36

sacado2 wrote: post #35

Earlier quoted context omitted.

It's hard to deal with low-level code without resorting to pointers in some ways, though. I can't think of a low-level language that doens't use them, actually.

That's true, although you can always use pointers without pointers being a language-level feature. That said, if the programming language is designed for low-level code then pointers are beneifical in my opinion. But is Go really designed to be a low-level language? I don't think so, and if it is, I will stay away from it if I can..

Go is middle-level, lower than scripting languages, higher than C++. You have control over memory layout, which lets you use less memory than a language that boxes everything (like Java or Python). You can use linear structs, or references to data, whatever fits your problem best. But, to do that, you need pointers.

However, Go pointers can't be casted to another type and you can't do pointer arithmetic. In this way, they are very close to Java or Python references, except they're made explicit. How can these kinds of pointers be any worse than references ?

Re: Five Popular Myths about C++: Postscript

#38

Post by nawitus » Wed, Dec 31, 2014, 7:26 PM UTC

sacado2 wrote: post #37

nawitus wrote: post #36

Earlier quoted context omitted.

That's true, although you can always use pointers without pointers being a language-level feature. That said, if the programming language is designed for low-level code then pointers are beneifical in my opinion. But is Go really designed to be a low-level language? I don't think so, and if it is, I will stay away from it if I can..

Go is middle-level, lower than scripting languages, higher than C++. You have control over memory layout, which lets you use less memory than a language that boxes everything (like Java or Python). You can use linear structs, or references to data, whatever fits your problem best. But, to do that, you need pointers. However, Go pointers can't be casted to another type and you can't do pointer arithmetic. In this way,…

>How can these kinds of pointers be any worse than references ?

Because references are easier to use.

Re: Five Popular Myths about C++: Postscript

#39

Post by sacado2 » Thu, Jan 01, 2015, 9:10 PM UTC

nawitus wrote: post #38

sacado2 wrote: post #37

Earlier quoted context omitted.

Go is middle-level, lower than scripting languages, higher than C++. You have control over memory layout, which lets you use less memory than a language that boxes everything (like Java or Python). You can use linear structs, or references to data, whatever fits your problem best. But, to do that, you need pointers. However, Go pointers can't be casted to another type and you can't do pointer arithmetic. In this way,…

>How can these kinds of pointers be any worse than references ? Because references are easier to use.

I get your point, although I think references are not that easier ; if one doesn't think what's happening underneath when using refernces, nasty bugs can occur.