- "Unicode" - 9 Updates
- This will work or not? - 13 Updates
- Implications of conversion function template argument deduction in C++ (stackoverflow cross-post) - 1 Update
- /* Introducing "indexitor", a new C++ container... */ - 2 Updates
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 02 02:44PM +0100 On 02/09/2016 01:52, Jerry Stuckle wrote: >> /Flibble > Nope. ISO is not the only standard in the world - and was not the only > recognized C++ standard. Fractal wrongness: the state of being wrong at every conceivable scale of resolution. That is, from a distance, a fractally wrong person's worldview is incorrect; and furthermore, if you zoom in on any small part of that person's worldview, that part is just as wrong as the whole worldview. http://rationalwiki.org/wiki/Fractal_wrongness > But once again you're just showing you're no more than a stoopid troll. > Nothing new here. Project much mate? /Flibble |
| Jerry Stuckle <jstucklex@attglobal.net>: Sep 02 10:10AM -0400 On 9/2/2016 9:44 AM, Mr Flibble wrote: > part of that person's worldview, that part is just as wrong as the whole > worldview. > http://rationalwiki.org/wiki/Fractal_wrongness ROFLMAO! You are completely clueless, as usual. But that's not surprising for a stoopid troll (which you yourself have shown to be). >> Nothing new here. > Project much mate? > /Flibble Yes, you do project a lot. But that's what trolls do. And you've proven yourself to be one. Not a very good one, but a funny one at times. You don't even know C++ now - and never were programming in C++ before the C98 standard came out. How would you know? And according to you, Java has no standard because there is not an IOS standard. However, Oracle and millions of programmers around the world would disagree with you. But you'd claim to be right on that, also. What's next - the sun rising in the west? Or does that happen only in the Southern Hemisphere? It's no wonder you've never been able to get a decent job. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 02 04:35PM +0100 On 02/09/2016 15:10, Jerry Stuckle wrote: [snip] > But you'd claim to be right on that, also. What's next - the sun rising > in the west? Or does that happen only in the Southern Hemisphere? > It's no wonder you've never been able to get a decent job. Fractal wrongness: the state of being wrong at every conceivable scale of resolution. That is, from a distance, a fractally wrong person's worldview is incorrect; and furthermore, if you zoom in on any small part of that person's worldview, that part is just as wrong as the whole worldview. http://rationalwiki.org/wiki/Fractal_wrongness /Flibble |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 02 05:02PM +0100 On 02/09/2016 15:10, Jerry Stuckle wrote: [snip] > Yes, you do project a lot. But that's what trolls do. And you've > proven yourself to be one. Not a very good one, but a funny one at times. You even project projection; you are in serious need of medication. > You don't even know C++ now - and never were programming in C++ before > the C98 standard came out. How would you know? I don't know C++? Funny but https://github.com/FlibbleMr/ is entirely my own work and I use C++ every day at work as a senior software engineer. These are surely amazing feats for someone who doesn't know C++. I have been coding in C++ since 1993 (five years before the FIRST C++ ISO standard). > And according to you, Java has no standard because there is not an IOS > standard. However, Oracle and millions of programmers around the world > would disagree with you. Java is off topic however I'll bite: what you are talking about are called "de facto standards" not "standards". > But you'd claim to be right on that, also. What's next - the sun rising > in the west? Or does that happen only in the Southern Hemisphere? Strawman. > It's no wonder you've never been able to get a decent job. Whether or not any of my jobs were/are "decent" is highly subjective. I was a member of the tiger team for and I wrote a fair bit of the software for the world's first smartphone (the Ericsson R380); is that "decent" enough for you? /Flibble |
| Jerry Stuckle <jstucklex@attglobal.net>: Sep 02 12:26PM -0400 On 9/2/2016 11:35 AM, Mr Flibble wrote: > worldview. > http://rationalwiki.org/wiki/Fractal_wrongness > /Flibble You keep saying that. But that doesn't make it true. Your inability to get a decent job, however, is true. So are your demonstrated lack of C++ knowledge and that you are a troll. You keep trying. But it doesn't work. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Sep 02 12:33PM -0400 On 9/2/2016 12:02 PM, Mr Flibble wrote: >> proven yourself to be one. Not a very good one, but a funny one at >> times. > You even project projection; you are in serious need of medication. Nope. You have proven youself time and time again to be a trill. > These are surely amazing feats for someone who doesn't know C++. > I have been coding in C++ since 1993 (five years before the FIRST C++ > ISO standard). ROFLMAO! So you've been coding C++ since 1993. Maybe one of these days you'll get it right. I doubt it, though. You've already proven yourself to be hopeless. And BTW - I've been programing C++ since 1988 - one year after the first commercial compiler from AT&T was released in (in beta form). >> would disagree with you. > Java is off topic however I'll bite: what you are talking about are > called "de facto standards" not "standards". Nope, they are standards. The fact the standards aren't issued by ISO does not mean they are not standards. >> But you'd claim to be right on that, also. What's next - the sun rising >> in the west? Or does that happen only in the Southern Hemisphere? > Strawman. No, a serious question for you. Maybe you can google it. > software for the world's first smartphone (the Ericsson R380); is that > "decent" enough for you? > /Flibble So you claim. You wouldn't last two weeks on any competent team. But then how many smartphones is Ericsson making now? That was a huge success, wasn't it? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 02 05:53PM +0100 On 02/09/2016 17:33, Jerry Stuckle wrote: >>> times. >> You even project projection; you are in serious need of medication. > Nope. You have proven youself time and time again to be a trill. Youself? Trill? Are you having a stroke now? Can't get your troll out quick enough eh mate? > ROFLMAO! So you've been coding C++ since 1993. Maybe one of these days > you'll get it right. I doubt it, though. You've already proven > yourself to be hopeless. I repeat: https://github.com/FlibbleMr/ is entirely my own work and I use C++ every day at work as a senior software engineer. These are surely amazing feats for someone "who doesn't know C++" and/or "is hopeless" and can't "get it right". > And BTW - I've been programing C++ since 1988 - one year after the first > commercial compiler from AT&T was released in (in beta form). I am amazed that someone with your claimed experience can seemingly do nothing but troll others on Usenet. >> called "de facto standards" not "standards". > Nope, they are standards. The fact the standards aren't issued by ISO > does not mean they are not standards. Yep, a de facto standard is not the same thing as a standard. >>> in the west? Or does that happen only in the Southern Hemisphere? >> Strawman. > No, a serious question for you. Maybe you can google it. No, it is a strawman. >> "decent" enough for you? >> /Flibble > So you claim. You wouldn't last two weeks on any competent team. You keep making these groundless assertions based on no evidence all the time, why do you do it? You know it just makes you look like an idiot right? All the teams I have worked with were competent and I was a member of them for years and left them on my own terms. > But then how many smartphones is Ericsson making now? That was a huge > success, wasn't it? Yes it was a success actually. I left Sony Ericsson in 2003 and they continued to be successful for several years after that. Sony Ericsson's mistake was sticking with Symbian OS rather than embracing Android when it was clear that that was where the smart money was going. Nevertheless Sony Ericsson was folded back into Sony Mobile and they continue to do quite well now. Sony Android phones are great. /Flibble |
| Gareth Owen <gwowen@gmail.com>: Sep 02 07:20PM +0100 >> commercial compiler from AT&T was released in (in beta form). > I am amazed that someone with your claimed experience can seemingly do > nothing but troll others on Usenet. That's a bit harsh. Those consulting companies didn't bankrupt themselves, you know |
| Jerry Stuckle <jstucklex@attglobal.net>: Sep 02 04:36PM -0400 On 9/2/2016 12:53 PM, Mr Flibble wrote: >> Nope. You have proven youself time and time again to be a trill. > Youself? Trill? Are you having a stroke now? Can't get your troll out > quick enough eh mate? ROFLMAO! Another stoopid comment by a stoopid troll. But in your case, "trill" might be a better description! > use C++ every day at work as a senior software engineer. These are > surely amazing feats for someone "who doesn't know C++" and/or "is > hopeless" and can't "get it right". Yup, and pretty crappy work, at that. I'd be embarrassed to claim work like that. >> commercial compiler from AT&T was released in (in beta form). > I am amazed that someone with your claimed experience can seemingly do > nothing but troll others on Usenet. This from a proven troll! >> Nope, they are standards. The fact the standards aren't issued by ISO >> does not mean they are not standards. > Yep, a de facto standard is not the same thing as a standard. A standard is a standard. Period. >>> Strawman. >> No, a serious question for you. Maybe you can google it. > No, it is a strawman. Nope. A serious question - but obviously one you can't answer! But then you don't know what a strawman is either, do you? > right? > All the teams I have worked with were competent and I was a member of > them for years and left them on my own terms. Your posts in this and other newsgroups speak otherwise. I don't know a single team I've ever worked with who would hire you. > Sony Ericsson was folded back into Sony Mobile and they continue to do > quite well now. Sony Android phones are great. > /Flibble You got your arse fired for incompetence, you mean. Which is why you've never been able to get a decent job since then. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| me <crisdunbar@gmail.com>: Sep 02 08:19AM -0700 On Thursday, September 1, 2016 at 7:17:16 PM UTC-7, Jerry Stuckle wrote: > And where does it say the rule can override such structures? You are > misreading the standard. The as-if rule applies to execution, not > memory layout. Have _you_ read 1.9.1? "[C]onforming implementations are required to emulate (only) the observable behavior of the abstract machine as explained below." Since 9.2.13 .gt. 1.9, clearly it applies to structure member layout. > > disobeying 9.2.13? What would you say to convince them that the as-if > > rule _didn't_ apply? > Yes, because they are. What would YOU say to convince someone it is OK? My first recourse of course would be to reference 1.9.1. But maybe a simpler approach would just be "Prove it". I.e., prove that in program 1 the memory address of s.a is higher than s.b, OR prove that in program 2 the memory address of s.a is lower than s.b. > If your interpretation were correct, there would be no need for 9.2.13. > But it's there - so there must be a reason. Maybe it's because you > don't understand the as-if rule. Of course it's still needed. It describes certain observable behaviour, like taking addresses and offsets of struct members. But in the absence of taking those addresses, I really can't understand how "behaviour" that is _completely_unobservable_ via standards-mandated means, could possibly be construed as "observable behaviour". |
| David Brown <david.brown@hesbynett.no>: Sep 02 05:39PM +0200 On 02/09/16 13:37, Ben Bacarisse wrote: >> uint32_t as_array[5]; >> } u; > Is the 5 a typo? No - "c" is a uint64_t, while the others are uint32_t. I don't know if that was a typo in the OP's first post, but I've followed it. > I've not been following the details, so maybe there are some assumptions > in play here, but if the struct has unknown padding the only thing you > can rely on is that u.a and u.as_array[0] overlap. It's true that there could be padding here - my assumption is that there is no padding. But the point still stands - /if/ the first code is allowed (depending on implementation-dependent padding), then the second code is an allowable transformation by the compiler. |
| Melzzzzz <mel@zzzzz.com>: Sep 02 05:40PM +0200 On Fri, 02 Sep 2016 17:39:21 +0200 > > Is the 5 a typo? > No - "c" is a uint64_t, while the others are uint32_t. I don't know > if that was a typo in the OP's first post, but I've followed it. It was not typo. I only missed to say that struct has packed attribute. |
| David Brown <david.brown@hesbynett.no>: Sep 02 05:46PM +0200 On 02/09/16 15:17, Manfred wrote: > sequentially, variables must be ordered as coded. Again, even if obscure > things would be allowed to happen, they would be transparent to the > programmer, so that they could be ignored. The point is that the output you have shown here is observable behaviour. In this case, it is the /only/ observable behaviour. And the compiler is free to make whatever transformations it wants, as long as the observable behaviour matches. The compiler is therefore free to re-arrange the structs as it wants - just as it is free to turn main() into int main(void) { puts("1\n2\n3\n0\n4\n"); } Of course, that would only be legal if the compiler knew that the code would not be statically linked with other code that called foo, bar, or main, or used u. When gcc had an option for re-ordering structs, it could only be enabled along with the "-fwhole-program" flag for precisely that reason. But if the relevant structs and functions had been locals or file static (with no "escapes"), then the compiler could freely transform it. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Sep 02 04:54PM +0100 >> Is the 5 a typo? > No - "c" is a uint64_t, while the others are uint32_t. I don't know if > that was a typo in the OP's first post, but I've followed it. Ah, right. I missed that. <snip> >> can rely on is that u.a and u.as_array[0] overlap. > It's true that there could be padding here - my assumption is that there > is no padding. I'd missed that too. <snip> -- Ben. |
| David Brown <david.brown@hesbynett.no>: Sep 02 05:59PM +0200 On 02/09/16 14:50, Jerry Stuckle wrote: >> my own. Are you telling me that you know better than they do? > The as-if rule applies to execution. If it applied here, 9.2.13 would > be meaningless. No, it would not be meaningless - it is as meaningful as the rest of the standard. The as-if rule says that could must produce observable behaviour as though it slavishly followed the standard - including 9.2.13. As long as the program produces the same observable behaviour, it can rearrange structs as it wants - just as it can make optimisations that appear to contradict any other rules. There is nothing special about 9.2.13 in this regard. Now, you failed to answer my question - are /you/ claiming to understand the standards better than the people who wrote the Pathscale compiler and the people who wrote gcc? >> the standards (C standards at least - I haven't read as much of the C++ >> standards) that makes this distinction. > Again you are incorrect. The same rule applies to C. I am happy to believe that the same rule applies here in C and C++. It is simply not the rule that you think it is. >> to change it. > The struct layout is observable behavior, and cannot be changed. 9.2.13 > says so. No, 9.2.13 says nothing about observable behaviour. Read it again, and see if you spot that phrase. And in the definition of observable behaviour (section 1.9.8), no mention is made of struct layout or memory (except in regard to volatile accesses). You are simply wrong here. You are making things up that are not in the standards. >> known to the compiler, the compiler is free to do as it wants. > Sorry, you are once again wrong. The compiler doesn't know what a > function does. You are really grasping at straws now, David. If the compiler does not know what a function does (such as for external functions), then it must assume the worst - it must assume it has volatile accesses to all globally visible data, for example, and thus any such data must follow the rules for struct layout. But it can assume that the external function has defined behaviour - and thus cannot read local data or file static data that has not escaped in some way, and it can re-arrange such data as it likes. And if the compiler knows the definition of the function, then it will know which re-arrangements and optimisations are safe. With whole-program or link-time optimisation, the compiler may even know the definitions of every function in the program. > Just admit you are wrong and move on. Or explain why 9.2.13 exists, > when according to you, it is meaningless. No, only you have claimed it is meaningless. I am quite happy with its meaning. |
| Jerry Stuckle <jstucklex@attglobal.net>: Sep 02 12:39PM -0400 On 9/2/2016 11:19 AM, me wrote: > emulate (only) the observable behavior of the abstract machine as explained > below." Since 9.2.13 .gt. 1.9, clearly it applies to structure member > layout. Yes, and "below" refers to the rest of section 1.9, NOT the entire rest of the standard. Additionally, 1.9 refers to "Program Execution". Not memory layout. > simpler approach would just be "Prove it". I.e., prove that in program 1 > the memory address of s.a is higher than s.b, OR prove that in program 2 > the memory address of s.a is lower than s.b. And once again you are reading the standard wrong. > of taking those addresses, I really can't understand how "behaviour" > that is _completely_unobservable_ via standards-mandated means, could > possibly be construed as "observable behaviour". Why is it still needed? It describes no behavior. It describes memory layout - which you just said is overridden by 1.9.1. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Sep 02 12:49PM -0400 On 9/2/2016 11:59 AM, David Brown wrote: > (except in regard to volatile accesses). > You are simply wrong here. You are making things up that are not in the > standards. No, you are making up things which are not what the standard says. No, section 1.9.8 doesn't say anything about struct layout. That is not its purpose. And 1.9.1 refers to the remainder of section 1.9, not the entire standard. Plus, 1.9 refers to program execution - not memory layout. Layout is not behavior. 1.9.1 is for things like the following: a = 2; b = 3; c = 2; Can be reordered to a = c = 2; b = 3; Of course it's more than that. But to stay in line with what you can understand, I'm keeping it simple. > assume that the external function has defined behaviour - and thus > cannot read local data or file static data that has not escaped in some > way, and it can re-arrange such data as it likes. And how is the compiler to know that? Does it predict the future? struct mystruc { int a, b; }; func f() } struct mystruct ms; ms.a = 1; // The structure has been defined ms.b = 2; write(ms); // NOW the compiler knows that there is a call } It is a one-pass compiler. There is no way for it to know when assigning ms.a that there is going to be a call to another function. > know which re-arrangements and optimisations are safe. With > whole-program or link-time optimisation, the compiler may even know the > definitions of every function in the program. Not before the structure has been defined. >> when according to you, it is meaningless. > No, only you have claimed it is meaningless. I am quite happy with its > meaning. No, you said the compiler is free to reorder the memory. That is in direct conflict with 9.2.13. So it is you who declare it meaningless. You are just digging yourself a deeper and deeper hole, -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| David Brown <david.brown@hesbynett.no>: Sep 02 08:22PM +0200 On 02/09/16 17:54, Ben Bacarisse wrote: >> It's true that there could be padding here - my assumption is that there >> is no padding. > I'd missed that too. I can't really blame you for not noticing my unstated assumptions - especially as they were based on the OP's omitted "packed" attribute :-) I'd be surprised if there are any implementations of C that would put padding in this struct even without a "packed" attribute - it would almost have to be an architecture with 64-bit int and 32-bit short for packing to make much sense. But it was still an assumption, and should have been stated. |
| David Brown <david.brown@hesbynett.no>: Sep 02 08:36PM +0200 On 02/09/16 18:49, Jerry Stuckle wrote: >> On 02/09/16 14:50, Jerry Stuckle wrote: >>> On 9/2/2016 3:35 AM, David Brown wrote: >>>> On 02/09/16 03:02, Jerry Stuckle wrote: <snip> > No, you are making up things which are not what the standard says. No, > section 1.9.8 doesn't say anything about struct layout. That is not its > purpose. I did not say that 1.9.8 discussed the layout of structs - I said it did /not/ cover struct layout. > And 1.9.1 refers to the remainder of section 1.9, not the entire > standard. Plus, 1.9 refers to program execution - not memory layout. > Layout is not behavior. 1.9.1 refers to the observable behaviour, which is defined "below" in 1.9.8. Section 1.9.8 refers to the entire rest of the standard. And memory layout is behaviour. > b = 3; > Of course it's more than that. But to stay in line with what you can > understand, I'm keeping it simple. It covers /vastly/ more than that. It is the basis for the concept of an "optimising compiler". > } > It is a one-pass compiler. There is no way for it to know when > assigning ms.a that there is going to be a call to another function. That was perhaps true in the days when compilers read programs on punched cards. But these days, compilers are smarter than that. Before the compiler generates anything for "ms.a", it has already parsed all the rest of the file - and perhaps all the other files in the program. Perhaps you use a one-pass compiler, with all its limitations. I don't know how many passes modern gcc or clang have, but according to a quick google gcc 4.6.2 had 207 unique passes. >> whole-program or link-time optimisation, the compiler may even know the >> definitions of every function in the program. > Not before the structure has been defined. The compiler collects all the information about the program, data, structures, functions, etc., before it starts organising the data or generating the code. That's the point of whole-program optimisation. >> meaning. > No, you said the compiler is free to reorder the memory. That is in > direct conflict with 9.2.13. So it is you who declare it meaningless. Yes, the compiler is free to re-order anything it likes - code, functions, memory, structs, whatever - as long as the observable behaviour is unchanged. > You are just digging yourself a deeper and deeper hole, You simply don't understand much about how compilers work. That's okay, you don't have to know how they work in order to use them. But you do look silly by continuing to flaunt your ignorance. But keep going, if you like - it is somewhat entertaining. The idea that a modern C compiler is one-pass and generates the code for one line of source before reading the next line gave me a bit of a chuckle. |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Sep 02 12:06PM -0700 On 8/31/2016 5:28 PM, Alf P. Steinbach wrote: >> why it will work (or not) , I would be grateful. > Formally there can be padding (except before the first item), and > therefore formally you're in UB-land. [...] Right. So, this little program below should have no undefined behavior: ________________________________________________ #include <cstddef> #include <cstdio> struct A { int v; }; struct B { A m_a0; char c; A m_a1; }; int main() { B b = { { 0 }, 'c', { 1 } }; A* pa0 = &b.m_a0; B* bp = reinterpret_cast<B*>(pa0); unsigned char* a = reinterpret_cast<unsigned char*>(bp); char* pc = reinterpret_cast<char*>(a + offsetof(B, c)); A* pa1 = reinterpret_cast<A*>(a + offsetof(B, m_a1)); pa0->v = 1; *pc = '2'; pa1->v = 3; std::printf("b.m_a0.v:%d\nb.c:%c\nb.m_a1.v:%d\n", b.m_a0.v, b.c, b.m_a1.v); return 0; } ________________________________________________ This should be fine, A and B are POD's and work well with offsetof. |
| me <crisdunbar@gmail.com>: Sep 02 12:26PM -0700 On Friday, September 2, 2016 at 9:39:15 AM UTC-7, Jerry Stuckle wrote: > Yes, and "below" refers to the rest of section 1.9, NOT the entire rest > of the standard. > Additionally, 1.9 refers to "Program Execution". Not memory layout. Footnote 5) explicitly says that _any_ requirement of the standard can be ignored as long as the observable behaviour is correct. Yes, it's only a footnote, but clearly conveys the intent of 1.9.1. 1.9.8 defines "observable behavior" in the obvious manner, which does _not_ include (explicitly) anything to do with memory layout. Finally (admittedly this is a less-than-language-lawyerly argument), I think that all the guff about observable behaviour, as-if rule, abstract machines, is about ensuring that the program produces well-defined output and does what we think programs should do. We want the correct prompts to show up for the user, we want the correct bits to show up in files, etc., etc. To insist that the standard would even _bother_ to care about struct layout except as it affects observable behaviour seems utterly useless. (And this is supported by footnote 5). > > the memory address of s.a is higher than s.b, OR prove that in program 2 > > the memory address of s.a is lower than s.b. > And once again you are reading the standard wrong. Okay, please explain how your correct reading is a counterargument to my "prove it" argument. I.e., what statement in the standard _precludes_ both those programs producing identical executables. _Prove_ that the addresses of the struct members are _not_ as the standard mandates. > > possibly be construed as "observable behaviour". > Why is it still needed? It describes no behavior. It describes memory > layout - which you just said is overridden by 1.9.1. I phrased that poorly. _If_ it affects observable behaviour, i.e., _if_ addresses are taken or member offsets are used, _then_ the implementation must take 9.2.13 into account to ensure that the observable behaviour is correct. But 1.9.1 (plus footnote 5) says that if there is _no_ affect on observable behaviour (as in my programs above), the implementation can do any darn thing it pleases with struct layout. |
| Jerry Stuckle <jstucklex@attglobal.net>: Sep 02 04:32PM -0400 On 9/2/2016 2:36 PM, David Brown wrote: >> purpose. > I did not say that 1.9.8 discussed the layout of structs - I said it did > /not/ cover struct layout. That is correct. Because 1.9.8 does not apply to structs (neither does 1.9.1). > 1.9.1 refers to the observable behaviour, which is defined "below" in > 1.9.8. Section 1.9.8 refers to the entire rest of the standard. > And memory layout is behaviour. No, there is a difference. But you don't understand that. >> understand, I'm keeping it simple. > It covers /vastly/ more than that. It is the basis for the concept of > an "optimising compiler". As I said - it's a SIMPLIFIED EXAMPLE - meant for a SIMPLE MIND. > Perhaps you use a one-pass compiler, with all its limitations. I don't > know how many passes modern gcc or clang have, but according to a quick > google gcc 4.6.2 had 207 unique passes. How about - ONE PASS. But then you need to see what each of those unique passes does. Here's a hint: 206 of them are for code optimization - not memory layout. That's why in C anything must be declared before it can be used. > The compiler collects all the information about the program, data, > structures, functions, etc., before it starts organising the data or > generating the code. That's the point of whole-program optimisation. Once again you are mistaken. > Yes, the compiler is free to re-order anything it likes - code, > functions, memory, structs, whatever - as long as the observable > behaviour is unchanged. Not according to 9.2.13. But you don't understand plain English. > But keep going, if you like - it is somewhat entertaining. The idea > that a modern C compiler is one-pass and generates the code for one line > of source before reading the next line gave me a bit of a chuckle. I understand completely how compilers work. I've worked on more of them than you have. And yes, they are one pass through the source code. The other passes are for optimization - which does NOT include reordering structs. But you don't understand standards. But then trolls like you never were very smart. And you just continue to dig yourself into deeper and deeper holes. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| jacob navia <jacob@jacob.remcomp.fr>: Sep 02 09:38PM +0200 Le 02/09/2016 à 13:44, Öö Tiib a écrit : > reference). Similarly if you want the operator to return value > then you have to type "<class T> operator T()" because > "<class T> operator T&()" does not return values. The implementation removes the references in the arguments but not on the return value. The return value is specified as a reference, not as a value, and THAT reference is NOT removed. Do I understand correctly? This provokes an error in the second line. This asymetric behavior is somehow surprising. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 02 09:35AM -0700 On Monday, August 29, 2016 at 9:39:50 PM UTC-4, Mr Flibble wrote: > 13: third -> 714 > Download (at own risk as not yet fully tested) from: > https://github.com/FlibbleMr/neolib What do you gain by this? Best regards, Rick C. Hodgin |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 02 05:56PM +0100 On 02/09/2016 17:35, Rick C. Hodgin wrote: >> Download (at own risk as not yet fully tested) from: >> https://github.com/FlibbleMr/neolib > What do you gain by this? If you have to ask that question then you probably don't need it. /Flibble |
| 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