C++ in Coders at Work • Hacker News Board

Re: C++ in Coders at Work

#81

Post by coliveira » Fri, Oct 16, 2009, 6:38 PM UTC

jacquesm wrote: post #60

coliveira wrote: post #54

Earlier quoted context omitted.

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 ci…

When working with objects you should always do ++p instead of p++. The later one creates a temporary, so you have to work extra hard for nothing.

Re: C++ in Coders at Work

#82

Post by dkarl » Fri, Oct 16, 2009, 6:43 PM UTC

tetha wrote: post #59

dkarl wrote: post #47

Earlier quoted context omitted.

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++…

CLOS method dispatch does not meet the design criteria of C++. It uses runtime information about inheritance relationships, for example.

Also, note that there is also a semantic difference here between C++ (and Java) and most other languages. In C++ multiple inheritance, if classes A and B define method foo, and A and B have no inheritance relationship, then A::foo and B::foo are entirely unrelated methods -- just as if they were named A::foo and B::bar. The fact that they have the same name does not automatically create a relationship between them, as it would in CLOS or in duck-typed languages like Python. That means that a call to foo in a class that inherits from A and B is just as ambiguous as if the programmer had typed "foo, or maybe bar." This unrelatedness is inherent to C++'s type system. It would make no sense to a C++ programmer to treat A::foo and B::foo as being alternative dispatch targets for the same method call.

Even if you allow the compiler to gloss over this unrelatedness, I still think it is a matter of taste whether it is simpler to require programmer disambiguation or to have a well-defined algorithm for resolving ambiguous names. C++ usually takes heat for providing powerful more-than-meets-the-eye mechanisms that allow programmers to "hide" program semantics inside language features. Here C++ takes the opposite approach and requires the programmer to explicitly resolve ambiguous names, and it takes heat from a CLOS programmer, who could write an entire operating system using a single family of generic functions all having the same name ;-) Damned if you do, damned if you don't.

Re: C++ in Coders at Work

#83

Post by [deleted] » Fri, Oct 16, 2009, 6:44 PM UTC

Periodic wrote: post #77

raganwald wrote: post #14

Earlier quoted context omitted.

Bjarne was truly correct when he said: "there are languages people complain about, and there are languages nobody uses." I think this is very true, what it says literally is that popularity and attracting ire are correlated. However, my interpretation is that the reason why this is true is that (1) all languages involve design trade-offs, (2) every trade-off pisses someone off for at least a moment, and (3) popularit…

My first impression of the quote is that any language that gains enough users will find people who complain about it. However, I agree that his main point is more that you will never be able to design a language that is useful to a large number of people without making compromises, and with any compromise there will be at least one person for which it is not the optimal solution. I don't want to say the relationship…

[deleted]

Re: C++ in Coders at Work

#84

Post by jacquesm » Fri, Oct 16, 2009, 6:45 PM UTC

coliveira wrote: post #81

jacquesm wrote: post #60

Earlier quoted context omitted.

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 ci…

When working with objects you should always do ++p instead of p++. The later one creates a temporary, so you have to work extra hard for nothing.

That's an interesting one, I never even thought of that! Thanks.

Re: C++ in Coders at Work

#85

Post by scott_s » Fri, Oct 16, 2009, 6:46 PM UTC

jacquesm wrote: post #64

monos wrote: post #26

Earlier quoted context omitted.

> C accurately models how the computer actually works i don't even know on what kind of hardware my java or python programs run. neither google (appengine) nor our IT apartment tell me. so for most app developers "a computer" is not really something they work with. of course someone must write those abstractions (python, etc), and they do it in C/C++ :)

But I can safely say that it is a machine that the C language models fairly precisely and that python, lisp etc will use in ways that will make it harder to predict how their constructs will interact with the machine. That's exactly the point, if your machine is anywhere near 'standard' (as in not a SIMD or something exotic) then C is as close as you can get to it without going to assembler.

I characterize C as a portable assembly language.

Re: C++ in Coders at Work

#86

Post by scott_s » Fri, Oct 16, 2009, 6:49 PM UTC

jacquesm wrote: post #68

dkarl wrote: post #52

Earlier quoted context omitted.

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?

I think operator overloading, which seemed like a 'great idea at the time' with some forethought should have never been part of the language in the way it works right now. The times that I ran in to examples where it was used properly and elegantly I think it could have been done just as nice with a properly named function call. I think the way it workd came from the DSL camp arguing that you should be able to make i…

http://spirit.sourceforge.net/

