Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ in Coders at Work

gigamonkeys.com

Post reply on HN
Print view View original

91–100 of 174 posts

Re: C++ in Coders at Work

#91

Post by jacquesm »

dkarl wrote: post #82
tetha wrote: post #59

Earlier quoted context omitted.

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…

> who could write an entire operating system using a single family of generic functions all having the same name ;-)

I sense an upcoming challenge! ;)

Re: C++ in Coders at Work

#92

Post by varjag »

amalcon wrote: post #12
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…

C is a portable assembler. Sometimes that's exactly what you want. C++ is C, except that it doesn't completely suck for higher-level projects.

I would say C++ is somewhat less portable assembler than C, due to different linker semantics, which is not unified across platforms.

Re: C++ in Coders at Work

#93

Post by jacquesm »

scott_s wrote: post #86
jacquesm wrote: post #68

Earlier quoted context omitted.

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.

Agreed, DSLs are the one area that I can think of where overloading is a 'natural'.

Unfortunately its use is not quite limited to code like that.

Re: C++ in Coders at Work

#94

Post by dkarl »

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…

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 did some crazy and irresponsible things in college, just like everyone else.

If there's one point I've been wanting to make over and over again in this discussion, it's that misuse of language features is a much smaller problem than people think. (In practice, it is even negligible next to the overhead of reading poor error messages from the STL.) C++ is a very bad programming language for people who fear their coworkers, but so are C, Ruby, and any Lisp with macros. Even Java isn't protection against stupidity: a bad Java programmer on your team can't confuse you, but he can bury you.

Just think of defmacro as implicitly adding an infinite number of infinitely complex language features to Lisp. If you can deal with defmacro in a responsible way, operator overloading shouldn't bother you at all.

Re: C++ in Coders at Work

#95

Post by jacquesm »

joe_the_user wrote: post #90
jimbokun wrote: post #76

Earlier quoted context omitted.

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

Haskell is pretty theoretical, but on the lisp front I think AutoCad and Emacs more than qualify.

Re: C++ in Coders at Work

#96

Post by dkarl »

rpledge wrote: post #71
jacquesm wrote: post #36

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…

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

exceptions are almost always going to cause leaks without the team being all C++ experts

Don't give up exceptions; give up naked pointers. Use shared_ptr and scoped_ptr, and you won't have memory leaks due to exceptions. Use RAII consistently, and you'll find it's actually easier to handle resource management in C++ than in Java. Java's resource management is superior for memory but inferior for every other resource.

Re: C++ in Coders at Work

#98

Post by lacker »

citizenparker wrote: post #65
snprbob86 wrote: post #56

Earlier quoted context omitted.

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.

Thus proving the author's point.

But C with vector, string, hash_map, const&, destructors and scoped_ptr is a pretty good language! It's certainly better than plain C. It's just not as aesthetically pleasing that it sits inside the larger monstrosity that is C++.

Re: C++ in Coders at Work

#99

Post by philwelch »

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.

Hence the old joke that C++ should really have been called ++C because "C++" violates good C++ practice.

Re: C++ in Coders at Work

#100

Post by jacquesm »

dkarl wrote: post #94
jacquesm wrote: post #68

Earlier quoted context omitted.

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…

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, because you understand fully what the consequences are when you are using them improperly. If a situation is a 'natural' for overloading then you'll use it, otherwise you'll use a function with a descriptive name.

Unfortunately that is not the norm. You'd almost want an '--expert' flag given to the compiler before you are allowed to use those features, and every time you want to use it you get this trick question about some obscure bug that you have to answer :)

The best little C bug I saw in some forum somewhere by the way was this one:

            int x,y;
    
            x = 0; /* initialize both x
            y = 0;    and y to 0 */
   
            domorestuff(x,y);
Of course any C programmer worth his weight will spot that one in a heartbeat, but it is indicative of how easy a language 'feature' (multiline comments) can become a bug.
Post reply on HN