Talking to C Programmers about C++ [video] • Hacker News Board

Re: Talking to C Programmers about C++ [video]

#51

Post by MereInterest » Sun, Sep 25, 2016, 1:43 PM UTC

qwertyuiop924 wrote: post #41

MereInterest wrote: post #36

Earlier quoted context omitted.

I would say that the complexity of a language and the complexity of programs within that language are inversely correlated. Java is a very simple language, but as a result, the programs written in it must be more complicated to make up for the shortcomings of the language. As an example, Java's lifetime rules are much simpler than those of C++. At some point after all references are gone, the object will be garbage c…

No, not really. Complexity is not about the language: It's about how you use it. It's not necessarily Java's featureset that makes it so complex, it's its idioms. C++'s lifetime rules, on most variables, are this: It's allocated until you say it isn't. Some of the vars might be refcounted or GCed, but with GC you've still got the same problem on your hands as finalizers, and refcounting can't handle cycles. Manual me…

I'd be interested to hear why you say that RAII cannot be idiomatic. With `std::unique_ptr` and `std::shared_ptr` for handling pointers, `std::vector` for handling data arrays, `std::string` for handling char arrays, I would argue that modern C++ is very heavily RAII. At this point, if I have a class that cannot be declared on the stack, with cleanup handled by RAII, I consider it to be a broken class.

Good point on limitations vs simplicity. I think that there are different forms of complexity. Some complexity is necessary, due to the nature of the underlying problem. Other complexity is incidental, being due to poor implementations. As an example of essential complexity, C++ has different declarations for stack-based variables and heap-based variables, while Java does not. This is because Java does not allow classes to be declared on the heap, and so it does not need an extra form of declaration. On the other hand, C++ definitely has lots of incidental complexity as well, mostly due to its long history. Having four different constructs for loops is incidental complexity.

I agree that the idioms are what make Java programs be complicated, rather than the language itself. What I'm not sure on is how much those idioms are needed to overcome limitations in the language, and how much they are unnecessary parts of the culture.

Oh, absolutely on Lisp. Lisp/Scheme are amazingly simple, and amazingly powerful. The one downside that I've found is that it doesn't correspond to the hardware as much. Much of C++'s complexity stems from trying to provide as many features as possible while still compiling down to reasonably fast code.

Re: Talking to C Programmers about C++ [video]

#52

Post by aksx » Sun, Sep 25, 2016, 1:46 PM UTC

faragon wrote: post #44

sseagull wrote: post #40

Earlier quoted context omitted.

A vector/map of what? How do I have a map of some key to a custom structure? How do you do this simply without templates? Separate libraries? Macro hell? How do you handle types which need to free memory without destructors? Manually loop over the vector and free stuff every time one goes out of scope? That doesn't seem safer to me.

>>A vector/map of what? How do I have a map of some key to a custom structure? How do you do this simply without templates? Separate libraries? Macro hell? Separate libraries, without "macro hell". >>How do you handle types which need to free memory without destructors? Manually loop over the vector and free stuff every time one goes out of scope? That doesn't seem safer to me. Providing both heap and stack based all…

>For heap allocation, you would need to call some sometype_free(&a) function

i find '__attribute__((cleanup (fn)))' fascinating in C, need to try it in some production code though.

Re: Talking to C Programmers about C++ [video]

#53

Post by wott » Sun, Sep 25, 2016, 1:56 PM UTC

After 20 minutes spent complaining that nobody listens to him, several minutes of diversion to come to the point that people are not rational because they favour world view and moral sense (characteristics that he calls 'emotional') compared to self-interest, and that he finds that dismaying.

Well, I am dismayed that one may consider prioritising selfishness and immediate interest as rational and prioritising global thinking as emotional, and not the opposite. And that is supposed to serve as an anchor to the following points. Well...

Now at 30 minutes and the subject of the talk was barely tackled. I am not sure I have the strength to inflict myself the remaining hour.

Re: Talking to C Programmers about C++ [video]

#54

Post by qwertyuiop924 » Sun, Sep 25, 2016, 1:57 PM UTC

MereInterest wrote: post #51

qwertyuiop924 wrote: post #41

Earlier quoted context omitted.

No, not really. Complexity is not about the language: It's about how you use it. It's not necessarily Java's featureset that makes it so complex, it's its idioms. C++'s lifetime rules, on most variables, are this: It's allocated until you say it isn't. Some of the vars might be refcounted or GCed, but with GC you've still got the same problem on your hands as finalizers, and refcounting can't handle cycles. Manual me…

I'd be interested to hear why you say that RAII cannot be idiomatic. With `std::unique_ptr` and `std::shared_ptr` for handling pointers, `std::vector` for handling data arrays, `std::string` for handling char arrays, I would argue that modern C++ is very heavily RAII. At this point, if I have a class that cannot be declared on the stack, with cleanup handled by RAII, I consider it to be a broken class. Good point on…

Well then, that's your problem: C++ is trying to be both low-level and high level at the same time. This isn't a good idea, IMHO.

What I mean is that while some amount of RAII is a common idiom in C++, It's rare for a program to use RAII fully, as many C++ idioms conflict with it. Mind, I'm not an expert, so I might be wrong, but that was my understanding. AFAICT, if RAII was used all the time, idomatic C++ would look a lot more like Rust.