It's a DSL that is similar to EBNF that generates parsers. It would be considerably more difficult to use without operator overloading.

Re: C++ in Coders at Work

#87

Post by rpledge » Fri, Oct 16, 2009, 6:52 PM UTC

jacquesm wrote: post #74

rpledge wrote: post #71

Earlier quoted context omitted.

I have a list of things to stay away from indeed, but it's due to my own sanity of being. For example, without GC exceptions are almost always going to cause leaks without the team being all C++ experts. If I was designing in Java exceptions are wonderful, in C++, asking for issues

> but it's due to my own sanity of being. I think that is what such lists have in common :) > For example, without GC exceptions are almost always going to cause leaks without the team being all C++ experts. That is something I rarely have had trouble with, but I never worked much in teams. I did notice that the double-free and never-freed pointers are a good portion of the problems you encounter in live code though.…

Throwing an exception isn't saying "I don't feel like dealing with this", but rather, "A problem has occurred". In C++ (ignoring exceptions), you typically (or hopefully!) return an error code and rely on the caller to handle the issue. In Java, with checked exceptions, a catch or declaration that the current method can throw the same exception is needed for compilation.

Now, this doesn't stop empty catch blocks or other horrible coding practices, but professional software engineers should never let that happen in their code (and there are lots of people who do, and they shouldn't be getting paid to write code!)

Checked exceptions wouldn't fix the memory leak issues in C++, I routinely use the shared_ptr template to fix that, but it would be a good step forward.

Re: C++ in Coders at Work

#88

Post by jacquesm » Fri, Oct 16, 2009, 6:56 PM UTC

rpledge wrote: post #87

jacquesm wrote: post #74

Earlier quoted context omitted.

> but it's due to my own sanity of being. I think that is what such lists have in common :) > For example, without GC exceptions are almost always going to cause leaks without the team being all C++ experts. That is something I rarely have had trouble with, but I never worked much in teams. I did notice that the double-free and never-freed pointers are a good portion of the problems you encounter in live code though.…

Throwing an exception isn't saying "I don't feel like dealing with this", but rather, "A problem has occurred". In C++ (ignoring exceptions), you typically (or hopefully!) return an error code and rely on the caller to handle the issue. In Java, with checked exceptions, a catch or declaration that the current method can throw the same exception is needed for compilation. Now, this doesn't stop empty catch blocks or o…

Aye, I hear you. But the problem is not that people use stuff the way it is intended, but they will use it in ways that it is not intended!

> Now, this doesn't stop empty catch blocks or other horrible coding practices,

Exactly...

> professional software engineers should never let that happen in their code

I could show you some horror stuff I'm dealing with right now that does exactly that.

The bigger problem is that it works and that I'm having a hard time convincing other people that that is not how it is done.

Re: C++ in Coders at Work

#89

Post by scott_s » Fri, Oct 16, 2009, 6:59 PM UTC

alrex021 wrote: post #69

haberman wrote: post #43

Earlier quoted context omitted.

JSON is not a programming language.

You are absolutely right. My point exactly. Now you need "two hammers" to get a single job done. Your current programming language of choice and a data expression language. For example: In C, C++, Java, or related, you "first" have to build you structure to represent a Person with first_name and last_name and then you have to write it to JSON: Java: class Person { String firstName; String lastName; } JSON with JavaSc…

Not all problems require communicating your data structure outside of the program. And I don't think it's accurate to say "Now you need." For problems where you do need to communicate data outside of the program, that's been true since the days of Fortran.

Re: C++ in Coders at Work

#90

Post by joe_the_user » Fri, Oct 16, 2009, 7:00 PM UTC

jimbokun wrote: post #76

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…

"Part of how C++ is successful is that it retains C compatibility" I think Objective C is a better object oriented C than C++. It's simpler, makes a syntactic distinction between message passing and "traditional" C, and has a more dynamic run time. I'm surprised no one else has brought up Objective C as a better solution to the "make C object oriented" problem.

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 appropriate.

I currently suspect one should have either "full" object orientation plus weak typing OR weak object orientation plus strong typing. 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.

While Ruby or Python allows compact but slow code, Java and C#, among other excesses, force one to create a full class for every two-field data-structure. Thus C++ is more compact than C# and Java and faster than Python and Ruby, winning for race for a desktop application language (oddly enough, desktop apps need a fast language because they must compensate for desktop windowing systems being more bloated and users expect more from their machine each).

I'm sure Haskell or Lisp are excellent for some things but I don't think their paradigm is very compatible with GUI programming - I'd be interested if someone has a counter-example.