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

111–120 of 174 posts

Re: C++ in Coders at Work

#111

Post by barrkel »

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…

The computer is actually has a von Neumann architecture, that is, they have code and data in the same address space.

To the degree that C represents this reality, it is through exploits: e.g. buffer overflows, overwriting the stack and return address, and executing arbitrary code supplied by attackers. C itself does not represent the reality very well, since it does not lend itself to writing code that writes code at runtime.

Re: C++ in Coders at Work

#112

Post by barrkel »

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.

This is only true to a degree.

The only reason you know what the C you write will end up doing on the machine is because you are generally not doing much when you're working in C.

If you want to get productive work done, you'll be leveraging lots of libraries written by third parties, and you have no more insight into how they are working when you're invoking them with C than Ruby, Python, Java, C#, or any other language.

Re: C++ in Coders at Work

#113

Post by barrkel »

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…

At least C# doesn't require you to allocate a file for your class, and a simple two-field class should consume no more than 5 lines of code. And if you're willing to use a generic tuple type, you don't need to declare a class at all; just use Tuple as needed.

Re: C++ in Coders at Work

#114

Post by sshumaker »

C++ is pretty awful to develop in, especially compared to many other languages. Some of these issues have to do with poorly designed features in the core language (templates), static variable instantiation, no good way for declaring complex data structures in the language (a'la JSON), multiple inheritance, etc.

But this isn't just a problem with the core language itself, but with the compilation model and linkage model - and the compilers and linkers. You need include guards on the top of your header files to make sure the code doesn't get re-included. You have to aggressively forward declare to work around declaration dependencies. And you have to trim the files that you include to keep compile times under control, because here's the fun thing about C++: For every .cpp file in your project, you will end up reading in and parsing the same damn header files again and again. In a large project, that might mean recompiling the same header files 1000s of times. Precompiled headers aren't a good solution, either - because when you have to touch the header, you pay a huge cost in recompiling the PCH.

In every other language I've used, I haven't had to worry about carefully restructuring code (sometimes at a cost in performance) to reduce compile times - because the core include and dependency mechanism sucks so badly.

Finally, C++ as a language is very poorly extensible. By this, I mean in compared to languages like LISP (with macros), or Ruby / Scala, which both make writing DSLs very easy. This is especially unfortunate, given that is so heavily used in a lot of very specific domains. And don't get me started on templates - I couldn't dream up a more backwards and awkward way of doing generics if I tried.

Re: C++ in Coders at Work

#115

Post by jacquesm »

barrkel wrote: post #112
jacquesm wrote: post #64

Earlier quoted context omitted.

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.

This is only true to a degree. The only reason you know what the C you write will end up doing on the machine is because you are generally not doing much when you're working in C. If you want to get productive work done, you'll be leveraging lots of libraries written by third parties, and you have no more insight into how they are working when you're invoking them with C than Ruby, Python, Java, C#, or any other lang…

I think you're missing the point here.

A C program that accesses the memory will do so in an extremely predictable way, if I lay out a memory structure, a piece of code and an access pattern then I can be very sure about how that will interact with things like the caches.

In other languages where there is more 'under the hood' that is a lot harder.

Libraries don't enter in to the problem, that's another level altogether.

While it's true that library code written by third parties might be less (or more) efficient than the code you wrote, even those libraries will have the luggage of the underlying implementation of the language.

In C there is no implementation underneath, it is a 1:1 correspondence with machine instructions.

That is the reason that kernel code tends to be written in C.

Re: C++ in Coders at Work

#116

Post by jacquesm »

lacker wrote: post #98
citizenparker wrote: post #65

Earlier quoted context omitted.

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

Thus proving the authors point even further.

It is funny how everybody really seems to have their own favorite subset of C++.

Re: C++ in Coders at Work

#117

Post by gaius »

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…

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 :-)

Re: C++ in Coders at Work

#118

Post by scott_s »

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…

That's also an example in favor of why syntax highlighting is a good thing.

Re: C++ in Coders at Work

#119

Post by tptacek »

I'm liking these Seibel digest posts more than I'm liking the actual book, which, even in the Norvig chapter, drags a bit.

I think the book might have worked better if it was organized topically, instead of by person.

Re: C++ in Coders at Work

#120

Post by tptacek »

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.

Objective C is cleaner and much more fun to write in, but it's less accommodating than C++:

* You have to actually run the dynamic runtime, which even OS X's XNU doesn't do.

* The dynamic runtime also obscures what's going on with the hardware, which can be a problem in embedded environments.

I like Objective C but it's always felt like voodoo to me. I'm always more comfortable in Ruby+C than I am in ObjC.

Post reply on HN