| Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 14 08:13AM +0200 Am 13.04.20 um 21:35 schrieb Mike Terry: >> Press any key to close this window . . . > -1073740791 is the NTStatus for stack buffer overrun, in case this helps > anyone... Maybe a missing guard page access. This would explain why debug succeeds. Marcel |
| "Öö Tiib" <ootiib@hot.ee>: Apr 14 12:34AM -0700 On Monday, 13 April 2020 19:14:07 UTC+3, Bob Langelaan wrote: > default_random_engine engine( static_cast<unsigned int>( time(0) ) ); > uniform_int_distribution<size_t> randomInt( 1, four_billion); > Default settings in IDE other than I have selected "ISO C++ 17 Standard (for the field "C++ Language Standard"). This is required in order to use this updated version of the sort algorithm. Can't reproduce. It can be it is about something in undisclosed code or in compiler command line. Post those details too or if you already discovered what was wrong then don't be embarrassed but tell us. Happens all the time. |
| Juha Nieminen <nospam@thanks.invalid>: Apr 14 09:44AM > This code used to work in earlier version of MS VS 2019: I'm somewhat certain that Visual Studio engineers don't read this newsgroup. You should report this through the proper Microsoft channels. |
| gazelle@shell.xmission.com (Kenny McCormack): Apr 14 08:18PM In article <r740lu$irv$1@adenine.netfront.net>, >> This code used to work in earlier version of MS VS 2019: >I'm somewhat certain that Visual Studio engineers don't read this newsgroup. >You should report this through the proper Microsoft channels. Where it will go directly to /dev/null. You get more play and feedback posting to Usenet. Therefore, I support posting it here. -- Conservatives want smaller government for the same reason criminals want fewer cops. |
| Paavo Helde <eesnimi@osa.pri.ee>: Apr 15 01:07AM +0300 14.04.2020 23:18 Kenny McCormack kirjutas: > Where it will go directly to /dev/null. > You get more play and feedback posting to Usenet. > Therefore, I support posting it here. I have reported MSVC bugs to Microsoft and they got fixed (after a couple of years, but still). Not that this particular issue is bound to be a compiler bug, we have not yet seen a self-contained demo case. When I reported a bug I included a destilled demo program along with a VStudio project, plus a crashing compiled .exe. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 15 01:02AM +0200 On 14.04.2020 22:18, Kenny McCormack wrote: >> I'm somewhat certain that Visual Studio engineers don't read this newsgroup. >> You should report this through the proper Microsoft channels. > Where it will go directly to /dev/null. That's not my experience. Latest communication from them, two days ago: << Hi Alf P. Steinbach, Nina Wang [MSFT] changed the status of the following problem: "Opening empty .rc file hangs + crashes + relaunches Visual Studio" to Need More Info and added a comment. Thank you for sharing your feedback! We've according to your steps to repro the issue, but we cannot reproduce it on 16.5.3, in this case, could you please try to below steps? 1. Repair your VS via installer 2. Update to latest VS 2019 version Thanks > You get more play and feedback posting to Usenet. > Therefore, I support posting it here. Different kinds of feedback. Usenet denizens bring a lot of experience and intelligence to the table. Microsoft brings the ability to fix the compiler, which they usually do when I report something. - Alf |
| Juha Nieminen <nospam@thanks.invalid>: Apr 14 10:03AM The (new meaning of the) 'auto' keyword can be extremely useful in many situations (and in fact the language uses it to its advantage to abstract away types that the programmer doesn't need to care about, most prominently the exact type of lamdba functions). However, I have noticed that it has had a rather unintended consequence. Namely, I have noticed that beginner and mid-tier C++ programmers (and probably even some experienced programmers) are shoving it *absolutely everywhere.* For reasons that I cannot really understand. Almost anywhere where 'auto' could be used, they will use it. No longer will you see code like int i = 5; Instead, it's always auto i = 5; And what happens if the codes wants it to be something other than an int? I have seen abominations like auto i = (short)5; for reasons known only to the programmer himself. And probably not even to himself. Also things like: auto name = std::string(str); instead of, you know, std::string name(str); Recently I had to answer a beginner programmer's question why this didn't work properly: for(auto i = 0; i < vec.size(); ++i) My response? "Don't use auto." My followup response? "Don't. Use. auto." Many a bug is introduced into programs due to overuse of auto. While there are some genuine situations where it's actually desirable to write something like auto result = someFunctionSomewhere(); in general you really want to see the actual type you are expecting that function to return. (There are situations where you don't and shouldn't care about that type, but those tend to be rare.) Personally, about the only situation where I allow myself to use 'auto' merely to save writing is with iterators, like: std::map<std::string, std::string> myMap; auto iter = myMap.begin(); In most situations this is quite readable, understandable and not very error-prone. |
| Paavo Helde <eesnimi@osa.pri.ee>: Apr 14 01:32PM +0300 14.04.2020 13:03 Juha Nieminen kirjutas: > probably even some experienced programmers) are shoving it *absolutely > everywhere.* For reasons that I cannot really understand. Almost anywhere > where 'auto' could be used, they will use it. Looks like the code review step in your organization is not working properly. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 14 01:10PM +0100 On Tue, 14 Apr 2020 10:03:28 -0000 (UTC) > auto iter = myMap.begin(); > In most situations this is quite readable, understandable and not very > error-prone. Herb Sutter is partly responsible for this with his "Almost Always Auto", which I think was a mistake. (He also perpetrated a more serious piece of disinformation with his "const means thread-safe": So std::string::length() is thread-safe is it? I think not - try calling it when another thread is appending to the string.) |
| "Öö Tiib" <ootiib@hot.ee>: Apr 14 05:33AM -0700 On Tuesday, 14 April 2020 15:10:37 UTC+3, Chris Vine wrote: > piece of disinformation with his "const means thread-safe": So > std::string::length() is thread-safe is it? I think not - try calling > it when another thread is appending to the string.) After 2002 or so I have gradually stopped listening to Herb Sutter since he has become evangelist of C++/CLI and other as monstrous concepts. |
| Juha Nieminen <nospam@thanks.invalid>: Apr 14 12:35PM > piece of disinformation with his "const means thread-safe": So > std::string::length() is thread-safe is it? I think not - try calling > it when another thread is appending to the string.) Did he say "thread-safe" or "reentrant"? Because there's a difference between the two, and he probably meant the latter (even if he said the former). And not as in "const guarantees reentrancy" but "in well-designed code const *should* guarantee reentrancy". (Reentrancy simply means that two threads can call the same funtion simultaneously without any misbehavior happening. In other words, the function is "thread-safe" with itself, ie. in the context of being called from multiple threads at the same time.) This means effectively that const functions shouldn't have side-effects. Even if the function doesn't modify *this, it should still have no side-effects (such as calling std::cout, etc). |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 14 05:32PM +0100 On Tue, 14 Apr 2020 12:35:23 -0000 (UTC) > This means effectively that const functions shouldn't have > side-effects. Even if the function doesn't modify *this, it should > still have no side-effects (such as calling std::cout, etc). He deduced that "const means thread safe" in the context of const member functions, in a talk he gave at 2012 CPPCon. He observed that the requirements of §17.6.5.9 of C++11 apply to any standard library function, and in particular that §17.6.5.9/3 states that "A C++ standard library function shall not directly or indirectly modify objects accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function's non-const arguments, including this". (He also correctly observed that this rule does not apply to correctly synchronised mutable data members, which can be modified by a const this pointer - in other words by const methods.) But he then confused himself (or at least gave a confusingly idiosyncratic meaning to the expression "thread-safe") by deducing that const members functions were therefore "thread-safe". The ordinary meaning these days of applying the label "thread-safe" to a method of an object is (I suggest) that a thread can call the method without creating a data race by virtue of something that another thread is doing to the same object concurrently: or in other words, that the user does not have to provide his/her own synchronisation to prevent undefined behaviour. std::string::length() is re-entrant. It is also const. But it is not thread-safe according to the normal meaning of the expression. You have undefined behaviour if you call std::string::length() concurrently with, amongst other things, another thread appending to the string. What the extract from the standard I have mentioned does guarantee is that different threads can concurrently call const methods of a class in the standard library without external synchronisation provided that (i) that no other thread calls a non-const method of the object concerned concurrently, and (ii) that none of the const methods modifies unsynchronised static or global data. On a minor quibble about what you say, it may be true that generally const methods 'shouldn't have side effects' (in the sense of 'I wouldn't do that'), but that is not a requirement of the standard. Const methods cannot modify non-mutable non-static data members according to the standard. However they can modify static member data, and any data in namespace scope. Or put another way, 'const' doesn't mean 'pure'. |
| Daniel P <danielaparker@gmail.com>: Apr 14 10:18AM -0700 On Tuesday, April 14, 2020 at 12:33:05 PM UTC-4, Chris Vine wrote: > (i) that no other thread calls a non-const method of the object > concerned concurrently, and (ii) that none of the const methods > modifies unsynchronised static or global data. Also note that the std::function operator() const member function will do whatever your containing code does. > Const methods cannot modify non-mutable non-static data members > according to the standard. However they can modify static member data, > and any data in namespace scope. They can modify the contents of a derefernced pointer data member, class A { public: int* p; A() { p = new int [2]; } ~A() { delete p; } void foo() const { p[0] = 1; } }; > Or put another way, 'const' doesn't mean 'pure'. Indeed. Generally, C++ const means no more than "logical const", that the "logical" state of the object remains the same. Not something the compiler can use to optimize or diagnose. And of limited value for reasoning about code. Daniel |
| "Öö Tiib" <ootiib@hot.ee>: Apr 14 10:45AM -0700 On Tuesday, 14 April 2020 20:19:05 UTC+3, Daniel P wrote: > > Or put another way, 'const' doesn't mean 'pure'. The thing that in C++ is very close to meaning "pure" about function is "constexpr". In fact constexpr function is related to constant expressions only to extent what one would expect from pure functions. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Apr 14 11:04AM -0700 Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes: [...] > piece of disinformation with his "const means thread-safe": So > std::string::length() is thread-safe is it? I think not - try calling > it when another thread is appending to the string.) Another thread can't append to the string if the string is defined as "const". (I haven't read Herb Sutter's "const means thread-safe" discussion.) -- 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 */ |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 14 07:34PM +0100 On Tue, 14 Apr 2020 11:04:33 -0700 > Another thread can't append to the string if the string is defined as > "const". (I haven't read Herb Sutter's "const means thread-safe" > discussion.) Clearly (on both points). The discussion was about whether const methods are thread safe. But the point also remains about objects held by reference to const. The fact that thread 1 cannot modify an object because it only holds the object by reference to const (say by receiving it as a reference to const function argument) does not mean that thread 2 cannot access it in some other way and thus modify it. You have to look at the code to determine whether there is the potential for a data race, not at whether the method concerned is qualified as const. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Apr 14 12:32PM -0700 >> discussion.) > Clearly (on both points). The discussion was about whether const > methods are thread safe. OK. > it in some other way and thus modify it. You have to look at the code > to determine whether there is the potential for a data race, not at > whether the method concerned is qualified as const. Sure. Which is why I specifically said that the string (by which I meant an object of type std::string) is *defined* as const, not that something sees it as const. Admittedly my point was a bit trivial. -- 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 */ |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 14 11:52PM +0100 On Tue, 14 Apr 2020 12:32:56 -0700 > meant an object of type std::string) is *defined* as const, not that > something sees it as const. > Admittedly my point was a bit trivial. There is an interesting tangential point. How often in a C++ program do people create const immutable class type objects for run time (as opposed to, say, constexpr scalars for compile-time computation)? I can't say my code does it at all often, if at all. In the case of strings, if I want a literal string I tend to use a C string literal. C++ is an imperative language, not a functional language. In C++ you don't loop by iterative recursion and the passing of immutable arguments with tail call elimination, you loop with mutable local loop variables. The C++ OOP paradigm usually assumes that at some point some method is going to mutate a datum at some point in the program - that is the whole point of encapsulating data with the methods which will operate on the data. It is commonplace to pass non-const non-trivial objects to a function by reference to const on the understanding that they will not be mutated by that particular function, but I think it is quite rare in C++ to create such objects as immutable and const at the outset. |
| Nikki Locke <nikki@trumphurst.com>: Apr 14 10:23PM Available C++ Libraries FAQ URL: http://www.trumphurst.com/cpplibs/ This is a searchable list of libraries and utilities (both free and commercial) available to C++ programmers. If you know of a library which is not in the list, why not fill in the form at http://www.trumphurst.com/cpplibs/cppsub.php Maintainer: Nikki Locke - if you wish to contact me, please use the form on the website. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment