The Time Needed to Write “Effective Modern C++” • Hacker News Board

Re: The Time Needed to Write “Effective Modern C++”

#141

Post by solipsism » Thu, Apr 23, 2015, 7:13 PM UTC

innguest wrote: post #129

solipsism wrote: post #14

Earlier quoted context omitted.

Creating C++ means you're likely to know the ins and outs of the language. That's a necessary condition to being a good C++ programmer, but it's not sufficient. It's not at all obvious to me that Stroustrup would be a good C++ programmer or even a good C programmer.

Macho man! If you need to know the intricacies of an abstraction in order to use an abstraction, then it's not a very good abstraction. Do engineers know the ins and outs of concrete and rebar? Or do they offload that knowledge onto manufacturers? But programmers can't offload anything onto the language creator or they aren't real programmers. I'm glad for all the work the SBCL and GHC teams put onto their languages…

What? You're reading way too much into my use of the term ins and outs. I didn't say good C++ programmers must know how to implement a C++ compiler. By ins and outs I meant: the syntax, the evaluation strategy, the features and facilities provided by the language and toolsets, etc. You need to know those kinds of things to be a good programmer, and every language creator is likely to know those things about the language she created. My point was that knowing those things is necessary but not sufficient to be a good programmer.

Macho man! ... Maybe one day you'll find a language ...

Your tone is really shitty, and it's made worse by the fact that you're being shitty toward some imaginary strawman you've put in my place. For what it's worth: I greatly value good abstractions, I think appropriate high-level languages should be used whenever there's not a good reason to use low-level languages, I think leakier abstractions are shittier abstractions, I think C++ is full of the leakiest of abstractions, and I think Haskell and lisps are great. I know you're really eager to shit on others because you think you've achieved some kind of higher level consciousness, but you should probably work on your knee-jerk reactions.

Re: The Time Needed to Write “Effective Modern C++”

#142

Post by nostrademons » Thu, Apr 23, 2015, 7:44 PM UTC

coliveira wrote: post #115

nostrademons wrote: post #72

Earlier quoted context omitted.

I think the objection is that b may get passed throughout the program such that it's no longer local to a. Then you have 'const Foo& a' that you expect will never change, but your function reading from that calls something that mutates a 'Foo* b' that aliases the object (probably through a member variable), and suddenly you have some very hard to track down bugs. If you're multi-threaded, you have a data race. You ei…

> you have 'const Foo& a' that you expect will never change, but your function reading from that calls something that mutates a 'Foo* b' that aliases the object And this is exactly why const means pretty close to nothing. Compilers can't enforce it in so many situations that it is almost like the "auto" keyword in pre-C++11 times.

It still documents intended behavior, though. C++ is basically a giant clusterfuck if you want the compiler to actually enforce anything - because of pointer arithmetic, there's no guarantee not only that const Foo& a is immutable, but even that it points to a valid Foo or that accessing it won't crash your computer. It's trivially easy to trigger undefined behavior that may do anything up to pwning your computer, whether you make your classes immutable or not. The point of const, access control modifiers, references, static typing, RAII, and all of the other restrictions on C++ programming is to put up giant signposts that say "Don't do that! Here be dragons!" rather than actually prevent you from doing it.

If you want the compiler to actually enforce safety properties of the language, use a language like Haskell or Rust.

Re: The Time Needed to Write “Effective Modern C++”

#143

Post by MrScruff » Thu, Apr 23, 2015, 7:59 PM UTC

angersock wrote: post #138

MrScruff wrote: post #85

Earlier quoted context omitted.

There are many applications that either aren't typically IO bound, or where the IO (eg. gpu memory) is fast enough that you'll likely need C++ to maximise performance. Writing software that pushes bleeding edge hardware is fun, which is why many people still want to learn C++.

Oh, sure, but the vast vast vast majority of applications--especially that people are hiring for--aren't what you're referring to.

Statistically I've no doubt you're right. However there are still a bunch of jobs where performance matters. If I left my job and industry, I'm fairly certain I could find another employer that found value in having a specific piece of code run as fast as possible.

Re: The Time Needed to Write “Effective Modern C++”

#144

Post by Shorel » Thu, Apr 23, 2015, 9:13 PM UTC

