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

Zed Shaw on C++

librelist.com

Post reply on HN
Print view View original

191–200 of 210 posts

Re: Zed Shaw on C++

#191

Post by kragen »

wglb wrote: post #125
woadwarrior01 wrote: post #89

Earlier quoted context omitted.

Ironically, the whole iphone apps goldrush seems to have contributed in a big way to increase its mindshare. Obj-C is very beautifully designed, I especially like how it adds message passing OOP to C with very minimal syntax additions. But then calling objc_msgSend for every message send, does have a small performance penalty attached, which mostly static languages like C++ don't have to pay.

So does C++ have any price to pay for say vtables?

vtables in C++ aren't free, but C++ has a couple of advantages here:

• If you're calling a nonvirtual method, you don't have to pay the vtable cost at all, just the cost of passing this. And most methods in C++ are nonvirtual.

• A call through a vtable is typically a couple of indexed fetches and an indirect jump. Objective-C's mechanism involves a hash-table lookup, which is a bit slower.

Re: Zed Shaw on C++

#192

Post by kragen »

ericb wrote: post #31
WilliamLP wrote: post #26

Earlier quoted context omitted.

It has grabbed and maintained complete domination of nearly all performance sensitive code in games and desktop software, for nearly a generation now which is an unprecedented reign in computing history. That's a pretty good start to me.

Are you saying that the complete domination claim is also true in comparison to C ?

I don't know if he's saying that, but yes, nearly all performance-sensitive code in games and desktop software is written in C++, not C. Objective-C seems to be edging in.

Re: Zed Shaw on C++

#193

Post by mhd »

microtonal wrote: post #91
mhd wrote: post #28

Earlier quoted context omitted.

I really dislike C++ but more to the point I really dislike other people's C++. That's right on the money. I can find a subset of C++ that I like and that I could program with, but that assumes that I'm not collaborating with someone and that I don't have to use C++ libraries (It's not just the code, it's the APIs, too). The latter is almost worse. I could imagine a company that has some rather strict standards, wher…

There are some very good template-based libraries. I think STL is mostly ok, but also libraries like Eigen are great, and avoid a lot of code duplication through templates. http://eigen.tuxfamily.org/index.php?title=Main_Page

Templates as they were used/implemented in earlier days where quite okay, apart from having to use other people's libraries, I preferred to solve problems using generic programming than just building class hierarchies (which now nicely translates to functional programming).

Apart from very crappy compiler support (looking at you, Microsoft) I really liked the STL. It's simple enough (maybe a bit too simplistic).

Template meta-programming is a whole 'nother deal. It's like the rabid daughter of an unhappy marriage between Lisp's macros and Perl. From some angles, she looks rather enticing. Then she bites down on your crotch.

Re: Zed Shaw on C++

#194

Post by joe_the_user »

wglb wrote: post #124
joe_the_user wrote: post #39

Earlier quoted context omitted.

My short rant: C++ is as bad as they say it is. It is horrible, it is the worst language in the world ... except for all the other (a la Winston Churchill and democracy). The horrifical complexifications of C++ are just terrible, yet every one of them has a reason behind it. And also, the horrifical complexities are a bit more optional than the horrifical complexities of, say, Java. There isn't another language that…

There is no other language for crafting large-scale, high performance tools is demonstrably false. There are high-volume low latency world-class financial systems written totally in Java. The seriously complex and high-performance ITA system is written in Lisp. And if you read Coders at Work, some of the criticisms of C++ suggest that the reason behind many of the C++ features is that Bjarne didn't want to say NO . A…

Well, it was a rant (as requested)...

I should have said "there is no other language which gives you the latitude for crafting high performance tools". You can indeed create serious high performance systems in a number of languages. The thing about most languages other than C and C++ is that things written in them tend to inherit their qualities - A system written in Java generally use Java's garbage collector. That works great for a number of things but it's still a constraint.

More of C++'s "modularization" features are optional than in the other languages so you have more latitude for creating your tools than anywhere else.

Of course, you do get the badness too...

Re: Zed Shaw on C++

#195

Post by kragen »

kragen wrote: post #189
zedshaw wrote: post #78

Earlier quoted context omitted.

Well, we can agree to disagree here, but my belief is that OO is a impedence mismatch for writing "low-level efficiency of direct pointer manipulation and other C features". It's kind of like saying, "There is no 16 wheel semi truck that can win the Tour De France." Maybe you shouldn't be using a 16 wheel truck.

