- Bug in the C++ 2011 specifications - 6 Updates
- No more need for signals and slots! - 1 Update
| David Brown <david.brown@hesbynett.no>: Aug 13 05:28PM +0200 On 12/08/16 23:49, jacobnavia wrote: > C is VERY stable language, and software written in C stands the time > test. A C beautifier program is still running in the lcc-win IDE, code > written in the eighties. Yes, that is one of C's biggest strengths, and biggest weaknesses - it does not change (or does so only very little, and very slowly). C++, on the other hand, /does/ change - both the language, the standard library, and the tools. And again, that is both a strength and a weakness. That's why it's good to have both languages, suited to different purposes. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 13 06:51PM +0100 On 12/08/2016 23:40, Alf P. Steinbach wrote: >>> int main() { >>> f(S().n); >>> } [snip] > versions appears to be that this zero value can be regarded as a compile > time integer 0, a "constant expression" 0 in C++11, but not in C++03, > which has less smarts. Wrong. C++11 will not regard it as a compile time integer; if it does then your compiler has a bug. A C++11 compiler I just tried will output "X!" as it should. /Flibble |
| jacob navia <jacob@jacob.remcomp.fr>: Aug 14 12:44AM +0200 Le 13/08/2016 à 19:51, Mr Flibble a écrit : > then your compiler has a bug. A C++11 compiler I just tried will output > "X!" as it should. > /Flibble Not according to the developer in the clang team. His argument is that const expressions take priority here, and the 2011 version changes the behavior of the null constant since they are (apparently) propagated in priority. Now, since you do not name the compiler you are using I can't tell if the fact that you see some output is because you didn't specify std-c++ 2011 or not, or because other reasons. What is interesting in this discussion is that humans can only say: "Compiler xyz outputs this" and nobody understands the priorities anymore... This whole stuff is so complicated that all the human experts here are completely overwhelmed. You say that "X" is what it "SHOULD" output the compiler but you do not forward any explanation. Your "explanation" is that an unknown compiler outputs something! Is that because c++ is now only "readable" by a machine? The rules and their unforeseen interactions can't be followed by people anymore? I think that a reflection is needed by the users and the developer of this language to come to their senses before c++ will be definitely fucked up. Sorry but that is what this is leading to. A computer language that only a machine can fully understand. Humans are unable to parse 12 lines of C++ and all come to the same conclusion. In my message I tried to give A REASONING. Starting with the main function, I spelled out the rules that I think apply here and explained the steps one by one. If that is impossible for you, you are just begging my question. Where did I went wrong? Thanks for pointing me where I erred. And stop compiling that code. It is now the question if anyone here UNDERSTANDS what is written there and the actions the machine should perform. jacob |
| Ian Collins <ian-news@hotmail.com>: Aug 14 11:06AM +1200 On 08/14/16 10:44 AM, jacob navia wrote: > const expressions take priority here, and the 2011 version changes the > behavior of the null constant since they are (apparently) propagated in > priority. I agree with Flibble, the output should be "X!". So do all of the compilers on my boxes: $ cat > x.cc #include <iostream> struct S { int n; }; struct X { X(int) {} }; void f(void *) { std::cerr << "Pointer!\n"; } void f(X) { std::cerr << "X!\n"; } int main() { f(S().n); } clang++ -std=c++11 x.cc; ./a.out; clang++ --version X! clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin /opt/gcc5/bin/g++ x.cc -std=c++11; ./a.out; /opt/gcc5/bin/g++ --version X! g++ (GCC) 5.3.1 20151213 CC x.cc -std=c++11; ./a.out; CC -V X! CC: Studio 12.5 Sun C++ 5.14 SunOS_i386 2016/05/31 > apply here and explained the steps one by one. If that is impossible for > you, you are just begging my question. > Where did I went wrong? There isn't any ambiguity, the constructor for X is the only fit. If you change the constructor to be explicit (which it should be, no matter what version of C++ you use), the code won't compile no matter what version of C++ you specify. -- Ian |
| jacob navia <jacob@jacob.remcomp.fr>: Aug 14 01:20AM +0200 Le 14/08/2016 à 01:06, Ian Collins a écrit : > CC x.cc -std=c++11; ./a.out; CC -V > X! > CC: Studio 12.5 Sun C++ 5.14 SunOS_i386 2016/05/31 OK OK. And what happens when you put std-c++2003 or equivalent on clang? The thing is that (according to the clang developper) the behavior CHANGED. |
| Ian Collins <ian-news@hotmail.com>: Aug 14 11:24AM +1200 On 08/14/16 11:20 AM, jacob navia wrote: >> CC: Studio 12.5 Sun C++ 5.14 SunOS_i386 2016/05/31 > OK OK. And what happens when you put std-c++2003 or equivalent on clang? > The thing is that (according to the clang developper) the behavior CHANGED. clang++ -std=c++03 x.cc; ./a.out; clang++ --version X! clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) -- Ian |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 13 08:59PM +0100 Hi! My new GUI library "neoGFX" doesn't use signals and slots as signals and slots are an old solution to an old problem. Instead all we need to do is: button1.clicked([](){...}); If you need to unsubscribe from the event (which you should do if any objects associated with your event handler will be destroyed before the event source is destroyed) then simply use a "sink" object: sink s; s += button1.clicked([](){...}); Here when 's' is destroyed any associated event subscriptions will be unregistered automatically. A sink can be an object on the stack, a member variable or a base class. /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