Boost::Fuck! (the git command)
-
It was also THE WEEKEND.
I have more patience for this shit when I'm procrastinating at work.
Oh sorry, for a moment I forgot that you don't get even the most obvious allusions. The point of my post above is that because you haven't addressed my counterarguments, it can be assumed you're agreeing with me that not everything should be undoable, at least until you actually address that.
-
In C#, you deal with objects and high level concepts. In C, you have to imagine them while you twiddle with bits and memory addresses.
It's more like, whether you're working in C, C#, Java, Haskell, asm, or anything else, all the high-level concepts are just your imagination, and what the program actually does is twiddle with bits. The difference is, C# compiler has as vivid imagination as you do, and C compiler can't even understand what's the difference between text and group of characters.
-
C# is the friendly drunk, C is the nasty stabby drunk.
-
I don't think that I can use
thefuck. I'm sure it doesn't help when thefuckyou're muttering is because of your git repo gone completely messed up.
-
C# is the friendly drunk, C is the nasty stabby drunk.
It's usually the friendly drunks who beg for money.
-
I'd rather try and make a friendly drunk who begs for money dance to my tune, than a nasty stabby drunk.
dance for your coppers drunk! dance! yees! I am the one who is the lord of this dance of drunkenness!
-
The point of my post above is that because you haven't addressed my counterarguments, it can be assumed you're agreeing with me that not everything should be undoable, at least until you actually address that.
Right; because if I don't say I disagree, then obviously I do agree. That's how the universe works. How perceptive of you.
Wow! I didn't realize you agreed with pedophilia! You should see some help about that Gaska. I know you agree with it because you didn't say otherwise. Whoa, you agree with the KKK also? And neo-Nazis? Jesus, man.
-
If you're done explaining why not laying out your disagreements doesn't mean you don't disagree, could you start laying out your disagreements? I'd like to see where the line is drawn on what actions are undo-able and what actions aren't.
-
Right; because if I don't say I disagree, then obviously I do agree. That's how the universe works. How perceptive of you.
In real life, when you say one thing, someone counters that, and you don't say anything more, it's commonly interpreted as that you were left speechless by counterarguments and are unable to defend your point anymore. Internets is a terrible tool for communication, so a lot of online interaction is assumptions about what's happening with the other person. In algorithmics, it's called heuristic.Wow! I didn't realize you agreed with pedophilia! You should see some help about that Gaska. I know you agree with it because you didn't say otherwise. Whoa, you agree with the KKK also? And neo-Nazis? Jesus, man.
I see you're procrastinating at work again. Pray tell, do you still think everything should be reversible, including the things I mentioned in post #19?
-
No one cares what you think of user-friendliness of C, it's used by those who know how and where to use it.
This is nonsensical. If someone is complaining, it means they used it and don't know how to do it well. You're basically saying "If you complain about C, you don't exist", which is clearly false.
And even people who know how to use C have reason to complain about it. It was designed around the limitations of the computers of the time, and it shows. C is the worst part of C++, for example.
-
Maybe, but instead, you have to worry about object lifetimes and resource usage.
Not "instead". You have to worry about that in C too. You just don't have language constructs to help you do it. Or you can go back 30 years and write structured code, as god intended.
-
This is nonsensical. If someone is complaining, it means they used it and don't know how to do it well. You're basically saying "If you complain about C, you don't exist", which is clearly false.
Well, I've made much, much more complaining at either PHP or JS than at C++ in my life, despite having 10 years of experience in C++ and literally zero in the former two.C is the worst part of C++, for example.
Nope. The worst part is template metaprogramming. Second worst part is implicit single-arg constructors. Third worst part is ecosystem. C legacy comes only at the fourth place.
-
I've made much, much more complaining at either PHP or JS than at C++ in my life, despite having 10 years of experience in C++ and literally zero in the former two.
Huh. How do you even know what to complain about?
The worst part is template metaprogramming.
Template metaprogramming is awesome. The syntax is hell, however, because it had to be grafted on to something that tried to be compatible with C's syntax. Also, people like new features to be extra verbose, without realizing that you're screwing yourself when you become used to those features and want to use them.Second worst part is implicit single-arg constructors.
They're bad, but you can make them explicit. Hardly "the second worst part of the language".Third worst part is ecosystem.
I don't think you can extricate this completely from compatibility with C. Assuming you mean the hell it is to just get someone else's library to build in a different environment, it comes down to the terrible tools, which mirror C's tools (and often are the same). Just this week I had to struggle with Freetype (a C library) because the build script got confused about my windows mingw-64 installation, and wanted to use lib instead of ar in the final step. Which are the same kind of issues I have when compiling C++ libs.Well, that and proprietary bullshit wars between compiler vendors.
-
Template metaprogramming is awesome. The syntax is hell, however, because it had to be grafted on to something that tried to be compatible with C's syntax. Also, people like new features to be extra verbose, without realizing that you're screwing yourself when you become used to those features and want to use them.
It's also murderous to compile & link times.
-
Then my answer is: fart. All of your questions answered. By fart.
-
Huh. How do you even know what to complain about?
I read a lot.Template metaprogramming is awesome.
Only in the "hey, look how they managed to exploit this SFINAE caveat to implement compile-time logical expressions evaluation allowing different interfaces and implementations of classes depending on what type you pass as argument! Much ass-backwards, so hackery!" sense.The syntax is hell, however, because it had to be grafted on to something that tried to be compatible with C's syntax
No, the syntax is hell because people write compile-time code generators using type declaration syntax only. There's no way for this to not go wrong.Also,
peoplemanagers like new features to be extra verbose
FTFYThey're bad, but you can make them explicit.
I can't make 3rd-party type constructors explicit without modifying 3rd-party code.I don't think you can extricate this completely from compatibility with C.
Yes I can. Try to link C++ program to C library. It Just Works™. Now try to link C++ program to C++ library. It works iff you compile both with same compiler.
-
Then my answer is: fart. All of your questions answered. By fart.
Fart joke. *ding* Blakey Sin Counter: 13250732065Protip: if you want to convince people undoing is a good idea, maybe you should show that it's indeed a good idea?
-
-
I don't like ultimatums. I do like posting "fart."
Fart.
-
*ding* *ding*
-
Only in the "hey, look how they managed to exploit this SFINAE caveat to implement compile-time logical expressions evaluation allowing different interfaces and implementations of classes depending on what type you pass as argument! Much ass-backwards, so hackery!" sense.
Exactly; the idea is great. Compile time reflection for better generic programming. "If this class can do this, do this. If it can't, do this worse thing". The syntax is awful, because of C legacy. And they're trying to make it better, because it is a useful feature (better const expressions to replace some kinds of metaprogramming, concepts, etc) but what holds those advancements back is the C syntax.It works iff you compile both with same compiler.
My point about that was that that's not the fault of the language. The language specifically avoided describing that part of the implementation, because they considered it would have been overreaching (whether that's the right decision is a matter of interpretation). And then every compiler vendor decided to do their own, mutually incompatible tool just to fuck with everyone else.
I try to distinguish where the language is messed up and where the implementation is messed up. I mean, there's no aspect of the language stopping you from writing a linker that could link libraries from different compilers (as far as I understand the issue).
-
Tell you what, if you want to dictate the content of my posting, you can hire me. PM me; we'll work out a reasonable rate.
Until then, fart
-
Tell you what, if you want to dictate the content of my posting, you can hire me. PM me; we'll work out a reasonable rate.
I'm toocheappoor to hire a spammer. Also, my goal isn't to dictate what you post; it's to prove you wrong, or at least make it look like I did. Which, by the way, I've accomplished in this topic.Until then, fart
*ding*
-
I have to use Git
If Git is the same as Linux, then C is the same as Unix and that means the Windows API is written in Unix.
-
Undeniably true.
-
Exactly; the idea is great. Compile time reflection for better generic programming. "If this class can do this, do this. If it can't, do this worse thing".
Agreed.The syntax is awful, because of C legacy.
No. The syntax is awful because of shitheads behind the language figured out that SFINAE makes the templates Turing-complete and they don't need anything else to be feature-complete. None of this has anything to do with C compatibility.My point about that was that that's not the fault of the language.
Yes, it's not. It's the fault of THE ECOSYSTEM. I thought I made it clear enough in my original post, by stating that the problem with C++ is THE ECOSYSTEM.The language specifically avoided describing that part of the implementation, because they considered it would have been overreaching (whether that's the right decision is a matter of interpretation).
There's nothing to interpret. Here are the facts: every compiler implements different ABI and it makes cross-linking impossible, which sucks. Ergo, it was wrong to omit it. Simple as that.I try to distinguish where the language is messed up and where the implementation is messed up.
This disctinction is nice in academia, but in real life, the language isn't worth anything without the ecosystem around it - compilers, IDEs, testing frameworks, dependency managers etc. Also, the language isn't defined by the spec, but by the compiler - you can't use a feature if the compiler doesn't support it. Which is why C++11 was overtaking so slowly.
-
If Git is the same as Linux, then C is the same as Unix and that means the Windows API is written in Unix.
And if WinAPI is written in Unix, it means it's Open Source, and therefore Windows sucks. Which is in line with empirical observations.
-
Unix wasn't open source.
-
Unix wasn't open source.
Lunix is the same as INUX, and everyone knows OSX is open source hardware.
-
Which is why Linux Is Not UniX.
The X isn't bolded in the preview. Will it be bolded in the real message? Only one way to find out. I'm leaving it there because I selected the X and clicked "Bold" in the editor and that's what Discourse did. So that X is bolded according to Discourse.
-
You have discovered the meaning of "Discourse": Discourse Doesn't Work
-
Which is why Linux Is Not UniX.
BBCode works better:Which is why Linux Is Not Uni[b]X[/b].
-
This disctinction is nice in academia, but in real life, the language isn't worth anything without the ecosystem around it - compilers, IDEs, testing frameworks, dependency managers etc. Also, the language isn't defined by the spec, but by the compiler - you can't use a feature if the compiler doesn't support it. Which is why C++11 was overtaking so slowly.
Ok, I agree. I may have lost sight of the point while arguing. I believe, however, that the ecosystem would be better if not for C legacy. I'm willing to compromise, and agree that C legacy might not be THE WORST of C++'s problems, but it's up there.
-
The ecosystem would be better if C++ was less academic and more real-life. Unspecified ABI has nothing to do with C compatibility.
Another great mistake of C++ (and also C): unspecified size of primitive types. It's a real PITA when it comes to FFI.
-
-
unspecified size of primitive types
Holy crap, this bites my team all the time. Now we start every project by refactoring primitive types into
uint8_t,uint32_t, etc.
-
Now try to link C++ program to C++ library. It works iff you compile both with same compiler.
Here are the facts: every compiler implements different ABI...
I actually don't think this is very true... from what I can tell, most compilers use the "Itanium" ABI nowadays. (This is definitely true of GCC and LLVM, and appears to be true for Intel too.) So I suspect this isn't much of a problem now except MSVC to a non-MSVC compiler. But I'll admit that I actually haven't tried this.I'm also not sure about this, but I think that standardization of the ABI may be on the way.
-
Don't forget error messages!
Actually, of my complaints about templates, error messages are a few slots down from the top. It's fairly rare that I have any trouble figuring out what they're saying or how to fix them.
-
Once the meat is minced, you cannot unmince it into living cattle anymore.
I'll just leave this here.
-
The ecosystem would be better if C++ was less academic and more real-life. Unspecified ABI has nothing to do with C compatibility.
There are many things that could improve the ecosystem. The ABI is one. And I do believe it has something to do with it, since the ABI is a result from the compilation model, and the compilation model is a result of copying the C model. For example, when you use a java library, you have the whole source for it available. There's no linking step in Java (at least, that's my understanding).
I'm not saying C++ should copy Java's model, of course. I'm just pointing out that copying C's model is part of the reason the problem exists in the first place. The way files are included, so that you recompile the same source over and over is also a consequence of following C's model. In short, a lot of problems are C's problems, inherited for C compatibility. And C's ecosystem isn't a bed of roses either. So we get their issues and pile up C++'s own.
-
I actually don't think this is very true... from what I can tell, most compilers use the "Itanium" ABI nowadays. (This is definitely true of GCC and LLVM, and appears to be true for Intel too.) So I suspect this isn't much of a problem now except MSVC to a non-MSVC compiler. But I'll admit that I actually haven't tried this.
Well, historically, it was the way I said. And nowadays, the MSVC vs. non-MSVC is a big deal in gamedev, because here, the devs are split pretty evenly between VS and GCC, with other compilers within error margin.Actually, of my complaints about templates, error messages are a few slots down from the top. It's fairly rare that I have any trouble figuring out what they're saying or how to fix them.
Have you ever used combination of C++11, Boost and GTest in a big codebase developed by team of which a significant part is design pattern maniacs?
-
Holy crap, this bites my team all the time. Now we start every project by refactoring primitive types into uint8_t, uint32_t, etc.
I'm not sure this qualifies as a problem. On the one hand, I can see the benefit of having a type that's shorthand for "I don't care about the size, just give me what's good for this arch". On the other, having types who's size you know is important in certain applications.
C++ offers both, so it's not like you need to choose. And how often can this be an issue? How does it bite you more than once?
-
-
the ABI is a result from the compilation model
No. The ABI is a result of compiler implementation alone. It has nothing to do with makefiles, headers, dynamic libraries etc.For example, when you use a java library, you have the whole source for it available.
Um, nope. You get the compiled version. The fact you can often losslessly convert it back to the original source is irrelevant, except that it implies including great amounts of metadata with your lib, but it's certainly possible with natively compiled languages too.There's no linking step in Java (at least, that's my understanding).
There is. It's not the same kind of linking as C/C++'s replacing symbolic names with addresses in memory, but there's still linking (at runtime, I think). And because Java ABI is standarized, it works flawlessly.I'm not saying C++ should copy Java's model, of course. I'm just pointing out that copying C's model is part of the reason the problem exists in the first place.
The ABI itself isn't the problem. The existence of multiple ABIs is.The way files are included, so that you recompile the same source over and over is also a consequence of following C's model.
It's almost irrelevant to ABI problem. Almost.On the one hand, I can see the benefit of having a type that's shorthand for "I don't care about the size, just give me what's good for this arch".
Yeah, the benefit is that you don't have to think while coding. The drawback is that your code works differently depending on compiler's implementation and compilation options.MACROS EVERYWHERE
Actually, macros in GTest is just a thin layer built on top of giant pile of templates. Good luck with finding the problem when the message is eight hundred lines long.
-
And how often can this be an issue? How does it bite you more than once?
Our projects all started out without portability in mind. The developers regularly asked for "just give me what's good for this arch", but then wrote code that relied upon the size. When that gets ported to a different processor, it eventually breaks in some subtle, hard to debug way.
Can't blame the language, it is what it is, it's really the fault of the developers. You have to have discipline when writing portable code, you have to know when
intis appropriate and when it isn't.
-
The fact you can often losslessly convert it back to the original source is irrelevant, except that it implies including great amounts of metadata with your lib, but it's certainly possible with natively compiled languages too.
I wouldn't say that's "irrelevant". If C++ libraries were a zip file with the whole source, and you then compiled that zip file when building the executable, you wouldn't have ABI issues either. Being able to losslessly convert back to source means being given the source.
but then wrote code that relied upon the size
What I've found helps is using static_asserts to document those assumptions. That way the code doesn't break subtly, it fails to compile and it tells you why. (static_assert(sizeof(int) == 4, "Ints are the wrong size!");) Of course, you have to realize you're making an assumption in the first place.
-
You do know that programs like rm weren't open source when they were made, right? The GNU rm you find in Linux is different than the one found on 70' Unix or in today's Solaris, HPUX, AIX, etc. So, stop confusing UNIX with OSS.
Yeah, I'd rather have GNU
rmthan the probably-brain-dead one that comes with AIX...Yeah, I was just thinking thank god I get to develop in sane languages on a sane OS and avoid all these decades old, brutally awful pitfalls @wft seems so very proud of.
The problem is someone has to take those pitfalls for you, then. Fortunately, those folks are usually specialists at it, but they too can get them wrong...Just because it's managed code, doesn't make it immune to moronicity
Yup! I've heard plenty of tales of Java leaking memory...Well, historically, it was the way I said. And nowadays, the MSVC vs. non-MSVC is a big deal in gamedev, because here, the devs are split pretty evenly between VS and GCC, with other compilers within error margin.
Yeah -- it seems that the MS ABI and the GCC (Itanium/CodeSorcery) ABIs are more-or-less the predominant ones, on the C++ side of the ball at least.
-
Have you ever used combination of C++11, Boost and GTest in a big codebase developed by team of which a significant part is design pattern maniacs?
Not all together, though I've used each of those things (maybe except "design pattern maniacs") I think in each set of pairs. (Probably not C++11 & GTest.) And the code base I'm on now has a lot of template use, although it's not very "advanced" stuff. (Explicit specializations are the most advanced thing we do a lot. I don't think we dip much into SFIANE or other stuff along that line.)I stand by what I said. But not because I think error messages aren't a problem, just because I think other things are worse. If I could speed up compilation by an order of magnitude for instance, I'd do that long before improving template error messages.
-
If I could speed up compilation by an order of magnitude for instance, I'd do that long before improving template error messages.
Surprisingly, templates aren't usually the culprit of terrible compilation times. Headers are. If you want to improve compilation times, try to limit headers as much as possible (of course, templates have to live in headers, so you're double screwed there).
-
of course, templates have to live in headers, so you're double screwed there
Ding ding ding!
One of these days I want to play around with trying to use
extern templateor something to improve things. Not sure how difficult that would be with our code base, or whether even just the parsing time would make doing just that not so helpful.The other thing that templates do is give you an easy way to create a ton of identifiers with really long names. We have a dozen or so identifiers in the main executable that I work on whose mangled names are literally more than a kilobyte.
