Live data from Hacker News

C++ in Coders at Work

gigamonkeys.com

51–60 of 174 posts

Re: C++ in Coders at Work

#51

Its really fascinating to me. We had Lisp and then the road for many lead to C/C++, Java, and related and then we needed a way to express data in more human-readable form so some genius came up with XML. XML was to cumbersome (close tags, how attributes are expressed, etc.) and then JSON came into the picture. So all that to just come back to where we were in the first place. Now I clearly understand what some of the…

JSON is not a programming language.

Which just goes to show we still have not made all the way back to where Lisp was a few decades ago.

Re: C++ in Coders at Work

#52
post #10

Earlier quoted context omitted.

I see this claim made frequently, but Stroustrup talks about several features in Design & Evolution that were rejected. The committee requires implementations before accepting new features; they don't say "We like that idea" and include it without evidence that it's both possible and useful.

I think the main thrust of that argument has to do with trying to please too many people that were willing to put their support behind C++ if the language would support their pet construct.

It was more the other way around, I think. Implementers had a lot of power to say, "No, this can't be done efficiently," and as a result, the burden was passed to programmers instead.

Can you give an example of a "pet construct" (aside from major features like multiple inheritance and exception handling) that could have been left out?

Re: C++ in Coders at Work

#53
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…

"If Python or Java were implemented by Microsoft and GNU and four other smaller companies, you'd see the same horrible compatibility problems with those languages, too."

There are a lot of Java implementations, and I am not aware of serious compatibility problems between them.

Re: C++ in Coders at Work

#54
post #33

Earlier quoted context omitted.

I completely agree. While C++ certainly isn't perfect, those of us that write real code that is used and maintained day to day can be very productive. While I know who most of the people in the article are and respect their contributions to the world of software engineering, day to day real world pressures of delivery aren't the same as an example in a book. A hammer isn't an elegant tool, but it gets the nail into t…

If you code in a 'safe' way and you stay away from nifty tricks then you are in good shape. I'm sure you have a little list of stuff that you should stay away from or that you would at least discourage. The problems usually come when people start to use all those nifty features in combinations, especially 'newbie' programmers going wild on all that high level sugar. C/C++ is performance wise also as good as unbeatabl…

But think about open source code. Anyone can contribute code, so if you're using C++ you will get code from people from all levels of understanding of C++. This is a reason why some open source people prefer to use C, because they won't spend time saying what can or cannot be used in the project.

An example is Google. They had to create a huge document to describe what part of the language their developers can use: http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...

Re: C++ in Coders at Work

#55
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…

The one point that I see throughout the article is that every programming shop uses it's own subset of C++. Based on coding conventions, library usage, and business domain I have seen how the C++ code used in different companies can look like a different programming language altogether.

My professional experience outside C++ is limited, but I had always assumed this was the same for other languages as well. Is C++ really that much of a different animal from other languages?

Re: C++ in Coders at Work

#56
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 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++.

The sad part is that there are a few good ideas in C++, so it is hard to throw out the baby with the bathwater. I use C++ like C with destructors, operator overloading, typed constants, and not much else.

Re: C++ in Coders at Work

#57

Earlier quoted context omitted.

PHP, Python and perl are rarely seen at corporations that existed before the web came around. Their whole IT department is set up around a different kind of environment. Not sure if this is true in general. I work at a bank. We use a lot of Perl. Banks existed long before "the web", and our Perl stuff is not a web application either. All the internal web apps are Java. It is kind of weird, actually -- Java for stuff…

> We use a lot of Perl. That's interesting! That's the last thing I would expect from a bank actually, wonder how common that is. But then again, is there even an 'enterprise scripting language' ? > All the internal web apps are Java. That's what I would expect. Sun really did some good marketing in that sphere.

The area of a bank that generate money employs the smartest people, usually coming from academia. So, it doesn't surprise me.

Re: C++ in Coders at Work

#58

Earlier quoted context omitted.

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.

No, C is a portable assembler. C++ was created to add "high level" OO features to C. But the success of the effort is highly controversial, because there are differences between C and the OO model that are too difficult to overcome. I think the strategy of objective-C is much cleaner, since they better separate the concerns of "writing fast code" and "writing high level OO abstractions".

People need fast high level OO abstractions all the time: Abstract Factory, that sort of thing.

C++ is still the only game in town if you need to model something complex, as in a game or a simulation, where performance matters.

I don't understand why so many people toss off one liners singing the praises of C while damning C++. C's casting and general attitude to types is evil. void* must die. Do people like mysterious segfaults? Templates error output may suck right now, but it sure beats the crap out of scratching your head in front of the debugger weeks later.

Re: C++ in Coders at Work

#59
post #47
post #39

Earlier quoted context omitted.

Please, use a precise term if you talk about multiple inheritance, even though in this case it is clear that C++-MI is the multiple inheritance is meant. In general, there is at least the linearizing (Common lisp) multiple inheritance with a well defined method lookup semantics (even though there are good ways to shoot one into the foot there), and the C++-local-hackity-multiple inheritance (where the programmer has…

Different problem, different constraints, different solution. And, inevitably, just different ways to shoot yourself in the foot. Please explain how Common Lisp multiple inheritance relates to the question at hand, which is whether the complexity of C++ came from undisciplined language design or was inevitable given the design constraints of the language.

The distinction matters, because the multiple inheritance in common lisp (and other linearizing languages) is a lot saner and easier to use than multiple inheritance where the programmer has to define the method lookup sequence, which in term implies that multiple inheritance in itself is not the sole cause of complexity in this context, but rather the implementation of multiple inheritance in the given language (C++).

Re: C++ in Coders at Work

#60

Earlier quoted context omitted.

If you code in a 'safe' way and you stay away from nifty tricks then you are in good shape. I'm sure you have a little list of stuff that you should stay away from or that you would at least discourage. The problems usually come when people start to use all those nifty features in combinations, especially 'newbie' programmers going wild on all that high level sugar. C/C++ is performance wise also as good as unbeatabl…

But think about open source code. Anyone can contribute code, so if you're using C++ you will get code from people from all levels of understanding of C++. This is a reason why some open source people prefer to use C, because they won't spend time saying what can or cannot be used in the project. An example is Google. They had to create a huge document to describe what part of the language their developers can use: h…

Most of that is 'plain good sense' in any environment, here are a couple that target specific C++ pitfalls:

- Only very rarely is multiple implementation inheritance actually useful. We allow multiple inheritance only when at most one of the base classes has an implementation; all other base classes must be pure interface classes tagged with the Interface suffix.

- Do not overload operators except in rare, special circumstances.

- Make all data members private, and provide access to them through accessor functions as needed. Typically a variable would be called foo_ and the accessor function foo(). You may also want a mutator function set_foo().

- All parameters passed by reference must be labeled const.

- Do not use function overloading to simulate default function parameters.

- We do not allow variable-length arrays or alloca().

- Be very cautious with macros. Prefer inline functions, enums, and const variables to macros.

The only thing that struck me when reading this that I do different is the use of ++p, I would avoid that at all costs.

Pre-increment is a great way to confuse people. I can see why they would use it though, another similar source of confusion (stemming from C really) is the difference between

    *p++ 
and

    (*p)++;
Post reply on HN