C vs C++, from the author of ZeroMQ
-
Bro do you even read? I've already said that there's just one in memory!
-
But...doesn't there have to be something somewhere that's referencing it? If a reference is counted but nothing is referencing it....?
-
Refcount is decreased in destructor. Now, reread post #337 and connect the dots.
-
-
([An example article by Stroustrup][1].)
[1]: http://www.stroustrup.com/Software-for-infrastructure.pdfI enjoyed that article. One particular highlight was the ambigiuity of this statement:
@Bjarne Stroustrup said:
My examples are in C++, the programming language
I know best.Does he mean:
- Bjarne Stroustrup's knowledge of C++ is better than his knowledge of other programming languages, or:
- Bjarne Stroustrup's knowledge of C++ is the best compared to anyone else's knowledge of it or:
- A bit of both?
This is also a fun quote:
@Bjarne Stroustrup said:
If it turns out that most reliability and efficiency problems
are best solved by a combination of lots of runtime
decision-making, runtime checking, and a heavy reliance
on metadata, then I have unintentionally written a history
paper.Filed under: Stroustrup, Stroustrup, Stroustrup, Malkovich?
-
"Distinguished head" is probably a better term, but "end" isn't wrong. :-)
[/quote]"Distinguished head" sounds like the discerning gentleman's happy ending.
-
-
@Gaska said:
Yeah, and my post doesn't contain lap dance.
Discourse 2.0?
Just imagine the cooties...
-
I don't think I've been confused by or had problems with exceptions, ever. Ever. Like, seriously, I didn't know it was possible for an experienced programmer to be confused by or distrust them.
Like a lot of these things, it's more of a historical/political problem than a technical problem. When exceptions were originally introduced into C++ (just in time for the C++98 standard?) they had a number of problems, such as being hard to use and making your code "slow". Even though most of these problems have now been overcome, there are still a few diehards out there who refuse to have anything to do with them.
The one remaining legitimate objection to C++ exceptions these days is that it's very hard to look at a function and say whether it's exception-safe or not. Even swapping a couple of lines around can ruin exception-safety (so, uh, don't do that, I guess...), where as with error-checked code, it is manifestly obvious whether the error checking is there or not.
At the end of the day, your best bet is probably just to keep functions as small as is realistically possible, so there's an upper limit on the number of things that can go wrong within the function.
-
I am on the camp that believes that applications should fail fast if they encounter something they don't know how to handle. For me, having the program fail gracefully and shut down when it encounters an unexpected error is a good thing.
...unless you're writing a webserver, in which case there's no such thing as shutting down gracefully?
-
-
Fhtagn!
-
...unless you're writing a webserver, in which case there's no such thing as shutting down gracefully?
People write web applications in C++?
-
Shut down and restart? It's not like the alternative is "work correctly", so what do you suggest?
-
Shut down and restart? It's not like the alternative is "work correctly", so what do you suggest?
The web server should email the user "COMPLAIN! Naughty user!"
Duh.
-
C++ is not a better language for being compatible with C, despite all the effort that implied, but it is a more widespread one.
QFT. Presumably one of the next C++ standards might want to consider dropping C compatibility at this point, it's now more trouble than it's worth.
-
Exceptions in constructors are especially nasty because they leave behind a half-constructed object in indeterminate state.
Ooh, didn't we have a thread about that, at some point?
-
Presumably one of the next C++ standards might want to consider dropping C compatibility at this point, it's now more trouble than it's worth.
They'll still need to be able to access C functions as foreign-function-call stuff in that case, as there's still lots of libraries (including low-level OS interfaces!) that are out there, and nobody's got the time to rewrite all that in another language just because some standards committee decided to be annoying wazzocks.
-
Python, Java, C#, Rust, Lua and probably every other real programming language can do C FFI and they have zero source code compatibility with C. Your argument is invalid.
As of old codebases, yeah, breaking stuff is bad, so unupdated stuff wouldn't be able to get new stuff - but then, you won't get most of benefits without rewriting large portions of codebase anyway.
-
Python, Java, C#, Rust, Lua and probably every other real programming language can do C FFI and they have zero source code compatibility with C.
But they have to go through some form of interop layer, which just slows things down; C++ can call C directly, so avoid this overhead
-
That isn't due to syntax level compatibility. That's because calling conventions in both languages are the same. You could change the syntax without breaking that.
-
But they have to go through some form of interop layer, which just slows things down; C++ can call C directly, so avoid this overhead
I doubt whether that's really that significant.
Interop does still mean C usually - as usually it's not the other language calling C, but C making itself be callable by the other language.
-
You still have to have that interop on the boundary, so you can convert the variable types correctly
-
But they have to go through some form of interop layer, which just slows things down; C++ can call C directly, so avoid this overhead
Bro do you even link? All compiled languages - Pascal, Haskell, Rust, D, Go, and of course C and C++, but also pure asm - can call C functions directly, without any overhead except for the stuff necessary to make any function call, but this overhead is the same for Pascal-to-C, Pascal-to-Pascal and C-to-C. With interpreted languages, there's more overhead involved usually, but that's not because FFI is costly in them but because interpreted languages are slow in general.
-
You want me to provide a link to prove you need an interop layer, then go on to agree you need an interop layer.
-
You want me to provide a link to prove you need an interop layer, then go on to agree you need an interop layer.
You need an interop layer in a managed language, because there's the language framework in the way and you're calling out of it. In a compiled language, the framework isn't in the way and you call directly. C++could change it's syntax, and that would not change how they call C functions.
-
-
You want me to provide a link to prove you need an interop layer
What? When I said link, I meant linking object files. You know, merging the compiled source files together and resolving function call addresses. I haven't asked you for any link, Internet oor otherwise.
-
OK, but I still don't see how that's relevant; outside of tiny uni projects, everything I've ever worked on (that is compiled) has always involved linking, to the extent that I think of the two as halves of a whole
-
Maybe we're on different contexts. This whole thread was necro'd by tar saying that C++ could drop C compatibility. Dkf then said that people still need to call C functions. Gaska then pointed out that languages without syntax compatibility (the compatibility tar was talking about) can call C functions. You then said that they need to go through an interop layer.
What I'm saying is that the interop layer and source compatibility are independent concepts. You can break source compatibility without then requiring an interop layer, and you could conceivably have source compatibility and still need an interop layer (imagine someone compiling C to Java bytecode).
-
then go on to agree you need an interop layer.
I don't know what you consider an interop layer, but if Pascal to C requires one, so does C to C. Because they're both using the exact same facilities to call C code!
-
I can see where this is going, and I'm not going to waste yet another evening arguing against a petulant moron
-
People knowing what they're talking about are petulant morons now? Freedom is slavery, etc.?
-
-
Maybe. But it's irrelevant now because you're trying to sell me the utter bullshit that being able to copy-paste 40-years-old code into my project and compile it with a compiler for language that didn't even exist back then, somehow makes it faster to use that code when I didn't copy-paste it but rather left it in external library where it belongs - faster compared to other natively compiled languages which can link to C all the same.
-
And now you're bringing in irrelevant crap.
Kindly sod off.
-
Yep, the way languages call C is totally irrelevant to discussion about performance of languages calling C. Not at all.
You know, those discussions would get much smoother if I didn't HAVE TO GUESS WHAT ARE YOU EVEN DISAGREEING WITH!!!
-
Learn to read
-
Learn to write.
-
Learn to bicker.
-
I don't even know what that word means.
-
It's where you break your own vertebrae so you can shove your own head up your own ass. Then you giggle because the hair tickles.
-
Well, you certainly have many interesting skills, but I'm not sure how learning this particular one would help me in this situation. Or in fact, any situation.
-
-
You then said that they need to go through an interop layer.
The situation is rather more complicated than that, as the language concerned could be compiled into a form that doesn't need the interop layer.
The C++ and C calling conventions are very similar right now, but not the same. C guarantees that its functions won't throw exceptions (since it doesn't have exceptions at all). C++ is… rather more complicated in this regard. (There's also the difference in name mangling, but that's more of a “so what? big deal” at the level we're talking about.)
-
Yes, that's why I said
@Kian said:What I'm saying is that the interop layer and source compatibility are independent concepts.
-
You want me to provide a link to prove you need an interop layer, then go on to agree you need an interop layer.
He's talking about the compiler being the "interop layer" which is possibly one way to think about a compiler, but is really misleading.
-
-
-
Apparently they don't care enough to have updated their news page in the past four years.
