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.
C++ in Coders at Work
51–60 of 174 posts
Re: C++ in Coders at Work
#52Earlier 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.
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
#53This 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…
There are a lot of Java implementations, and I am not aware of serious compatibility problems between them.
Re: C++ in Coders at Work
#54Earlier 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…
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
#55This 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…
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
#56Part 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++.
Re: C++ in Coders at Work
#57Earlier 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.
Re: C++ in Coders at Work
#58Earlier 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".
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
#59Earlier 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.
Re: C++ in Coders at Work
#60Earlier 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…
- 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)++;