- Why does this work in MSVC 2019... - 9 Updates
- Niuce C++14-feature - 10 Updates
- I/O-benchmark - 6 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: May 19 01:42AM +0200 >> Totally brain-damaged. > :^) > I was just wondering why MSVC allows this to run in the first place. Why not ? It's not uncompilable code. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 18 04:48PM -0700 On 5/18/2021 4:42 PM, Bonita Montero wrote: >> :^) >> I was just wondering why MSVC allows this to run in the first place. > Why not ? It's not uncompilable code. Well, warnings aside for a moment, it seems to compile, _and_ run on MSVC, however it will not even run on GCC without a segfault. Plus, the code has a bug. I get warnings in MSVC, but it still runs it to completion. I was just wondering why. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 18 05:43PM -0700 On 5/18/2021 3:05 PM, Chris M. Thomasson wrote: > added in the const keyword in vain. Its been a while since I used the > STL. Take mercy on my soul! > ;^o Actually, the last "hardcore" C++ I worked with was ScopeGuard. |
| "Öö Tiib" <ootiib@hot.ee>: May 18 05:55PM -0700 On Wednesday, 19 May 2021 at 02:49:13 UTC+3, Chris M. Thomasson wrote: > MSVC, however it will not even run on GCC without a segfault. Plus, the > code has a bug. I get warnings in MSVC, but it still runs it to > completion. I was just wondering why. The segfault indicates that gcc allows it to run as well unless you mean that the compiler segfaults (that i've not seen gcc to do for ages). MSVC did allow to take lvalue references to non const of temporaries (that should not compile) for quite long time. I have not checked if it has stopped it finally ... that may have something to do with different outcome of undefined behavior. Undefined behavior is what it is ... different nasal demons or lack of such from repeated runs of same compiled binary with same data are rare but possible with MSVC and gcc alike. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 18 08:06PM -0700 On 5/18/2021 5:55 PM, Öö Tiib wrote: >> completion. I was just wondering why. > The segfault indicates that gcc allows it to run as well unless you mean > that the compiler segfaults (that i've not seen gcc to do for ages). Yes, GCC allows it to run with warnings, and segfaults, and does not allow the bugged program to run to completion. > should not compile) for quite long time. I have not checked if it has > stopped it finally ... that may have something to do with different outcome > of undefined behavior. MSVC allows that now. It compiles the bugged code, spits out a couple of warnings, and lets the compiled program run to completion. Strange. > Undefined behavior is what it is ... different nasal demons or lack > of such from repeated runs of same compiled binary with same > data are rare but possible with MSVC and gcc alike. Big time. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 19 07:02AM +0200 > Well, warnings aside for a moment, it seems to compile, _and_ run > on MSVC, however it will not even run on GCC without a segfault. It's implementation-defined how long the memory of the temporary is untouched. |
| Christian Gollwitzer <auriocus@gmx.de>: May 19 07:57AM +0200 Am 19.05.21 um 00:09 schrieb Chris M. Thomasson: >>> set_t::iterator const& search_id(unsigned long id) const >> Well UB is UB. That includes that things may appear to work. > Indeed. Mike Terry mentioned something about a stack issue. You are basically accessing memory that was "freed"[*] before. That is totally undefined, of course, but there is no guarantee that it segfaults. The CPU can not check every small allocation on the stack or heap for correctness. Instead, the memory is structured into pages of typically 4kB in size. The CPU only checks that the page was allocated for the current process, so as long as there is any other valid object in this page, there is no segfault. This also explains why programs with memory errors often crash in a totally different location. If a pointer gets mangled, then it segfaults at the point where the pointer is used and suddenly points into the woods. You can use a memory debugger to detect these problems, like valgrind on Linux (one of the best) or the flag -fsanitize=address with clang. Then, every object is allocated on its own page, making the program very bloated and slow, but the program will then segfault immediately at the point where the deleted object is accessed. [*] not on the heap, so not "malloc/free-type freed", but "stack-freed" Best regards, Christian |
| Paavo Helde <myfirstname@osa.pri.ee>: May 19 09:50AM +0300 19.05.2021 06:06 Chris M. Thomasson kirjutas: >> that the compiler segfaults (that i've not seen gcc to do for ages). > Yes, GCC allows it to run with warnings, and segfaults, and does not > allow the bugged program to run to completion. It's not GCC, but the hardware+OS which kills the running program. You can compile the program with GCC for a platform without memory protection (like 8086) and it will never segfault (because there are neither segments nor faults). It might do other funny things though. > MSVC allows that now. It compiles the bugged code, spits out a couple of > warnings, and lets the compiled program run to completion. Strange. This is normal for undefined behavior. Anything would be normal. OTOH, it's not normal for a programmer to ignore compiler warnings about returning references to temporaries. You might want to use the "Treat Specific Errors as Warnings" compiler feature for this warning (/we"4172" with MSVC). The only reason this is a warning and not an error is because UB formally only appears when dereferencing the invalid pointer/reference, returning it from a function is actually fine. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 19 12:45AM -0700 On 5/18/2021 11:50 PM, Paavo Helde wrote: > The only reason this is a warning and not an error is because UB > formally only appears when dereferencing the invalid pointer/reference, > returning it from a function is actually fine. 100% agreed! I saw the warnings, but was interested into why the program was allowed to run to completion under MSVC. Then I tried it GCC, different things occurred. Its the nature of the beast wrt UB. I thank you and everybody else for their time and patience. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: May 18 04:56PM -0700 > seriously. You want to hide all of my posts from your view because I threw > insults at someone in one single random thread? Why? What exactly do you > gain from this? What I gain is not seeing any more of your posts, with a resulting improvement in the signal-to-noise ratio of my view of the newsgroup. Another possible gain is that I let you know that your behavior is unacceptable. Repeatedly insulting a troll just adds useless noise. The cost, of course, is that I won't see any useful articles that you post. That's a price I'm willing to pay. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: May 18 04:57PM -0700 >> just because I criticised an aspect of C++ and now you're whining because >> someone got sick of your potty mouth? Pathetic. > Just fuck off, asshole. As an asshole, you can't spout anything but shit. As promised, PLONK. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Juha Nieminen <nospam@thanks.invalid>: May 19 04:53AM >>> someone got sick of your potty mouth? Pathetic. >> Just fuck off, asshole. As an asshole, you can't spout anything but shit. > As promised, PLONK. Yeah, seriously, I honestly cannot understand why. What is it to be gained from it? Usenet is almost dead already, so adding people to a killfile is only making it deader. |
| Juha Nieminen <nospam@thanks.invalid>: May 19 05:02AM > What I gain is not seeing any more of your posts, with a resulting > improvement in the signal-to-noise ratio of my view of the newsgroup. Of an almost dead newsgroup at that. > Another possible gain is that I let you know that your behavior is > unacceptable. Repeatedly insulting a troll just adds useless noise. Repeatedly insulting an asshole is not going to take a severe amount of seconds of your busy life. You can simply ignore those messages. I think calling an asshole an asshole is worth the effort. It makes him waste time responding to those insults. Trolling trolls back is wasting the troll's time. On that note, I honestly could not care less what you personally find "unacceptable" on usenet. Usenet is a cesspool anyway, and has always been. There is no moderation, and that's probably one of the reasons why it's almost dead and the vast majority of companies and service providers have dropped support. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 18 10:05PM -0700 On 5/18/2021 10:02 PM, Juha Nieminen wrote: > I think calling an asshole an asshole is worth the effort. It makes > him waste time responding to those insults. Trolling trolls back is > wasting the troll's time. Well, feeding any troll with anything negative just might make it feel stronger? Think of a troll as a prototype for the proverbial Cruel Puppet: https://www.thezorklibrary.com/history/cruel_puppet.html Fair enough? |
| Spud@nowheresville.org: May 19 07:19AM On Tue, 18 May 2021 16:56:42 -0700 >Another possible gain is that I let you know that your behavior is >unacceptable. Repeatedly insulting a troll just adds useless noise. I'm curious as to why you think someone criticising an aspect of C++ is trolling. If this forum is merely to praise how wonderful the language is to its acolytes then what purpose does it serve? |
| MrSpook_0by_disXi@2hd58e950gxh.eu: May 19 07:22AM On Tue, 18 May 2021 17:57:34 +0200 >> of older versions of the solaris compiler back in 00s. >The numer isn't parsed as a number, but just a "= 0"-token, >so you're lying. Why would I lie about something like that? It caused the compiler to crash, thats a fact. If you don't want to believe it thats your problem, not mine. |
| MrSpook_fDx9@a3i3cdf7_.info: May 19 07:27AM On Tue, 18 May 2021 17:56:02 +0200 >> extension like >> virtual LRESULT OnPaint(...) = WM_PAINT; >Who programs Win32 directly today ? Presumably the people who write the high level libraries you use. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 19 09:41AM +0200 >> The numer isn't parsed as a number, but just a "= 0"-token, >> so you're lying. > Why would I lie about something like that? ... Because we all know you're an asshole. > It caused the compiler to crash, thats a fact. No, you don't. It can be excluded that the 0 is parsed as a number and not as a token of the grammar. You're simply a liar. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 19 09:41AM +0200 >> Who programs Win32 directly today ? > Presumably the people who write the high level libraries you use. That's 30 years ago when people programmed USER32.DLL directly. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 19 01:50AM +0200 I've got some code which isn't plain C++ but Windows- / Posix-code. I just wanted to compare the efficiencies of read() or ReadFile by reading from the filesystem-cache with increasing blocksizes. Thereby I noticed a hughe difference in the cose of a kernel-call for reading small block-sizes. So here's the code: #if defined(_MSC_VER) #include <Windows.h> #elif defined(__unix__) #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment