- We've won! - 2 Updates
- new benchmark for my read/write algorithm... - 3 Updates
- vector<>::erase-behaviour - 6 Updates
- c++ is a cobol, c still being great - 6 Updates
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 06 06:25AM -0700 > I respectfully can't make sense of your position, except that it seems > to require much muddying of waters, this time via "doesn't matter". > Maybe it requires someone better at double-think+ than me. My apologies for the long delay in responding. The difficulty here is a subtle point of language, and I'm afraid I haven't communicated my thoughts about that as well as I would like. Unless you think it's important to pursue this further, perhaps we could just note that there has been a communication problem and leave it at that. |
| fir <profesor.fir@gmail.com>: Apr 06 01:37PM -0700 W dniu sobota, 17 listopada 2018 18:33:11 UTC+1 użytkownik Vir Campestris napisał: > Templates, etc. But if you know what you're sorting and are willing to > put that into the sort code - I don't know why C++ should be faster. > Andy in my opinion (which is sorta common opinion) well written c++ is just equal with well written c in speed c hivever in my opinion beats c++ very much in app design and lack of syntax bloat, faster compilation, better compatibility etc |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Apr 06 01:18AM -0700 On 4/5/2019 4:01 AM, Bonita Montero wrote: >> In gcc, asm volatile ("" ::: "memory") is a compiler barrier. > Yes, it is a logical barrier, but it has aquire as well as release > -behaviour. asm volatile ("" ::: "memory") does _not_ have any implied acquire or release characteristics whatsoever. It is a simple compiler barrier. There are different types of barriers. Do you want standalone or embedded? For what its worth, they are all compiler barriers. std::atomic_thread_fence(std::memory_order_acquire); is a compiler fence _and_ an acquire operation. This is standalone. They can also be "embedded" into atomic ops themselves. [...] Try to quote properly to keep the conversation intact? |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 06 08:51PM +0200 >> -behaviour. > asm volatile ("" ::: "memory") does _not_ have any implied acquire or > release characteristics whatsoever. Read what I wrote: I didn't write that this is a fence for the CPU. |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Apr 06 01:01PM -0700 On 4/6/2019 11:51 AM, Bonita Montero wrote: >> asm volatile ("" ::: "memory") does _not_ have any implied acquire or >> release characteristics whatsoever. > Read what I wrote: I didn't write that this is a fence for the CPU. It is sometimes hard to read what you quote, and what you actually write. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 06 04:33AM +0200 > That trivial answer is completely inapplicable to the context - he > incorrectly assumed that "gcc folk" didn't exist yet at the relevant > time. Yes, his argument totally lacked any logic. > An organization that didn't exist yet could not possibly have > influenced either the writing of those words or the committee's > resolution of the DR, Right. > and the fact that they could (and almost certainly > 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. Cheers!, - Alf |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 06 11:12AM +0100 "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: <cut> > Yes, his argument totally lacked any logic. I think I am the he of whom you speak, but I don't see any value in relying to this specific point. I am more interested in the original opinion that either the wording of the C standard or the later DR clarifying the intent comes from gcc's optimisations (either planned or implemented). Is that still your view (or the view of any other readers), and if it is, is there any evidence for it? -- Ben. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 06 03:44PM +0200 On 06.04.2019 12:12, Ben Bacarisse wrote: > clarifying the intent comes from gcc's optimisations (either planned or > implemented). Is that still your view (or the view of any other > readers), and if it is, is there any evidence for it? Far upthread we were discussing two ~opposite interpretations of the standard, and when optimization (essentially through assuming non-aliased pointer results of expressions) was mentioned as a rationale for the UB interpretation, I thought it likely that the UB interpretation of the wording came from the GCC optimization team. They're into things like that, in my view. Later, with C Defect Report 17 pointed out, it became clear that I was wrong about which interpretation was correct. Then I noted that, and also that I no longer believed it came from GCC, but that the mindset behind such an interpretation is similar: the 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. Cheers!, - Alf |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 06 04:03PM +0100 > rationale for the UB interpretation, I thought it likely that the UB > interpretation of the wording came from the GCC optimization > team. They're into things like that, in my view. Yes, I got that. I was curious as to what, if any, was the evidence for your (now changed) view. > Later, with C Defect Report 17 pointed out, it became clear that I was > wrong about which interpretation was correct. Yes, I got that too. > 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. Ah, I missed that change. It appears to be a same view except that gcc, specifically, is off the hook. It's compilers in general driving the inclusion of UB traps. What, if any, is the evidence for that? That's probably right in a rather limited sense. For example, the undefined and implementation defined behaviour of the shift operations are clearly intended to allow "optimisation" in the sense of avoiding the need for extra code to implement a kind of shift not supported by the hardware. But in reality it's the hardware design that's driving the UB, but really the compilers that target that hardware. My gut feeling about making sub-array index overflow undefined is that it may have been driven by a desire to allow cheap indexing using offsets on segmented architectures. I've got no evidence for this. -- Ben. |
| David Brown <david.brown@hesbynett.no>: Apr 06 05:34PM +0200 On 06/04/2019 17:03, Ben Bacarisse wrote: > the need for extra code to implement a kind of shift not supported by > the hardware. But in reality it's the hardware design that's driving > the UB, but really the compilers that target that hardware. I am not convinced this view applies to many of the undefined behaviours in C. It certainly applies to a lot of the implementation defined behaviours, and unspecified behaviours. These give the compiler writer the freedom to match operations to suit their target. But undefined behaviours are, AFAICS, mainly for things that don't actually make sense. Making them UB tells programmers "don't write nonsensical code", and it tells compiler writers "you can assume code is sensible". The result of this is clearer code for the programmer who sticks to the rules as no one needs to suspect them of doing weird things, like running outside of arrays. The compiler can make optimisations based on these, such as knowing that if you add two positive integers, the result will still be positive, and that you can re-arrange expressions based on normal mathematical rules. And the compiler (and debuggers, sanitizers, etc.) can give better warnings and aid the developer because code errors such as integer overflow are clearly bugs. So as I see it, UB is an advantage to me, as a programmer. The only real problem with it is people who think they "know" how particular UB is supposed to work, who think they "know" what the standards committee really meant to write (as though the committee were so careless as to leave such "mistakes" in multiple generations of the standards), and who think "it worked when I tried it" is good enough. > My gut feeling about making sub-array index overflow undefined is that > it may have been driven by a desire to allow cheap indexing using > offsets on segmented architectures. I've got no evidence for this. I think that would have lead to a lot of challenges when accessing the array as a whole using char* pointers (or memcpy). My own gut feeling (with no evidence either) is that this is simply a matter of consistency. If you have "int a[5][4];", then "a[1]" is an array of 4 int's - and you are not allowed to index an array of 4 int's outside of 0 .. 3. This gives you a simple and consistent rule. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 06 06:05PM +0200 On 06.04.2019 17:03, Ben Bacarisse wrote: > the need for extra code to implement a kind of shift not supported by > the hardware. But in reality it's the hardware design that's driving > the UB, but really the compilers that target that hardware. I agree regarding shift operations. But with the multi-dimensional arrays it's not hardware driving the UB. The sizeof requirements guarantee contiguous multi-D arrays, which must be accessible as contiguous via byte pointers, so to place sub-arrays in different segments you'd need run-time sized and allocated segments with byte level size granularity, somehow appearing as contiguous memory to byte pointers, and I just don't see that. One extreme example of UB for the ultra-marginal convenience of compiler writers, at possibly very high expense to language users: in C++03 it was undefined behavior to have a decimal integer literal to large for type `long`. Undefined behavior is at run-time so the compiler could within its rights produce a gotcha-not-what-you-expected-moo-hah program. In C++17 such a literal that is too large for the type that otherwise would be used, causes the source code to be ill-formed, which requires a diagnostic. > My gut feeling about making sub-array index overflow undefined is that > it may have been driven by a desire to allow cheap indexing using > offsets on segmented architectures. I've got no evidence for this. Sorry for repeating text, but the quoting sort of requires it: The sizeof requirements guarantee contiguous multi-D arrays, which must be accessible as contiguous via byte pointers, so to place sub-arrays in different segments you'd need run-time sized and allocated segments with byte level size granularity, somehow appearing as contiguous memory to byte pointers, and I just don't see that. Cheers!, - Alf |
| Melzzzzz <Melzzzzz@zzzzz.com>: Apr 06 04:59AM > Lisp is better Hahhahahahhahaha., -- press any key to continue or any other to quit... |
| Siri Cruise <chine.bleu@yahoo.com>: Apr 06 01:07AM -0700 In article <rmWpE.37569$Dc2.9188@fx18.am4>, Melzzzzz <Melzzzzz@zzzzz.com> wrote: > On 2019-04-05, cdalten@gmail.com <cdalten@gmail.com> wrote: > > Lisp is better > Hahhahahahhahaha., ADD 1 TO COBOL I think you mean. DATA DIVISION. OBJECT SECTION. OD LISP. 01 AREGISTER LISP. 01 DREGISTER LISP. METHOD CAR. RETURN AREGISTER. END METHOD. METHOD CAR. RETURN DREGISTER. END METHOD. METHOD CONS WITH OTHER LISP. LOCAL CELL LISP. ASSIGN NEW LISP TO CELL. ASSIGN SELF TO AREGISTER OF CELL. ASSIGN OTHER TO DREGISTER OF CELL. RETURN CELL. END METHOD. METHOD EQ WITH OTHER LISP. RETURN ADDRESS OF SELF EQUALS ADDRESS OF OTHER. END METHOD. METHOD NULLP. RETURN ADDRESS OF SELF EQUALS NIL. END METHOD. METHOD APPEND WITH OTHER LISP. IF SEND NULLP TO SELF THEN RETURN OTHER. RETURN SEND CONS TO (SEND CAR TO SELF) WITH (SEND APPEND TO (SEND CDR TO SELF) WITH OTHER). END METHOD. METHOD REVERSE. IF NULLP SEND TO SELF THEN RETURN SELF. RETURN SEND CONS TO (SEND APPEND TO (SEND REVERSE TO CDR OF SELF) WITH (SEND CONS TO (SEND CAR TO SELF) WITH NIL). END METHOD. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ The first law of discordiamism: The more energy This post / \ to make order is nore energy made into entropy. insults Islam. Mohammed |
| Melzzzzz <Melzzzzz@zzzzz.com>: Apr 06 08:24AM > TO (SEND REVERSE TO CDR OF SELF) > WITH (SEND CONS TO (SEND CAR TO SELF) WITH NIL). > END METHOD. I forgot COBOL ;p -- press any key to continue or any other to quit... |
| fir <profesor.fir@gmail.com>: Apr 06 02:34AM -0700 W dniu sobota, 6 kwietnia 2019 10:24:43 UTC+2 użytkownik Melzzzzz napisał: > I forgot COBOL ;p > -- > press any key to continue or any other to quit... by cobol i meant a synonym of bloated unhandy (and unfamous of it) language in fact c++ is far more bloated unhandy than cobol (m ainly for a reasons of disaster oop, templates and other results of design 'rules') |
| cdalten@gmail.com: Apr 06 06:37AM -0700 On Friday, April 5, 2019 at 9:59:11 PM UTC-7, Melzzzzz wrote: > > Lisp is better > Hahhahahahhahaha., I'd like to point out to you dickhead heathens that one of the top Engineering schools uses Lisp, and not C++ for an undergraduate level Computer Science Class. And here is the link to the book.... https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book.html And I'd also like to point out well known programming rule known among the Silicon Valley computer programmers... https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule And I quote... "That sounds like a joke, but it happens so often to varying degrees in large programming projects that there is a name for the phenomenon, Greenspun's Tenth Rule: Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. " So with that, if any of you flunkies wish to provide some decent response, either through a semi well thought out response, or by providing some scholarly link to rebut my statements, now is the time to do it. Otherwise go back to jerking off to animal porn. Well, midget porn in you're in the U.K. -). |
| Melzzzzz <Melzzzzz@zzzzz.com>: Apr 06 02:00PM > I'd like to point out to you dickhead heathens that one of the top > Engineering schools uses Lisp, and not C++ for an undergraduate level > Computer Science Class. Lisp is nice for learning, but useless for anything else... -- press any key to continue or any other to quit... |
| 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