Re: Talking to C Programmers about C++ [video]

#55

Post by MereInterest » Sun, Sep 25, 2016, 1:58 PM UTC

metaobject wrote: post #50

jonstewart wrote: post #38

Earlier quoted context omitted.

The problem with posts about C++ on Hacker News is that people who aren't experienced C++ programmers (you've been using C++ for a semester? do tell) feel compelled to write posts explaining the problems with C++.

This problem is not limited to HN, I see it everywhere. And wrt to the notion that every feature of C++ (from simple, to complex, to highly complex) will be used, I've been using C++ professionally for ~13 years and there are certain features I've chosen to stay away from since they don't add any benefit to the problems that I solve (or to the way I solve them). And I feel fine about that bc I'm very pleased with the…

As somebody who is relatively experienced with C++, but primarily on small projects with few developers, which features do you tend to stay away from?

Re: Talking to C Programmers about C++ [video]

#56

Post by KayEss » Sun, Sep 25, 2016, 1:59 PM UTC

FrozenVoid wrote: post #28

KayEss wrote: post #18

Earlier quoted context omitted.

Can you give some concrete examples?

http://pastebin.com/fgPhGaxz

Personally I think that looks pretty good. There's no templates, no inheritance. Not sure what would make bloat there nor latency. Whatever the faults of the syntax for folding, it's got to be better than VA_ARGS hasn't it?

Re: Talking to C Programmers about C++ [video]

#57

Post by FrozenVoid » Sun, Sep 25, 2016, 2:03 PM UTC

KayEss wrote: post #56

FrozenVoid wrote: post #28

Earlier quoted context omitted.

http://pastebin.com/fgPhGaxz

Personally I think that looks pretty good. There's no templates, no inheritance. Not sure what would make bloat there nor latency. Whatever the faults of the syntax for folding, it's got to be better than VA_ARGS hasn't it?

Have you tried to compile and run it?

Re: Talking to C Programmers about C++ [video]

#58

Post by AlexandrB » Sun, Sep 25, 2016, 2:04 PM UTC

blub wrote: post #39

satysin wrote: post #22

Earlier quoted context omitted.

You just proved my point ;)

Doubtful. What would 25% of the above list be, basics + OOP? No standard library at all? No templated code? I am saying one can barely write programs by knowing just 25% of C++, let alone for almost two decades. On the contrary, I think 80%+ of the language is accessible to every programmer.

> On the contrary, I think 80%+ of the language is accessible to every programmer.

80% of the language looks accessible to every programmer. Until you hit some corner of C++ behaviour and you realize your mental model of what C++ is doing is woefully incomplete. C++ is stuffed full of syntax, and obscure interactions between that syntax will continually trip you up. Each of the things in your list is somewhat contained on its own but interacts in surprising ways with every other thing on that list.

For example[1], want to create a template friend function for a template class? Prepare for function definitions like:

    Foo f();

Edit: that's not to mention various C++ idioms like CRTP [2] which don't fit neatly with the stuff you listed but are non-obvious and occur in a lot of complex C++ code.

[1] http://yosefk.com/c++fqa/templates.html#fqa-35.16

[2] https://en.wikipedia.org/wiki/Curiously_recurring_template_p...

Re: Talking to C Programmers about C++ [video]

#59

Post by blub » Sun, Sep 25, 2016, 2:07 PM UTC

hellofunk wrote: post #42

blub wrote: post #19

Earlier quoted context omitted.

What are the components of C++ that add up to 100%? I can count: * language basics (variables, structural statements, functions, error handling, preprocessor, how compilation works) * OOP * functional programming (which is not that complicated at all in C++) * generic programming * advanced generic programming and metaprogramming * the C standard library * the C++ standard library basics (containers, algorithms, smar…

> functional programming (which is not that complicated at all in C++) > I think most C++ programmers have a reasonable command of all of these These gave me a bit of a chuckle. It's true only if you've never done proper functional programming using a genuinely functional language. It's true that you can now pass lambdas around as first-class values easily, store and manipulate them as you might in a functional langu…

A discussion about "proper functional programming" is not particularly relevant, because the topic is functional programming in the context of C++.

The constructs that C++ offers for FP are not complicated.

Re: Talking to C Programmers about C++ [video]

#60

Post by sseagull » Sun, Sep 25, 2016, 2:09 PM UTC

faragon wrote: post #44

sseagull wrote: post #40

Earlier quoted context omitted.

A vector/map of what? How do I have a map of some key to a custom structure? How do you do this simply without templates? Separate libraries? Macro hell? How do you handle types which need to free memory without destructors? Manually loop over the vector and free stuff every time one goes out of scope? That doesn't seem safer to me.

>>A vector/map of what? How do I have a map of some key to a custom structure? How do you do this simply without templates? Separate libraries? Macro hell? Separate libraries, without "macro hell". >>How do you handle types which need to free memory without destructors? Manually loop over the vector and free stuff every time one goes out of scope? That doesn't seem safer to me. Providing both heap and stack based all…

Yes, but it would still be hard to support custom types, wouldn't it? Ie in your library, I would have to use pointers, which might be unsafe? Adding types to a library like that (like double) causes the amount of code to grow dramatically (maybe even n^2 for maps).

You're library does look nice for what it does, and may have to look into it for some projects (I do have some C projects). Thanks!