One of the very few situations in which I think Unix did things better than stuff that came later is libraries. Well-architected C APIs are so much easier to deal with than COM-like systems. (Not that Unix APIs were well-architected, mind you)
-
-
-
Replying to @whitequark @pcwalton
or more precisely, the dynamic linkers i feel like if you have to have a segment specifically dedicated for something C++ invented you have failed on multiple occasions *waves hands* somewhere in the design
2 replies 1 retweet 6 likes -
Replying to @whitequark @pcwalton
whys that, extending tooling to support new language features sounds somewhat reasonable? i mean not mounting a defense of linkers in general
1 reply 0 retweets 0 likes -
if you need to support C++ specifically in it your linker is either too specialized or too generic consider: do you see Solaris ld ever getting a feature to support Rust specifically? not happening
2 replies 0 retweets 0 likes -
Replying to @whitequark @__vlqc
Ever looked into .__objc_methname, etc.? It’s far worse :)
1 reply 0 retweets 1 like -
they wouldn't put meth in the name if it was a good thing methinks
1 reply 0 retweets 8 likes -
... but no, I didn't. I did look into objc_msgSend and inline caches, but the thing you refer to has elided me. got a link?
2 replies 0 retweets 1 like -
tl;dr: if you put strings in that specific section the objc runtime will gobble them up and register their addresses as selectors, so you can pass their addresses directly to msgSend without ever having to querySelector
1 reply 0 retweets 1 like
Actually the strings don’t have to be in that section at all. It only looks at __objc_selrefs. I haven’t found any use for __objc_methname except that I think ld takes a fast path for that section.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.