istvan__ wrote: post #21

Could somebody redpill me on why something like D ( http://dlang.org/ ) is not a better alternative to C++. Is that the library support or what exactly makes C++ still a better option in 2015? I am not sure what is the best alternative to C++.

The language itself is amazing. I'm a fan.

But try to find a MySQL library with support for DECIMAL. Something I think should be in the standard library nowadays.

No workable solution found.

Things like that are the things that kill the language.

Re: The Time Needed to Write “Effective Modern C++”

#145

Post by detrino » Thu, Apr 23, 2015, 10:15 PM UTC

coliveira wrote: post #114

lultimouomo wrote: post #78

Earlier quoted context omitted.

This does not seem like a strong argument. Yes, table salt is useful, but if you don't know what it actually does and you put it in your eyes, it will burn them, just like most, well, everything... A const reference guarantees to the caller that the callee won't modify the object, not to the callee that the object won't be modified.

Except that it doesn't. Thanks to const_cast, you can take away constness from pointers, so where does your "guarantee" comes from?

A function may not reliably cast a pointer-to-const-T to a pointer-to-T because T may actually be immutable, in which case modifying it would be UB. Like all casts, const_cast exists as an escape hatch in the type system for when you know that what you are doing is safe, even if the compiler can't prove it.

Re: The Time Needed to Write “Effective Modern C++”

#146

Post by coliveira » Thu, Apr 23, 2015, 10:34 PM UTC

nostrademons wrote: post #142

coliveira wrote: post #115

Earlier quoted context omitted.

> you have 'const Foo& a' that you expect will never change, but your function reading from that calls something that mutates a 'Foo* b' that aliases the object And this is exactly why const means pretty close to nothing. Compilers can't enforce it in so many situations that it is almost like the "auto" keyword in pre-C++11 times.

It still documents intended behavior, though. C++ is basically a giant clusterfuck if you want the compiler to actually enforce anything - because of pointer arithmetic, there's no guarantee not only that const Foo& a is immutable, but even that it points to a valid Foo or that accessing it won't crash your computer. It's trivially easy to trigger undefined behavior that may do anything up to pwning your computer, wh…

This seems to me a lot of trouble for "documented" behavior. It is much better to design your classes in a reasonable way and stop worrying about const issues. If you rely on const to write good code, I guarantee you that sooner or later you will be in a lot of trouble.

Re: The Time Needed to Write “Effective Modern C++”

#147

Post by coliveira » Thu, Apr 23, 2015, 10:58 PM UTC

netheril96 wrote: post #128

coliveira wrote: post #118

Earlier quoted context omitted.

> `const` is only needed for the caller to ensure that the object won't get changed when passed to another function. But const cannot guarantee this, because it can be cast away so easily. This could be true just for your own code, but then it is you who is responsible for maintaining the immutability, not the compiler.

> because it can be cast away so easily By this logic, none of the static type checks in C++ is of any use, since they can be cast away easily as well.

Types exist to help you organize your code. Const (for classes) just promotes the misguided idea that you should design objects with mutable and immutable parts at the same time. The main objection to this is that your objects should be either value objects (therefore immutable) or reference objects. There is no need for const if you design your classes in this way. On the other hand, the const idea requires you to spread "const" everywhere you might want immutability, otherwise the compiler will fight you at each line of your code. Either way, it is a loss-loss proposition.

Re: The Time Needed to Write “Effective Modern C++”

#148

Post by restalis » Fri, Apr 24, 2015, 9:03 AM UTC

innguest wrote: post #126

restalis wrote: post #84

Earlier quoted context omitted.

"the complexity of C++ is troubling" This comes out of the fact that C++ is being developed more as an engineering tool than as a programming toy. When you're into real engineering, you don't have free lunch.

This is the attitude that keeps us mired in subpar ideas like C, C++, Java, HTML, CSS, JS. "I'm a tough guy and tough guys use tools that make our lives hell! We're serious ! We're engineers ! Your language is just a toy because our managers want to keep us fungible!" What does an average "real engineer" C++ programmer have at their disposal? C++ has an ersatz type system (not algebraic and not connected to type theo…

"What does an average «real engineer» C++ programmer have at their disposal?"

Ways to do the job. C++ is not perfect, I contest some of its design decisions (like having private class members by default, and having to explicitly (i.e. verbose) declare "public" at least some of them to make that given class usable), but I don't have to fight the language so much to get things done. For me the best job C++ does so far is by staying a tool. I don't want _BY_DEFAULT_ "something more", "something clever", or "something whatever" that adds more accidental complexity [1] which comes around when least expected and gets in my way! This being said, I admit that C++ suffers from feature creep like many other things do, but (as a consolation) it got here like this only after serious critique for each of the added feature and each feature had to pass serious filtering in order to "creep in".

"managers keep choosing C++"

Actually, I am the one choosing C++ for what I do, be it corporate related (and managed by managers) work or personal projects. I choose it for both low level and almost scripting-like tasks, although I used (and consider myself proficient in) other toy programming languages too.

[1] http://shaffner.us/cs/papers/tarpit.pdf

Re: The Time Needed to Write “Effective Modern C++”

#149

Post by jokoon » Fri, Apr 24, 2015, 11:51 AM UTC

pmelendez wrote: post #119

AlexandrB wrote: post #110

Earlier quoted context omitted.

While that's true, a lot of the complexity is self-inflicted. C++ tries to define syntaxes for its features in a C style which cripples a lot of features in unnecessary ways. For example, classes being kinda like a C struct instead of a separate syntax altogether. Honestly, even Objective-C is better in this regard because the Objective-C parts are well separated from the C parts instead of feeling wedged-in.

>Objective-C is better in this regard I would argue that's "better". As a result, Objective-C feels like an alien language for a C programmer. Although to be fair I don't think a core C programmer would move to either C++ or Objective-C unless (s)he has to (iOS support or legacy code). I think it is the same reason why C++ developers are not moving to Go anytime soon.

I'd gladly move to a language that has the syntactic sugar of C++ (STL, lambdas, modules, and many other things) without the complexity (templates, inheritance, polymorphism).

Go and Rust seems to have weird syntax differences with C and I don't understand the utility of those. The go function syntax looks a little bit hairy.

Re: The Time Needed to Write “Effective Modern C++”

#150

Post by mikekchar » Fri, Apr 24, 2015, 3:17 PM UTC

blt wrote: post #41

mikekchar wrote: post #8

Very interesting to reflect on the amount of time needed to write a technical book on a programming language. If I compare that to amount of time taken to write code (and forgive me for the horrible KLOC metric), I think one could easily average about 300 lines of good C++ code (including tests) per day on a new project -- probably more if you are working alone, but let's keep it conservative. So about 37.5 lines per…

300 lines per day sustained? that seems really high to me. what were you working on? didn't you ever spend days optimizing or refactoring with <= 0 net lines added?

300 lines is about what I averaged (I can't remember the exact number, but I remember it was about 50:50 split between test code and production code with 150 lines of production code a day). As another commenter mentioned, it was new code and it was C++ (old style). It's easy to crank out header files (as long as they don't contain templates...) Definitely spent time both optimizing and refactoring large portions. It's the average over time. So some days I might write 1000 lines and others, net negative code.

As another person mentioned it really depends on the project. If you are using big frameworks then you can't write code nearly as quickly because you are constrained by the design of the framework. Also if you are green fielding everything, then you get to write a lot of infrastructure code. I get paid to write Ruby on Rails code these days (among other things) and there is no way that I would average 300 lines of code a day even with tests. A huge part of my day is wrestling with Rails and trying to understand what the heck it is doing.

Lots of other things can slow you down. Your coworkers for instance -- constant squabbling over one issue or another can easily eat up half the day (or more). Having a constant stream of requirements is really important too. It's easy to get stalled trying to figure out what you should be doing. It's also easy to get paralysed by indecision and be afraid to write code because you don't want to fix it later. Many, many things can slow you down. If you have a situation where these things aren't getting in the way, you can write quite a lot of code.

At the time I was measuring my output, I was on a phenomenal team. We were writing Windows applications (notably without MFC ;-) ). Working with them pretty much approximated what I think I could do if working alone (i.e., the communication overhead was pretty much 0), so I thought it was a reasonable comparison.