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

131–140 of 174 posts

Re: C++ in Coders at Work

#131

Post by barrkel »

jacquesm wrote: post #115
barrkel wrote: post #112

Earlier quoted context omitted.

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

I think my point is that you can lose track of the woods for all the trees; moreover, C is not actually a good map with the underlying hardware.

In C, you deal with so many trees, it sure feels like you're right there in the woods. But actually, if you're dealing with things on a tree by tree basis, you're not getting much done. And you can pretty lose your way by focusing on navigating territory efficiently at that level, but not keeping track of the overall goal.

As to whether kernel code should be written in C, that is a different matter. C is not a good map to von Neumann architectures because it doesn't model shared code and data in memory - C doesn't have a good representation for writing code at runtime. Most code written in C will not be the most efficient possible code for this reason.

Re: C++ in Coders at Work

#132

Post by gchpaco »

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 chief problem with the idea that C "accurately models how the computer actually works", as you allude to but don't go into detail, is that modern CPUs work nothing like the CPUs that C is accustomed to. Between out of order execution, hyperthreading, caches, prefetching, pretending-to-be-uniform-memory-access-but-not-actually-being-it and concurrency the degree to which C's computer model is relevant is rapidly shrinking. We don't really have a good model for this, but that's not really a good excuse to keep writing new languages based on C.

Re: C++ in Coders at Work

#133

Post by mbrubeck »

dkarl wrote: post #61
mbrubeck wrote: post #46

Earlier quoted context omitted.

Operator overloading in C++ is indeed more complex than it should be, thanks in part to the three different ways to pass paremeters (references, pointers, and values). It's definitely more straightforward in languages like C# or Python (or, well, just about anything else) that don't have these explicit distinctions.

The distinction between pointers and values (and the ability to treat pointers as values) is necessary for many applications of C++, so that complexity _should_ indeed be in the language. You may be right that the distinction between pointers and references is gratuitous. Ordinarily, one defines an overloaded operator using reference arguments (never pointers; only values if you're doing performance microoptimization…

"that complexity _should_ indeed be in the language"

Oh, absolutely. I just meant that it adds some incidental complexity to operator overloading that doesn't exist in other languages.

Re: C++ in Coders at Work

#134

Post by mbrubeck »

jacquesm wrote: post #116
lacker wrote: post #98

Earlier quoted context omitted.

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

Just as Lisp programmers add new syntax and vocabulary to build custom languages, C++ programmers do the same by taking them away.

Re: C++ in Coders at Work

#135

Post by huhtenberg »

jacquesm wrote: post #7

> Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair. > And he said “no” to no one. And that is the core of the problem.

Well, he did say No to the concepts just few months ago, and that was one of more useful features proposed for C++0x. Though one has to admit it was an over-engineered, ugly monstrosity (surprise) and it was quite far from a simple and elegant idea that was long lobbied for by Alex Stepanov & Co.

Re: C++ in Coders at Work

#136

Post by jacquesm »

scott_s wrote: post #125
jacquesm wrote: post #116

Earlier quoted context omitted.

Thus proving the authors point even further. It is funny how everybody really seems to have their own favorite subset of C++.

Most users also probably have their own favorite subset of Word.

You've nailed it right on the head there though, when offered a bloated solution, people will 'subset', when offered something small and powerful people will customize.

Re: C++ in Coders at Work

#137

Post by jacquesm »

aminuit wrote: post #126
jacquesm wrote: post #27

Earlier quoted context omitted.

I remember 'cfront', when it first came out, and to this day I haven't really changed my mind on how I felt about it, it's a much too bloated language compared to the elegance of C. If 'C' would have had a decent native string type I think C++ might not have happened ;)

Are you suggesting that std::string, or as my not-so-friendly c++ compiler likes to call it std::basic_string ::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits , _Alloc = std::allocator ] is an improvement? :-)

No, not at all. I was thinking of strings the way Dennis Ritchie would have done it.

I can see why they chose to omit it, but in retrospect I think it was a mistake. The problem they were faced with was that the language didn't include any 'runtime' at all the way they wrote it, a string package would have made it a must to have some runtime.

Everything that is 'runtime' in C is in libraries, and everything that is 'core' is in the compiler.

Re: C++ in Coders at Work

#138

Post by jacquesm »

russell wrote: post #122
loup-vaillant wrote: post #25

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.

In general, hardware optimized for high-level languages have been a failure, usually the extra baggage for handling things as machine-level interpreter slow things down nearly as much as a software interpreter. Nothing has been a real commercial success and it isnt for want of trying. Off the top of my head I can think of the Burroughs B5500 which had hardware support for typed data, the Lisp Machine, and the Intel 4…

There is forth on hardware, and a long tradition of that. It's still alive and kicking.

Re: C++ in Coders at Work

#139

Post by jacquesm »

haberman wrote: post #127
jimbokun wrote: post #51

Earlier quoted context omitted.

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

Consider that JSON has features Lisp does not. Like a tiny implementation, very wide language interoperability, being purely a data language (sandboxed by design), and not being Turing-complete (time to interpret is automatically bounded).

> (time to interpret is automatically bounded).

Well, at least for that particular set of cases I think you've just solved the halting problem ;)

Re: C++ in Coders at Work

#140

Post by jacquesm »

barrkel wrote: post #111
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…

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

The ones that do not are actually pretty rare.

Most of those use the 'harvard architecture' and are DSP style machines.

And then there are vector processors and SIMDs, but even those can be seen as many von Neumann machines running in lock-step.

Post reply on HN