If you cut a couple wheels off of an 18-wheeler, you could travel the 3642 km of the Tour de France in about 36 hours of driving, which would be about 3 days on a leisurely, safe schedule. The bicyclists take 22 days to do the same thing. So, there are really only a couple of problems: • if you're Zed Shaw, you apparently want to cut two wheels off an 18-wheeler, and if you're Zed Shaw, you're likely to screw up and…

And Vala. How could I forget Vala?

Re: Zed Shaw on C++

#196

Post by tbrownaw »

eru wrote: post #148
tbrownaw wrote: post #134

Earlier quoted context omitted.

> And for application-level programming, why would you chose a language without a garbage-collector? Because your code uses some finite resources other than memory, and you don't want the ability to forget to release said resources when you're done with them and they go out of scope.

Why should memory management related to managing other resources. Anyway, you might be interested in The Haskell Disciplined Disciple Compiler ( http://www.haskell.org/haskellwiki/DDC ) which lets you statically encode resource management rules. (And of course spots garbage collection for memory.)

Your objects contain/use various resources, such as memory, file descriptors, mutexes, etc. The way to reclaim any of these is to destroy the object, which lets you reclaim all of them. So memory management is very much tied to other resource management, since they both involve the same thing (deciding when to destroy objects you no longer need). Unfortunately not all resources can be collected equally lazily, so memory-centric GC schemes that ignore the requirements of other resources tend to get in the way (and make you do using(){...} or try/finally to make sure your files are closed, instead of allowing for RAII).

Re: Zed Shaw on C++

#198

Post by charlie_root »

WilliamLP wrote: post #23
blantonl wrote: post #9

Zed is literally the Kimbo Slice of the technical community.

Wow, an MMA analogy on this site? Who are Seth Petruzelli, Roy Nelson, and Matt Mitrione then?

Donald Knuth is Hélio Gracie

Edsger Dijkstra is Masahiko Kimura

John McCarthy is Yip Man

Paul Graham is Bruce Lee

Steve Jobs is Fedor Emelianenko

Linus Torvalds is Mauricio Rua

Bill Gates is Brock Lesnar

Steve Ballmer is Eric Esch

David Heinemeier Hansson is Anderson Silva

Guido van Rossum is B.J. Penn

Sergey Brin is Antônio Rogério Nogueira

Lawrence Page is Antônio Rodrigo Nogueira

Re: Zed Shaw on C++

#199

Post by [deleted] »

jimbokun wrote: post #169
stoney wrote: post #57

Earlier quoted context omitted.

The great thing about const is that if you don't like it you can pretty much ignore it. The only time it might be necessary to deal with it is if you are using a library that returns const objects. If you do like const (which I do) then you can put it in pretty much everywhere, except if you are dealing with a library that isn't "const correct", but then a bit of type casting will save the day. That's a big advantage…

"If you do like const (which I do) then you can put it in pretty much everywhere" In retrospect, it might have been better to have a keyword for things that can change. This goes equally for Java and "final". Making immutability the default and mutability opt-in makes for fewer bugs and more reliable programs. Arguably, this is what Clojure does where you have functional, immutable constructs by default with ways to…

[deleted]

Re: Zed Shaw on C++

#200

Post by ramchip »

jimbokun wrote: post #169
stoney wrote: post #57

Earlier quoted context omitted.

The great thing about const is that if you don't like it you can pretty much ignore it. The only time it might be necessary to deal with it is if you are using a library that returns const objects. If you do like const (which I do) then you can put it in pretty much everywhere, except if you are dealing with a library that isn't "const correct", but then a bit of type casting will save the day. That's a big advantage…

"If you do like const (which I do) then you can put it in pretty much everywhere" In retrospect, it might have been better to have a keyword for things that can change. This goes equally for Java and "final". Making immutability the default and mutability opt-in makes for fewer bugs and more reliable programs. Arguably, this is what Clojure does where you have functional, immutable constructs by default with ways to…

const by default may not be a bad idea, but immutability of structures/objects in C++ sounds like it would be a huge performance hit to me. I've used an image processing library (CIMG) which lets you do things like `img = img1 * 2 + img2 * 0.5`, instead of editing the image in-place. It's pretty, but with regular 800x600 images the performance was around 2 orders of magnitude below a simple for loop... it made a lot of extra copying and allocation instead of mutating the image.

The thing is, this kind of code isn't an exception in the C++ world. C++ is made for problems where performance matters: image processing, compilers, browsers... immutability works for Clojure, but Clojure is a lot slower than C++. It's more of an "enterprise software" language.

Post reply on HN