C++ in Coders at Work

Post by russell » Fri, Oct 16, 2009, 9:43 PM UTC

loup-vaillant wrote: post #25

Oxryly wrote: post #5

Part of how C++ is successful is that it retains C compatibility, and C accurately models how the computer actually works (at least computers of the 70s and 80s, which is all we know how to program well). Lovely languages like lisp, python, haskell may be nicer to work with, but they do not model the underlying machine properly, and for so many problem domains that is just not acceptable. It's not just a performance…

I totally agree. C++ main strength lies in its "portable assembler" nature. However, C++ also is [quite a behemoth][1], while Lisp, Python and Haskell aren't so. [1]: http://yosefk.com/c++fqa/ The answer then is obvious : we should change the hardware, so it is not C/C++ optimized, but Lisp/Python/Haskell optimized. Then, these languages are easier and more practical.

Post by malkia » Fri, Oct 16, 2009, 10:47 PM UTC

jacquesm wrote: post #100

dkarl wrote: post #94

Earlier quoted context omitted.

use of operators should be reserved to those situations where the outcome is predictable, and where operator precedence rules are the same as they would be when adding numbers. So what's stopping you? That's exactly the way I do it. In my C++ career I've only overloaded math operators for math types, * and -> for smart pointers, [] for container-like types, and () for callable objects. At least in production code...…

I see it as a traffic problem. I'm not that scared when driving of what I'll do next. But some of the other drivers on that same road scare the willies out of me. Same with language features. If all you have is bicycles then nobody is going to hurt anybody badly. But if we're all driving rocket cars at 1000 MPh then the resulting pile-ups will be spectacular. You use operator overloading in a disciplined fashion, bec…

Post by aminuit » Fri, Oct 16, 2009, 10:54 PM UTC

jacquesm wrote: post #27

dschobel wrote: post #23

Earlier quoted context omitted.

I think C models how the computer works a lot more closely than C++ (and no one would argue that C isn't carrying water out in the engineering world even today). IMO C++'s issue is precisely that it layers all of these leaky abstractions on top of the strict procedural model of C. For my money, developers are better off knowing two tools (c + some very high level language) rather than the spork which is C++.

I remember 'cfront', when it first came out, and to this day I haven't really changed my mind on how I felt about it, it's a much too bloated language compared to the elegance of C. If 'C' would have had a decent native string type I think C++ might not have happened ;)

    std::basic_string::basic_string(const _CharT*,
    const _Alloc&) [with _CharT = char, _Traits = std::char_traits,
    _Alloc = std::allocator]

Post by allenbrunson » Fri, Oct 16, 2009, 11:20 PM UTC

Confusion wrote: post #110

timr wrote: post #9

This is a disappointingly flamey article: roughly 90% of the comments are from people who got a bad impression of C++ during the pre-standardization days (which were admittedly horrible, but long since past). Most of the rest are from people who just skipped straight to Java, or who are so young that they never had to learn C++ at all. The comments that really drop my jaw are the people who seem to hold up Java as a…

roughly 90% of the comments are from people who got a bad impression of C++ during the pre-standardization days Zawinski and Thompson are good, but they are not 90% of Zawinski, Thompson, Bloch, Eich, Ingalls, Armstrong and Steele. You're completely misrepresenting the gist of the article. The comments that really drop my jaw are the people who seem to hold up Java as a "better" C++. http://www.paulgraham.com/icad.ht…

Post by joe_the_user » Fri, Oct 16, 2009, 11:49 PM UTC

gaius wrote: post #117

joe_the_user wrote: post #90

Earlier quoted context omitted.

Recently, I went from Ruby on Rails web programming to C++ w/Qt GUI programming. Using the C++ features that I choose, C++ is actually pretty fast to develop on... (I did MFC years ago and that was nasty but Rails internal code is also awful, with fifty-million separate classes just for exceptions). Aside from C compatibility, C++ also allows one to create simple structures and procedures when such simple beasts are…

Strong typing plus full OO = Bondage and Discipline language, where the size of the code itself starts to really drag your development and debugging time down You're missing a crucial part of the equation: type inference. OCaml does what you want :-)