Visual Studio WTF
-
@Gąska said in Visual Studio WTF:
TRWTF is having different source files with same name.
WTF what an idiot I was!
-
@boomzilla said in Visual Studio WTF:
compiling to make warnings be errors.
I've worked somewhere we actually did that. Sometimes. For test firmware. The actual chip? Thousands of warnings nobody even glanced at.
The place I'm working now doesn't treat them as errors. We really can't, because the compiler spits out warnings for really trivial things (like "you're using the default compiler configuration; set this configuration option if you want to do a thing we don't want to do") that should only be informational messages. But we have done a pretty good job of understanding them, cleaning up things that could be real problems, suppressing the ones that aren't (where we can), post-processing the build log to look for unexpected warnings, and failing the build if the number of unexpected warnings exceeds a threshold that gets lowered as things get cleaned up. That threshold has dropped from somewhere between 1000–2000 down to about 40.
-
@HardwareGeek I'm pretty sure that I'm the only person on my team that has ever deleted an unused (java) import.
-
@Gąska said in Visual Studio WTF:
Status: Reading my posts from 6 years ago makes me depressed. Not because of what I was saying, but because of all the shit I had to deal with that I was happy to have forgotten.
Sometimes it's better to only view the past through rose-coloured glasses.
-
@Gąska said in Visual Studio WTF:
@Gąska said in Visual Studio WTF:
TRWTF is having different source files with same name.
WTF what an idiot I was!
I cannot see what's bad about avoiding similarly-named files if you can help it...
-
@PleegWat said in Visual Studio WTF:
@Gąska said in Visual Studio WTF:
Status: Reading my posts from 6 years ago makes me depressed. Not because of what I was saying, but because of all the shit I had to deal with that I was happy to have forgotten.
Sometimes it's better to only view the past through opaque rose-coloured glasses.
-
@dkf It's worse. It's running an Electron app behind the scenes and using WebSockets to communicate low level WPF draw calls to the host. I'm not trolling, I'm serious.
-
@TwelveBaud said in Visual Studio WTF:
It's worse.
Only marginally. If one part of the stack for that ran on the Cloud, now that would be worse!
-
-
@bobjanova said in Visual Studio WTF:
@robo2 I've not used Rider but we use IntelliJ for Java development and it's really good, so I'd expect it to be good as well. It doesn't have a free edition though and since .Net is just a hobby thing at home for me I haven't bought it to try out.
I did install VS2019 the other day but I haven't tried to do anything beyond the trivial yet.
Rider is pretty great. It's definitely my daily C# dev environment
-
Status: Happily coding in C++. Ask it to scaffold my method for me...
Spongebob Narrator: 37 minutes later...
Whelp, fuck it, I guess I'm done for the day... Cancel does nothing, and I swear I saw the "This operation is taking longer than usual" dialog window flash up for a second.
-
-
@TimeBandit said in Visual Studio WTF:
@Tsaukpaetra said in Visual Studio WTF:
fuck it
Why am I not surprised you would?
When it gives XP, why not?
Hrm, seems nobody has made a Visual Studio OC. This needs to be remedied!
-
-
-
@dkf said in Visual Studio WTF:
@Tsaukpaetra said in Visual Studio WTF:
When it gives XP, why not?
These days, it gives 10.
-
daFaq?
Build debug/x64 project, cool.
Switch to debug/x86, build: "Error: The operation could not be completed. Unspecified error"
release/x86, build: "Error: The operation could not be completed. Unspecified error"
release/x64, build: "Error: The operation could not be completed. Unspecified error"
debug/x64, build: All's cool dude!...struggle, google, fuck it:
rd /s .vsAnd life is good again.
Yeah, I've learned when VS starts doing weird
, kill that directory.
-
@TwelveBaud said in Visual Studio WTF:
@dkf It's worse. It's running an Electron app behind the scenes and using WebSockets to communicate low level WPF draw calls to the host. I'm not trolling, I'm serious.
The what?
-
@marinus said in Visual Studio WTF:
Did it actually work when you added the extra
public, or did it just compile and then crash or call the wrong function?I swear I saw it once in a debugger that there was two identically named classes (not files) in a C++ Android project, they even were in different .so-s and a method call went to the wrong one according to the debugger.
-
I hear people are using Visual Studio to write Java. Is this... true?
-
@dcon said in Visual Studio WTF:
Yeah, I've learned when VS starts doing weird , kill that directory.
Actually, just kill it every now and then on principle. Whatever VS dumps in there doesn't seem that important and takes up way to much disk space.
-
@Gribnit From 2002-2007 there was Visual J#, which was a source-compatible Java language implementation on top of the CLR. Aaaaand then it got Oracled.
I don't know about anything more recent than that, but I suspect not.
-
@TwelveBaud said in Visual Studio WTF:
I don't know about anything more recent than that, but I suspect not.
VSCode might be happier with it; I assume someone's done a language server for Java.
-
@dkf Looks like it.
-
-
-
@marczellm said in Visual Studio WTF:
@marinus said in Visual Studio WTF:
Did it actually work when you added the extra
public, or did it just compile and then crash or call the wrong function?I swear I saw it once in a debugger that there was two identically named classes (not files) in a C++ Android project, they even were in different .so-s and a method call went to the wrong one according to the debugger.
Yes, the first identically named symbol takes precedence, and (at least usually) there's no correlation of a symbol to a specific file or library. See also LD_PRELOAD which allows injecting additional libraries at the start of the symbol resolution order.
-
@PleegWat said in Visual Studio WTF:
the first identically named symbol takes precedence
Only as far as link time. After that, within a DLL (or executable; they're very similar) all internal symbols are bound (even if they're exported). Imported symbols may be overridden as you say… but not always, depending on how the binding is done and how the loading of the library is done. It's complicated. But things like memory allocators tend to be easier to override than most.
-
-
-
The newest VS update (16.9.1) unpins the Installer shortcut from the start menu. Gee, thankx. (I pinned it there so I can easily do a check-for-updates)
-
@dkf said in Visual Studio WTF:
@PleegWat said in Visual Studio WTF:
I kept my post short.
So did I.
Hard.
-
@PleegWat said in Visual Studio WTF:
@marczellm said in Visual Studio WTF:
@marinus said in Visual Studio WTF:
Did it actually work when you added the extra
public, or did it just compile and then crash or call the wrong function?I swear I saw it once in a debugger that there was two identically named classes (not files) in a C++ Android project, they even were in different .so-s and a method call went to the wrong one according to the debugger.
Yes, the first identically named symbol takes precedence, and (at least usually) there's no correlation of a symbol to a specific file or library. See also LD_PRELOAD which allows injecting additional libraries at the start of the symbol resolution order.
Depends. If it's two classes with the same name (including namespaces) but not exactly the same(1) sequence of post-preprocessor tokens in their definitions, then you proceed directly into nasal demon territory, by definition.
(1) really exactly the same. Not semantically the same, but textually:
file1.cpp defines
class Fred { private: int m_thing; };file2.cpp defines
class Fred { int m_thing; };Semantically, they are identical.
m_thingis private because private is by-default. Textually they are different because of that (redundant) keyword, so it's UB.
-
@Steve_The_Cynic while technically UB, it's not your usual, sky-is-falling, anything-can-happen, time-travelling UB. If you have two semantically different classes, the compiler will semi-randomly pick bits and pieces from both and the result is ungodly mess that cannot possibly work. With textually different but semantically identical classes, the compiler will also pick bits and pieces from both, but because all pieces are equivalent, nothing will ever happen.
-
@Gąska said in Visual Studio WTF:
@Steve_The_Cynic while technically UB, it's not your usual, sky-is-falling, anything-can-happen, time-travelling UB. If you have two semantically different classes, the compiler will semi-randomly pick bits and pieces from both and the result is ungodly mess that cannot possibly work. With textually different but semantically identical classes, the compiler will also pick bits and pieces from both, but because all pieces are equivalent, nothing will ever happen.
Pedantry: it's UB, which is an all-or-nothing kind of thing(1), so you don't know that. If both of them contain the implementations in the .cpp, then maybe it will blow up at link time, which would mean that nothing will go wrong at runtime because it won't link and therefore can't be run.
(1) Once there is even a hint of UB somewhere in the program, all bets are off for the entire program.
-
@Steve_The_Cynic said in Visual Studio WTF:
Textually they are different because of that (redundant) keyword, so it's UB.
Who the fuck ordered that? What were they smoking? Can we pass their home address to a certain forum member for a special home visit sometime in the future?
-
@Steve_The_Cynic said in Visual Studio WTF:
@Gąska said in Visual Studio WTF:
@Steve_The_Cynic while technically UB, it's not your usual, sky-is-falling, anything-can-happen, time-travelling UB. If you have two semantically different classes, the compiler will semi-randomly pick bits and pieces from both and the result is ungodly mess that cannot possibly work. With textually different but semantically identical classes, the compiler will also pick bits and pieces from both, but because all pieces are equivalent, nothing will ever happen.
Pedantry: it's UB, which is an all-or-nothing kind of thing(1), so you don't know that.
Gotta love when pedants don't even bother to read the post they're replying to. It literally starts with "while technically UB..."
If both of them contain the implementations in the .cpp, then maybe it will blow up at link time
It won't because linking doesn't work that way. If two classes are semantically identical, they get decorated in the same way so both versions look up the same symbols, and duplicate symbols at link time aren't a hard error. You may sometimes get a warning but that's it.
(1) Once there is even a hint of UB somewhere in the program, all bets are off for the entire program.
No compiler has
if (UB) { doStupidRandomShit(); }in its code. The "bets are off" only metaphorically; in practice, every UB has a very specific impact on the program, and by tracing down the compiler's behavior with a specific input and specific compilation options, you can determine with absolute certainty what exactly will happen. When you do a bad downcast and call a virtual method through a bottom-most class's pointer, after enabling optimizations it will get inlined 100% of the time and you get the wrong behavior 100% of the time. There's nothing random, nothing unpredictable, nothing to bet on. This compiler with these options will do this specific thing every time you ask it to.In theory you're right, but I was very specifically talking about practice, not theory.
-
@Steve_The_Cynic said in Visual Studio WTF:
@PleegWat said in Visual Studio WTF:
Yes, the first identically named symbol takes precedence, and (at least usually) there's no correlation of a symbol to a specific file or library. See also LD_PRELOAD which allows injecting additional libraries at the start of the symbol resolution order.
Depends. If it's two classes with the same name (including namespaces) but not exactly the same(1) sequence of post-preprocessor tokens in their definitions, then you proceed directly into nasal demon territory, by definition.
I keep forgetting that this is a whole lot more shenaniganny in C++ than in C, and all my experience is in C.
Of course, in C also, if a symbol expects a
struct fooargument and you give it astruct foowith an entirely different definition then weird things will happen. But you may be able to predict the weirdness because struct definition maps to memory layout pretty consistently, which I believe is not the case for C++ classes.
-
@PleegWat said in Visual Studio WTF:
which I believe is not the case for C++ classes
That depends on whether any method in that class's inheritance hierarchy is
virtual. If the answer's “no”, the C rules are still in play (modulo needing to linearize the field order, which is probably trivial for the cases you can avoidvirtualin).
-
@Gąska said in Visual Studio WTF:
@Steve_The_Cynic said in Visual Studio WTF:
@Gąska said in Visual Studio WTF:
@Steve_The_Cynic while technically UB, it's not your usual, sky-is-falling, anything-can-happen, time-travelling UB. If you have two semantically different classes, the compiler will semi-randomly pick bits and pieces from both and the result is ungodly mess that cannot possibly work. With textually different but semantically identical classes, the compiler will also pick bits and pieces from both, but because all pieces are equivalent, nothing will ever happen.
Pedantry: it's UB, which is an all-or-nothing kind of thing(1), so you don't know that.
Gotta love when pedants don't even bother to read the post they're replying to. It literally starts with "while technically UB..."
UB is all-or-nothing. A specific thing is either UB or defined. There's no "technically UB". Ever.
If both of them contain the implementations in the .cpp, then maybe it will blow up at link time
It won't because linking doesn't work that way. If two classes are semantically identical, they get decorated in the same way so both versions look up the same symbols, and duplicate symbols at link time aren't a hard error. You may sometimes get a warning but that's it.
Really? Are you totally sure that the linker will treat the two classes absolutely the same? Once it's UB, you don't and cannot know what will happen, except by experimenting with ===> that combination of compiler version, command line flags, blah blah blah.
Relevant case: in a company I worked for from 2004 to 2009 (roughly), there were guys with no fear of UB, and they got bitten hard when the UB of passing C++ objects by value to varargs ("...") functions changed in an updated version of the compiler. (The old version passed them by address instead of by value, and the new version passed them by value. Since it was a grotesque hack that coincidentally allowed the "string as fixed-size array" objects to be printed with printf() types, everything blew up bigtime.)
(1) Once there is even a hint of UB somewhere in the program, all bets are off for the entire program.
No compiler has
if (UB) { doStupidRandomShit(); }in its code.Correct, but you should treat instances of UB that you find as if the compiler has exactly that line of code, because real practice (compilers get upgraded, command line options have to be changed, code gets ported to different architectures, etc.) says that the stupid arbitrary shit the compiler does anyway will change at the slightest provocation. In essence they don't have "if (UB) carefullyAndAccuratelyWorkOutWhatTheProgrammerReallyMeant();" either. DWIM interpreters are not a thing, and they should not be.
The "bets are off" only metaphorically; in practice, every UB has a very specific impact on the program, and by tracing down the compiler's behavior with a specific input and specific compilation options, you can determine with absolute certainty what exactly will happen.
Yes, you can do that. In general, it isn't worth the effort, because almost any disturbance of the environment will change that behaviour. What compilers probably should do if they can detect UB (sometimes you can, as in the example of printf()ing objects by value) is fail the compile with an error. Oh, and your investigation has to specify exactly which version of the compiler, standard library, operating system, target architecture, etc. etc. etc. you have.
Because it's UB and all bets are off.
In theory you're right, but I was very specifically talking about practice, not theory.
And the things I've seen in practice say that you're wrong about practice as well as about theory. Code that appears to work just fine on all the different compilers the company uses, except the one I have to use for my specific project, code that changes its behaviour when the compiler is upgraded, stuff like that.
-
@dkf said in Visual Studio WTF:
@PleegWat said in Visual Studio WTF:
which I believe is not the case for C++ classes
That depends on whether any method in that class's inheritance hierarchy is
virtual. If the answer's “no”, the C rules are still in play (modulo needing to linearize the field order, which is probably trivial for the cases you can avoidvirtualin).You also have to exclude virtual inheritance and multiple inheritance. Well, even single inheritance can be a problem because you don't know whether the base class elements are before or after the derived class elements, and I'm not enough of a standards nerd to want to rely on the compiler not re-ordering the fields of a no-inheritance class so that, e.g. private members come first, then protected members, then public members.
Oh, and no member variables that fail these conditions.
But if it's a no-inheritance class defined using
structand having no virtual anything and no "unknowable" member variables and no public/private/protected keywords, then yes, it will be like C.
-
@Steve_The_Cynic said in Visual Studio WTF:
@Gąska said in Visual Studio WTF:
@Steve_The_Cynic said in Visual Studio WTF:
@Gąska said in Visual Studio WTF:
@Steve_The_Cynic while technically UB, it's not your usual, sky-is-falling, anything-can-happen, time-travelling UB. If you have two semantically different classes, the compiler will semi-randomly pick bits and pieces from both and the result is ungodly mess that cannot possibly work. With textually different but semantically identical classes, the compiler will also pick bits and pieces from both, but because all pieces are equivalent, nothing will ever happen.
Pedantry: it's UB, which is an all-or-nothing kind of thing(1), so you don't know that.
Gotta love when pedants don't even bother to read the post they're replying to. It literally starts with "while technically UB..."
UB is all-or-nothing. A specific thing is either UB or defined. There's no "technically UB". Ever.
And yet, some UBs will corrupt your data, and some won't. Compilers aren't some kind of black magic, they're just a series of instructions like every other program.
If both of them contain the implementations in the .cpp, then maybe it will blow up at link time
It won't because linking doesn't work that way. If two classes are semantically identical, they get decorated in the same way so both versions look up the same symbols, and duplicate symbols at link time aren't a hard error. You may sometimes get a warning but that's it.
Really? Are you totally sure that the linker will treat the two classes absolutely the same?
The linker doesn't even know about classes. All it sees is symbol references to fill in and symbol declarations to fill references with. I did a lot of wonky stuff with linkers, and I know what they're capable of and what they aren't. And they very definitely aren't capable of conjuring garbled code out of thin air because of some mistake at the source parsing stage. The linker only works with what the compiler gave it, and the compiler will never give it detailed knowledge of class definitions, let alone source text.
Once it's UB, you don't and cannot know what will happen, except by experimenting with ===> that combination of compiler version, command line flags, blah blah blah.
Relevant case: in a company I worked for from 2004 to 2009 (roughly), there were guys with no fear of UB
That guy is an idiot. Also that story is completely irrelevant.
I have no idea what you think I'm saying, but it's certainly different from what I'm actually saying. I'm talking about one very specific scenario (like VEEEERY specific) where this one case of UB has zero chance to cause problems because there's nothing to even mess up to start with.
In every other UB, yes, all bets are off and the program can essentially be treated as random number generator. But in the VERY SPECIFIC CASE of a redundant access modifier that's present in some compilation units - there is just no interpretation of events under which a non-malicious compiler could possibly generate wrong code.
And the things I've seen in practice say that you're wrong about practice as well as about theory.
Have you seen LITERALLY THIS ONE SPECIFIC CASE that I'm talking about? Because if you haven't seen LITERALLY THIS ONE SPECIFIC CASE, then no, you haven't seen anything that disproves anything I say. Because I'm talking about LITERALLY THIS ONE SPECIFIC CASE.
-
@Steve_The_Cynic said in Visual Studio WTF:
Relevant case: in a company I worked for from 2004 to 2009 (roughly), there were guys with no fear of UB, and they got bitten hard when the UB of passing C++ objects by value to varargs ("...") functions changed in an updated version of the compiler. (The old version passed them by address instead of by value, and the new version passed them by value. Since it was a grotesque hack that coincidentally allowed the "string as fixed-size array" objects to be printed with printf() types, everything blew up bigtime.)
This reminds me, somewhere in my codebase there's a function which passes the same
va_listtovsnprintfmultiple times without resetting it inbetween. I didn't write it, it's a timebomb, I know it's a timebomb, but I don't know of a better solution let alone being able to spend time on implementing it.
-
@PleegWat C++11 or above? The solution is likely variadic templates. C++03 or below? The solution is upgrading to newer C++.
-
@Gąska said in Visual Studio WTF:
@PleegWat C++11 or above? The solution is likely variadic templates. C++03 or below? The solution is upgrading to newer C++.
Given that earlier in the thread he said
@PleegWat I keep forgetting that this is a whole lot more shenaniganny in C++ than in C, and all my experience is in C.
It seems like your solution doesn't exactly match the environment he's in...
And if you're moving away from C, why not pick a saner language while at it?
-
@Gąska said in Visual Studio WTF:
@PleegWat C++11 or above? The solution is likely variadic templates. C++03 or below? The solution is upgrading to newer C++.
Standard C.
@robo2 said in Visual Studio WTF:
And if you're moving away from C, why not pick a saner language while at it?
I'm pretty sure I'm already in a saner language than C++.
-
@Gąska said in Visual Studio WTF:
And yet, some UBs will corrupt your data, and some won't. Compilers aren't some kind of black magic, they're just a series of instructions like every other program.
When you said that some won't, you forgot to add "this time, on this version of the compiler with these options set and these options not set, compiling against that version of the libraries and blah blah blah".
That guy is an idiot. Also that story is completely irrelevant.
They (it wasn't just one guy) were, indeed, idiots. The relevance of the story is not its details but the fact that a simple upgrade for the compiler (from a version that was five majors old to a version that was "only" three majors old) broke their UB code.
Have you seen LITERALLY THIS ONE SPECIFIC CASE that I'm talking about? Because if you haven't seen LITERALLY THIS ONE SPECIFIC CASE, then no, you haven't seen anything that disproves anything I say. Because I'm talking about LITERALLY THIS ONE SPECIFIC CASE.
OK, so let's go back to the specific case. The two classes have a semantically-equivalent but textually-different definition, but their member functions are defined in some .cpp files rather than in the headers that I, as a user of those classes, will #include. When I call a member function on the object, which version of the member function will the linker give me? The two .cpp files both define
void Fred::some_function(some_parameters);and I cannot predict which version of that function will be called. That's why it matters.UB is UB, and there's no "only a little bit UB", nor "unimportant UB". Once a piece of code is UB, you cannot predict its behaviour. You can determine it by trying it to see what happens, and that tells you something about that case, something that could change if you change anything about the compilation environment. The other one I hinted at was a "reading a variable in an expression that modifies the variable, but the read wasn't part of calculating the modification and there wasn't a sequence point in the way" type of UB(1), and it worked how a naïve assessment would think it worked on all compilers the company used except the one I had to port it to.
(1)
*pointer++ = arithmetic on *pointer, for which there isn't (er, wasn't in C89/90) a sequence point between the two uses ofpointer. Later standards might have added a sequence point at the assignment operator, but I wouldn't want to rely on that. On that one compiler, the ++ happened before the right-hand side readpointerto recover the value to use, and the assignment used the before-the-increment value.
-
@Steve_The_Cynic said in Visual Studio WTF:
Have you seen LITERALLY THIS ONE SPECIFIC CASE that I'm talking about? Because if you haven't seen LITERALLY THIS ONE SPECIFIC CASE, then no, you haven't seen anything that disproves anything I say. Because I'm talking about LITERALLY THIS ONE SPECIFIC CASE.
OK, so let's go back to the specific case. The two classes have a semantically-equivalent but textually-different definition, but their member functions are defined in some .cpp files rather than in the headers that I, as a user of those classes, will #include. When I call a member function on the object, which version of the member function will the linker give me? The two .cpp files both define
void Fred::some_function(some_parameters);and I cannot predict which version of that function will be called. That's why it matters.The classes are semantically identical, so it doesn't matter which of the functions gets picked every time - the result will always be the same. Now, if the two methods had different code (ie. the classes DID differ semantically), it would be different.
UB is UB, and there's no "only a little bit UB", nor "unimportant UB".
But there is "the reason this particular UB results in this particular behavior". And you haven't yet established any reason why a compiler, when encountering two SEMANTICALLY IDENTICAL IN LITERALLY EVERY WAY, AND I MEAN EVERY WAY classes, would produce code that behaves differently from when there's one class.
(Also I thought we're talking about a case where just the class definition is duplicated, not a case where we have two .cpp files duplicating the method implementations too. But even then, it will be just fine unless you have static member variables defined outside class body.)
Once a piece of code is UB, you cannot predict its behaviour.
Sure you can. See the Raymond Chen's blog post I linked above. It's just that in large codebases, it becomes infeasible to keep track of it all, and as you pointed out, changing the compiler or even just compilation options - or even adding new code - can drastically change everything.
Out of the millions possible UB cases, you just happened to pick the one and only* UB case that doesn't result in catastrophic failure. If you picked any other UB, everything you said would be completely true. But you picked the only one out of millions and millions possible UBs where it's not.
-
@PleegWat said in Visual Studio WTF:
@Gąska said in Visual Studio WTF:
@PleegWat C++11 or above? The solution is likely variadic templates. C++03 or below? The solution is upgrading to newer C++.
Standard C.
Oh right. Derp.
-
@Gąska said in Visual Studio WTF:
And you haven't yet established any reason why a compiler, when encountering two SEMANTICALLY IDENTICAL IN LITERALLY EVERY WAY, AND I MEAN EVERY WAY classes, would produce code that behaves differently from when there's one class.
Because @Steve_The_Cynic is using a C++ compiler that's written to be as fuckwaddedly asinine as possible in its interpretation of the standard. If it can find a way to interpret things differently in some circumstances to others, it does exactly that. In particular, it likes to change the order of things (if it is at all legal to do so) based on a hash of the userid of the account running the compiler. Because there's nothing in the standard to say it can't.
