- vector<>::erase-behaviour - 17 Updates
- an alternative to finally - 2 Updates
- SFINAE question - 3 Updates
- something like "decltype(...) xxx" - 2 Updates
- Project symbiosis - 1 Update
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 08 01:33AM +0100 > an academic topic because they would require knowing the sizes of at > least some dimensions at compile time. This happens pretty rarely in > RL, maybe in some specific applications. Since this is comp.lang.c++, you are right, but multi-dimensional C arrays in C need not have dimensions known at compile-time. Even when variable length arrays are not used, C99's variably modified array types can be used to simplify multi-dimensional array handling. <cut> -- Ben. |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 08 07:34AM +0300 On 8.04.2019 3:33, Ben Bacarisse wrote: > arrays in C need not have dimensions known at compile-time. Even when > variable length arrays are not used, C99's variably modified array types > can be used to simplify multi-dimensional array handling. And in C++ it is pretty easy e.g. to wrap a 1D array/vector into a class providing element access via a T& operator()(size_t x, size_t y), if the goal is to simplify multi-dimensional array handling. This approach would share the same drawback with multi-dimensional C arrays in that the index calculation formally happens at each element access and care must be taken to write algorithms in such a way that the compiler would be able to optimize it away. In our code we have decided to leave the index calculation explicit in the algorithms to see the memory access pattern better, and to be able to bring parts of the index calculation out of the loop where possible, for helping the optimizer. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 08 08:14AM -0400 On 4/5/19 10:33 PM, Alf P. Steinbach wrote: >> incorrectly assumed that "gcc folk" didn't exist yet at the relevant >> time. > Yes, his argument totally lacked any logic. Incorrect - the logic of his argument was perfectly valid. The only problem was that one of his premises was incorrect. And it wasn't sufficiently incorrect to completely invalidate the conclusion. If you replace the premise with "gcc was quite young at the time the decision was made", then all you have to do is modify the conclusion slightly - instead of "it's impossible for gcc to have influenced the decision", say instead that "it's improbable that gcc significantly influenced the decision". The weakened conclusion is still strong enough to justify presenting it. >> did) read those words at some later time and form an interpretation of >> them is completely irrelevant to the point he was making. > Right again, it was a fallacious argument, one with no inner logic. In a logical argument, you have premises which are assumed correct, a conclusion that you're trying to prove, and an argument which is supposed to connect those premises to that conclusion. A fallacious argument is one where the logic of that connection is invalid. An argument where the connection is logically valid, but one or more premises is incorrect, is not fallacious, it's merely wrong, and that's the case with this argument. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 08 08:27AM -0400 On 4/6/19 9:44 AM, Alf P. Steinbach wrote: > standard, and when optimization (essentially through assuming > non-aliased pointer results of expressions) was mentioned as a rationale > for the UB interpretation, ... I mentioned the optimization for the sole purpose of pointing out that the fact that such code has undefined behavior is not just a pedantic quibble - there are plausible mechanisms by which such code could produce unexpected results. I have repeatedly tried, and apparently failed, to make it clear to you that I never said anything to suggest that such optimizations were the motivation for this rule. I'm not even sure whether any real-world compiler actually performs such optimizations. As far as I know, the rule was motivated solely by the belief that accessing an array outside it's declared length is an inherently illogical thing to do, which the C standard should discourage in the only way that it can - by specifying that the behavior of such code is undefined. You apparently disagree with that belief, which might explain why you resist so strongly the idea that it was in fact the motivation for this rule. But that belief does exist, and a majority of the C committee apparently shares that belief - not only did they approve the wording that says so, they also approved the DR that clarified that this is in fact what that wording means. > mindset of compiler developers who want to make their task somewhat > easier, with less analysis necessary to do optimization, at the cost of > carving out UB traps all over the place for language users to fall into. The mindset behind this rule, as we keep trying to explain to you, had nothing to do with the optimization, and everything to do with believing that such code is inherently illogical. The rule merely enables such optimizations; enabling them was not the purpose of creating the rule. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 08 02:42PM +0200 On 08.04.2019 14:14, James Kuyper wrote: > argument where the connection is logically valid, but one or more > premises is incorrect, is not fallacious, it's merely wrong, and that's > the case with this argument. Out of context, say as the start of a new thread, it could have been merely wrong, as an argument merely about the standard's wording. It was however posted in the context of discussing interpretations of that wording. With the implication that it was relevant to that discussion. As such it was a fallacy. /And/ wrong. Cheers & hth., - Alf |
| jameskuyper@alumni.caltech.edu: Apr 08 06:51AM -0700 On Monday, April 8, 2019 at 8:42:19 AM UTC-4, Alf P. Steinbach wrote: > On 08.04.2019 14:14, James Kuyper wrote: ... > > the case with this argument. > Out of context, say as the start of a new thread, it could have been > merely wrong, as an argument merely about the standard's wording. It wasn't an argument about the standard's wording at all, which may be the problem you're having with the argument. It's about influence, specifically the influence that gcc might have had on the committee's decisions about the wording. > It was however posted in the context of discussing interpretations of > that wording. With the implication that it was relevant to that > discussion. As such it was a fallacy. /And/ wrong. The only thing that can make an argument fallacious is a violation of the rules of logic - context can never turn a logically valid argument into an invalid one. A valid argument might not be applicable in a given context, but it remains valid, even in such a context. The only thing wrong with his argument was that it had a false premise; the logic itself was perfectly valid. If it's premise had been correct, his argument would have been entirely relevant. And since his premise was only slightly incorrect, the weaker, corrected version of his argument remains entirely relevant. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 08 03:57PM +0200 > the problem you're having with the argument. It's about influence, > specifically the influence that gcc might have had on the committee's > decisions about the wording. Well, let's formulate it that way, about not the wording itself but about the influence on the committees decisions that led to the wording. Which is what I meant. That means that it's a fallacy, in context. We're not children. We are able to reason about context and what an argument is meant to support. If it doesn't support anything then it's just nonsense, so one can choose: nonsense, or fallacy. Cheers!, - Alf |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 08 04:09PM +0200 > The only thing that can make an argument fallacious is a violation of > the rules of logic - context can never turn a logically valid argument > into an invalid one. I don't think so, for example because this very response is a counter-example. Cheers!, - Alf |
| jameskuyper@alumni.caltech.edu: Apr 08 07:33AM -0700 On Monday, April 8, 2019 at 9:57:37 AM UTC-4, Alf P. Steinbach wrote: > On 08.04.2019 15:51, jameskuyper@alumni.caltech.edu wrote: ... > > decisions about the wording. > Well, let's formulate it that way, about not the wording itself but > about the influence on the committees decisions that led to the wording. Does that sentence accurately reflect what you were claiming? You weren't clear about which decision you were accusing gcc of influencing, but I'd been assuming that you were talking about the committee's decision on the DR, not their decision on the writing of the wording itself. There's three reasons I made that assumption: 1. Your comments that this is an issue about the interpretation of the words, implying that you were under the misapprehension that the other interpretation was also consistent with the words. 2. Your comments, nonsensical in context, about whether the gcc developers could have been able to read the words of the first standard, which was never actually relevant to what he was talking about. 3. It's marginally more plausible that gcc might have significantly influenced the later decision, because they would have had 3 more years to accumulate enough influence to do so. > Which is what I meant. You meant to claim that gcc influenced the committee's decision. If his premise had been correct, presenting his argument would have proved you were incorrect on that point. Because his premise was inaccurate, the corrected version of his argument still served to point out that your claim was implausible. ... > We are able to reason about context and what an argument is meant to > support. His argument was meant to support the idea that your claim of gcc influence did not make sense. The corrected version of his argument still supports that claim, though slightly less strongly. > If it doesn't support anything then it's just nonsense, so one can > choose: nonsense, or fallacy. Perfectly sensable logically valid arguments can fail to support anything relevant to the context in which they occur, so if it didn't support anything, that would not, in itself, justify labeling it as either nonsense or fallacious. The corrected version of his argument is neither nonsensical, nor fallacious, nor does it fail to support the point it was intended to support. |
| jameskuyper@alumni.caltech.edu: Apr 08 07:40AM -0700 On Monday, April 8, 2019 at 10:09:38 AM UTC-4, Alf P. Steinbach wrote: > > into an invalid one. > I don't think so, for example because this very response is a > counter-example. Feel free to identify the specific logical fallacy (or fallacies) that applies. For a starting point, please review <https://en.wikipedia.org/wiki/List_of_fallacies#Formal_fallacies>. Note, in particular, that none of the items listed under <https://en.wikipedia.org/wiki/List_of_fallacies#Improper_premise> is a fallacy because the relevant premise is false - they are fallacies, regardless of whether the relevant premise is true or false, because of an improper relationship between the nature of the premise and the argument that uses that premise. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 08 05:06PM +0200 > It seems that if you want an way to specify the n'th element of the > vector, you don't want an iterator, but an numerical index, and use > indexing operations on the vector. No, i want to use iterators. > an extension of a pointer that when working on a sequence always points > to a GIVEN item, and the invalidation rules tells you when that > assumption no longer holds. The invalidation-rules are not necessary here. I gave a nearby implemen- tation of erase and this implementation doesn't invalidate the iterators beginning with the erased element. And guaranteeing that the iterators remain valid doesn't put any restrictions on the implementation. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 08 05:14PM +0200 >> about the influence on the committees decisions that led to the wording. > Does that sentence accurately reflect what you were claiming? You > weren't clear about which decision you were accusing gcc of influencing, I never claimed they influenced a decision. That may be why it's unclear in your mind. > but I'd been assuming that you were talking about the committee's > decision on the DR, not their decision on the writing of the wording > itself. This looks like an example of false memory. > 1. Your comments that this is an issue about the interpretation of the > words, implying that you were under the misapprehension that the other > interpretation was also consistent with the words. The other interpretation is the only sensible one, e.g. not incompatible with the standard library's algorithm functions, not adding UB traps. But we got what we got. Apparently to marginally ease the life of compiler writers, at cost. > 2. Your comments, nonsensical in context, about whether the gcc > developers could have been able to read the words of the first standard, > which was never actually relevant to what he was talking about. I guess I lost your train of thought here. But considering, as noted above, that you apparently started with a falsehood: anything can be proved from a falsehood. > 3. It's marginally more plausible that gcc might have significantly > influenced the later decision, because they would have had 3 more years > to accumulate enough influence to do so. No-one would have to influence any decision in order to promote an interpretation of the wording that resulted from the decision. Assuming that's necessary is, well, nonsensical. A time travel view. >> Which is what I meant. > You meant to claim that gcc influenced the committee's decision. WTF? > If his > premise had been correct, presenting his argument would have proved you > were incorrect on that point. You make me laugh. Thanks. :) > Because his premise was inaccurate, the > corrected version of his argument still served to point out that your > claim was implausible. Lols. [snip] Cheers!, - Alf |
| jameskuyper@alumni.caltech.edu: Apr 08 09:33AM -0700 On Monday, April 8, 2019 at 11:14:50 AM UTC-4, Alf P. Steinbach wrote: > On 08.04.2019 16:33, jameskuyper@alumni.caltech.edu wrote: > > On Monday, April 8, 2019 at 9:57:37 AM UTC-4, Alf P. Steinbach wrote: ... > > Does that sentence accurately reflect what you were claiming? You > > weren't clear about which decision you were accusing gcc of influencing, > I never claimed they influenced a decision. On Thursday, April 4, 2019 at 1:44:27 AM UTC-4, Alf P. Steinbach wrote: ... > Thanks, now it appears to be clear where the nonsense comes from, > namely the "optimization" in the GCC compiler. At the time you posted that message, I had already posted my message identifying the C committee's resolution of DR#017 confirming the truth of that "nonsense". Therefore, the only way you could justify asserting that the nonsense came from gcc is to imply that gcc influenced the committee's decision when resolving that DR. Since it's not clear whether you had yet read that part of my earlier message at the time your wrote that one, it's not entirely clear whether that's what you intended. Ben's comment served to remind you that, if that is what you meant, it didn't make sense. And he was right about that. If that isn't what you meant by that comment, saying so would have been a better response, to any of the subsequent messages on this sub-thread, than incorrectly claiming that Ben's logic was invalid. > > interpretation was also consistent with the words. > The other interpretation is the only sensible one, e.g. not incompatible > with the standard library's algorithm functions, not adding UB traps. It suffers from just one key problem: it's inconsistent with the wording of the standard. The key point is that the standard's wording refers to an array (called "x" in the current version of the C++ standard), and there is no array declared that can be substituted for "x" which has the right properties to justify the only interpretation you consider sensible. And the committee has made it clear that the interpretation you consider senseless is the one they intended to apply. > But we got what we got. > Apparently to marginally ease the life of compiler writers, at cost. It wasn't done for that reason, as you've been repeatedly told. It was done in the belief that code which violates this rule is logically flawed. Dispute that belief if you wish, but please stop suggesting, without supporting evidence, that some other reason was behind this "senseless" decision. The optimization I mentioned is NOT such evidence, since I did not identify it as a motivation for the rule.89012 > > developers could have been able to read the words of the first standard, > > which was never actually relevant to what he was talking about. > I guess I lost your train of thought here. You clearly never had it. He made an argument which did not depend in any way upon whether or not the original intent of the wording matched the interpretation that the committee eventually confirmed as correct, and which did not depend, in any fashion, upon whether or not gcc evelopers had ever actually read the standard, by claiming: On Friday, April 5, 2019 at 11:56:44 AM UTC-4, Alf P. Steinbach wrote: ... > Without that circular assumption the above would express in a Spock- > incompatible way that GCC folks could not have made an interpretation > of wording that already existed, which is a much worse fallacy. ... > > to accumulate enough influence to do so. > No-one would have to influence any decision in order to promote an > interpretation of the wording that resulted from the decision. Someone would have to influence the decision to write the words the way they were written, in order to make sure that those words were written in a way consistent with the optimization they wanted to make. They would have had to influence the decision about how to resolve DR#017, in order to make sure that it wasn't resolved in a way that repudiated that interpretation. The only way to justify holding gcc responsible for the "nonsense" that was confirmed by the committee's resolution of DR#017 is to imply that they had such influence over at least one of those two decisions. Which is implausible, though not, as originally implied, impossible. > >> Which is what I meant. > > You meant to claim that gcc influenced the committee's decision. > WTF? As cited above, Thursday, April 4, 2019 at 1:44:27 AM UTC-4. |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 08 08:20PM +0300 On 8.04.2019 18:06, Bonita Montero wrote: > tation of erase and this implementation doesn't invalidate the iterators > beginning with the erased element. And guaranteeing that the iterators > remain valid doesn't put any restrictions on the implementation. So what prohibits you from using your own implementation instead of std::vector::erase()? It looks like nobody else has any problem with the current wording of the standard, so a custom solution for your specific needs seems appropriate. PS. Your implementation lacks a std::move(), without it there would be some unneeded overhead when copying non-trivial types. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 08 07:32PM +0200 > PS. Your implementation lacks a std::move(), without it there would be > some unneeded overhead when copying non-trivial types. I added a follow-up-posting where I added the move. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 08 08:08PM +0200 > At the time you posted that message, I had already posted my message > identifying the C committee's resolution of DR#017 confirming the truth > of that "nonsense" Maybe you had, I don't give a fuck. I hadn't read it. Cheers!, - Alf |
| jameskuyper@alumni.caltech.edu: Apr 08 12:07PM -0700 On Monday, April 8, 2019 at 2:08:35 PM UTC-4, Alf P. Steinbach wrote: > On 08.04.2019 18:33, jameskuyper@alumni.caltech.edu wrote: ... > > identifying the C committee's resolution of DR#017 confirming the truth > > of that "nonsense" > Maybe you had, I don't give a fuck. I hadn't read it. OK, so that explains your comment in that message. However, in your very next message (Thursday, April 4, 2019 at 11:51:59 PM UTC-4) where you objected to Ben's response to that comment, you also acknowledged the existence and authority (if not the sanity) of committee's resolution to DR#017. Therefore, you were aware of it at that time, and should have understood by then what Ben was referring to. If you'd simply responded to Ben's comment by saying "I'm sorry, I wrote that before I found out about DR#017. I now understand that the nonsense actually came from the committee itself", it would have saved all three of a us a lot of time and trouble. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 08 03:10PM +0200 I'd like to have finally with C++, but unfortunately C+ lacks finally. And RAII is not always an alterantive because writing a class with a con- and destructor for a purpose only used once is mostly too complex. So I had the idea of a wrapper-class which calls the ()-operator of another class on destruction. So here's my solution. #include <iostream> using namespace std; template<typename T> struct invoke_on_destruct { T &t; invoke_on_destruct( T &t ) : t( t ) { } ~invoke_on_destruct() { t(); } }; int main() { string str( "hello world" ); auto f = [&str]() { cout << str << endl; }; invoke_on_destruct<decltype(f)> des( f ); return 0; } I think that's very handy for emulating finally. Is there already a class like invoke_on_destruct in the C++ standard-library? |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 08 03:43PM +0200 On 08.04.2019 15:10, Bonita Montero wrote: > } > I think that's very handy for emulating finally. Is there already > a class like invoke_on_destruct in the C++ standard-library? No, but there is ¹one called `final_action` in Microsoft's (!) helper library for the C++ core guidelines, on GitHub. It's modelled on Petru Margineans (often referred to as co-author Andrei Alexandrescu's) ²ScopeGuard class, but without the ScopeGuard dimiss functionality, and apparently without mentioning ScopeGuard or Marginean. Cheers!, - Alf Links: ¹ <url: https://github.com/Microsoft/GSL/blob/master/include/gsl/gsl_util> ² <url: http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758> |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 08 10:13AM +0200 On 07.04.2019 16:48, Daniel wrote: > work in all these environments. > I don't suppose you would have any suggested alternatives that would work > with Visual C++ 140 (2015) or 141 (vs 2017)? I sort of wish now that I had not hastily uninstalled VS 2017. I think I still have VS 2012... But, try rewriting with specialization instead of SFINAE, maybe? Cheers!, - Alf |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 08 10:27AM +0200 On 07.04.2019 16:48, Daniel wrote: > work in all these environments. > I don't suppose you would have any suggested alternatives that would work > with Visual C++ 140 (2015) or 141 (vs 2017)? Wait, with VS 2017, did you remember to specify the version of the standard? Like, `/std:c++17`? This is a useful set of options for that compiler: /nologo /std:c++17 /Zc:__cplusplus /utf-8 /EHsc /GR /W4 /FI"iso646.h" /D _CRT_SECURE_NO_WARNINGS /D _STL_SECURE_NO_WARNINGS Cheers & hth., - ALf |
| Daniel <danielaparker@gmail.com>: Apr 08 05:15AM -0700 On Monday, April 8, 2019 at 4:13:59 AM UTC-4, Alf P. Steinbach wrote: > I sort of wish now that I had not hastily uninstalled VS 2017. > I think I still have VS 2012... It appears there were a number of SFINAE issues with VS 2017, it looks like this one was fixed in version 15.9 (or _MSC_VER 1916.) I have version 15.8.7 installed, and AppVeyor has 15.9, I experienced the bug on my desktop, AppVeyor passed. As noted in my other post, it also passed on gcc 4.8 and later, and clang 3.9 and later. Since I don't want to give up support for vs2015 over this, I've #def'ed a hack for _MSC_VER < 1916. Your reply was helpful. Daniel |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 08 10:58AM +0200 I'd like to have a templated class with an iterator-class as a template -parameter. And internally the class should have a vector having the element-type the iterator "points" to. I could write vector<decltype(*it)> when it is a iterator-instance. But I'd like to have something like vector<decltype(*IteratorType)>. Theoretically the compiler could deduce the type of *IteratorType by analyzing the operator * of IteratorType. Even there's the issue that this type would be a refernce this could work by writing vector<decltype(remove_reference<*IteratorType>::type). But the standard doesn't allow all this. So is there a clever way arround this mess? |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 08 11:33AM +0200 On 08.04.2019 10:58, Bonita Montero wrote: > vector<decltype(remove_reference<*IteratorType>::type). But the > standard doesn't allow all this. > So is there a clever way arround this mess? Not so clever: `decltype` + `std::declval` + `std::remove_reference_t`. Clever: `std::iterator_traits`. Cheers!, - Alf |
| David Brown <david.brown@hesbynett.no>: Apr 08 09:54AM +0200 >> be homophobic, transphobic and misogynist which makes it unprofessional >> and you a bigoted > I wonder if you would say the same thing about Ben Shapiro. Is this guy a C++ programmer? If not, why bring him up? This is a C++ newsgroup, for discussing C++. It is not a place to advertise commercial services, or your company website, or bonus prizes. Mr. Flibble is correct that your website and its bigoted links will turn away potential users - and your posts here idolising characters like Shapiro will ensure they stay away. You are, of course, free to follow whatever religious ideas (or lack thereof) you like, but do not try to impose them on others. You are free to put any such ideas on your website (if you want to chase away users, that's your choice), but not to post them in this C++ newsgroup. A link to your website, and perhaps a non-bigoted off-topic comment, is fine in a Usenet standard 4-line signature. (The same, of course, applies to Mr. Flibble, who errs in similar ways.) |
| 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