Comments on: I Didn’t Order That, So Why Is It On My Bill, Episode 1

By: Xo Wang

Xo Wang — Tue, 23 Mar 2010 23:17:09 +0000

This blog is fantastic! I’m student who has been using C++ for about 3 years now, and I’ve noticed that what I’ve learned with each project were features and quirks of C++, and how or why *not* to use them. This little column introduced me to a new facet of the language—features I don’t need but still pay for.

By: Phil

Phil — Wed, 21 Oct 2009 22:34:12 +0000

rmn: This is a runtime cost. Consider a program that is run very often, and takes very little time. The linking can come to be the dominant term in total execution time. Consider also programs that can load dynamic libraries as plugins, or interpreters for some other language with a foreign function interface. We pay the cost at each load there, too.

By: rmn

rmn — Thu, 17 Sep 2009 19:31:01 +0000

Well, you said you were going to say how we’re paying for this at runtime – but you haven’t. I wouldn’t consider the time it takes to load shared libraries as “runtime” since, well, it is not the run time of your own code. For the same reasoning you could say that context switches are part of your runtime and are somehow related to C++, but that would not make a valid point imo.
Nice read though.

By: Pierre Lebeaupin

Pierre Lebeaupin — Mon, 29 Jun 2009 12:19:42 +0000

(I was not answering “Someone” with my post, btw.)

By: Pierre Lebeaupin

Pierre Lebeaupin — Mon, 29 Jun 2009 12:15:13 +0000

Well, if you read about symbol resolution in the Mach-O runtime (or for that matter, ELF), you realise that even in C some work needs to be done to ensure pointers to the same function always compare equal, e.g. one consequence is that a function from a dylib cannot be resolved lazily in a module where its address is taken (the address of the stub function cannot be taken as then it wouldn’t compare equal to the function pointer address taken from within the dylib, or one taken from another module). Some time after reading in these docs the care that needs to be taken to ensure that, I was thinking about how to implement a feature (in code that needs to be so cross-platform it’s not even funny – think embedded RT OSes), and while it could make sense for it to rely on function pointer equality (long story), I thought “Hmm, I read about how Mach-O does this, it’s not trivial, perhaps other systems screw this up…” and decided the feature would query the function instead of comparing the function pointers (the feature has yet to be implemented, though). It’s only later that I learned that, on Windows, not only can two function pointers to the same function, but taken from different sides of a DLL boundary, compare different (learned from experimenting with a test case), but in fact two different functions can end up in the same address (and have function pointers compare equal) if they do the same thing (learned from the Old New Thing, of course, and confirmed experimentally)! Of course, the latter (and perhaps the former) can be prevented if you specify some “OMG be super respectful of all C semantics” flag, but how can you trust everyone who ever compiles your code to always set such a flag?…

By: Someone

Someone — Tue, 23 Jun 2009 19:26:15 +0000

I do not understand why -fvisibility-inlines-hidden would have to break “An inline function with external linkage shall have the same address in all translation units”. Couldn’t a compiler:
- in code that never takes the address of a function f:
– call an invisible copy of an inline function
– not generate a copy with external linkage
- in code that does takes the address of f:
– generate a copy with external linkage
– use that copy’s address as address of f (so that the linker has to do work to guarantee that all translation units get the same value for its address)

Technically, that would be in conflict with the standard, but how could a conforming program tell? If not, what is wrong?

By: DogCow

DogCow — Tue, 23 Jun 2009 15:18:50 +0000

Glad to see you’re updating the blog again!

By: Ross

Ross — Tue, 23 Jun 2009 14:02:18 +0000

(i just wanted to see what pi is so far, because i read the ‘what’s this’ link after reading the article.)

good article! can’t wait for the next ones..

By: david

david — Tue, 23 Jun 2009 11:23:16 +0000

great post, concise and interesting. however, who is exporting vector::* anyway? does this happen in any dylibs shipped in OSX?

By: Don Hersey

Don Hersey — Tue, 23 Jun 2009 09:47:58 +0000

I haven’t programmed in awhile, so go easy on me, I’ve been busy with other things, unfortunately. Is the intent here to protect memory-mapped I/O (ie volatile paramed fns)? Or if the fn has something equivalent to a ‘how many times have I been called’ counter? What, in your opinion, is the motivation for having things this way?