- static constexpr with inner type doesn't compile - 3 Updates
- Read the following because it is important - 1 Update
- Std::any vs std::optional - 1 Update
- "+" and "-" for options set - 1 Update
- Forget about C++, C is not a low-level language either - 1 Update
- Forget about C++, C is not a low-level language either - 3 Updates
| Juha Nieminen <nospam@thanks.invalid>: May 24 09:16AM > initializer". Adding = {} to each makes it complain only about the last > one with ???constexpr Container::Test4::Test4()??? called in a constant > expression before its definition is complete". I wonder if gcc requiring the initializer (which clang doesn't) is also required by the standard, or whether it's just a interpretation by the developers of gcc. One would think that at the very least the struct having an explicit default constructor (ie. Test2) wouldn't require an explicit initialization, but apparently gcc thinks otherwise. As you note, both gcc and clang scoff at Test4 in particular, which is the only one that's inside the outer struct and has an explicit (albeit constexpr) constructor. Both compilers seem to be interpreting the strandard in the same way, so maybe it is so in the standard as well? But why? What exactly is the rule? |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 24 11:54AM +0200 On 24.05.2018 11:16, Juha Nieminen wrote: > an explicit (albeit constexpr) constructor. Both compilers seem > to be interpreting the strandard in the same way, so maybe it is > so in the standard as well? But why? What exactly is the rule? If it is specified by the standard it's probably about "user declared" constructor or not. Maybe tied in with notion of aggregates. Cheers!, - Alf |
| Tim Rentsch <txr@alumni.caltech.edu>: May 24 03:23PM -0700 > static constexpr Test4 object4; // Does not compile > }; > //------------------------------------------------------------ I don't know the answer to your question, but the following may shed some light on the subject. The code below struct Foo { struct Bas { constexpr Bas(){} }; // static constexpr Bas t1; // eh? // 1 // static constexpr Bas t2 = Bas(); // eh? // static constexpr Bas t3 = Bas{}; // eh? // static constexpr Bas t4 = {}; // eh? static constexpr Bas t5(); // static constexpr Bas t6{}; // eh? }; compiles without problems as C++11, C++14, and C++17, under both clang (5.0.0-3~16.04.1) and g++ (Ubuntu 5.4.0-6ubuntu1~16.04.9). If any of the lines marked "eh?" are uncommented, the code fails to compile in all versions. If the definition of struct Bas is moved outside of struct Foo, the code compiles in all cases, including uncommented all "eh?" lines, except that the first "eh?" line is accepted only with clang as C++17. Finding it difficult to give definitive answers to such seemingly simple questions is part of why I think C++ is too complicated. I'm surprised that the resident experts apparently aren't sure either. |
| Tim Rentsch <txr@alumni.caltech.edu>: May 24 02:45PM -0700 > It's not acceptable that *you* (and others who respond) cannot > control yourselves. Unlike the OP, you're not crazy. > Please killfile him. It's the only rational thing to do. I endorse Jorgen's suggested action. In case it needs saying, I bear no malice, just supporting what I think is a good suggestion. |
| Tim Rentsch <txr@alumni.caltech.edu>: May 24 02:35PM -0700 > https://www.reddit.com/r/cpp/comments/8ghtom/andrei_alexandrescu_expected_the_expected_cpp/ > Andrei Alexandrescu says he thinks std::optional is > the worst thing to happen to humanity. After looking at his talk, I think his reaction is based on std::optional not being a good fit for his use case. Apparently he doesn't understand that there are other use cases for which std::optional is just what the doctor ordered. |
| "Öö Tiib" <ootiib@hot.ee>: May 24 11:37AM -0700 On Wednesday, 23 May 2018 15:56:45 UTC+3, Alf P. Steinbach wrote: > A less verbose alternative could perhaps be to require a separate type, > maybe a boxing type, for each rôle of type's values? > Ideas? List of deviations from defaults can perhaps be passed to constructor of widget as initializer list parameter. Initializer lists are annoyingly loose but might work in such situation. Modern GUIs (mobile-app-ready) have gone complex. Designers of GUI expect CADs. There is always some sort of (hard to read and to merge to repo) resource script. About the few lucky cases where it has to be built with code (say for some nifty animation) no one cares how ugly the code looks. So ... don't worry. ;) |
| Real Troll <real.troll@trolls.com>: May 24 12:59PM -0400 On 24/05/2018 06:19, Paavo Helde wrote: > that Spectre, Meltdown et al have become possible because of the > desire to let the C programmers to continue to falsely believe they > are programming in a low-level language. I always thought since the college days that C, Fortran, and Pascal were high-level languages. So who would have thought that C programmers could be fooled to think that they are programming in a low level language. The rule of thumb is that any code that people can understand is considered to be high-level language. These include languages that use normal English terms and sentences. Me thinks so anyway. These languages can do almost anything these days for commercial use and not many people are writing compilers or operating systems so it doesn't matter whether they are using low-level or high-level. |
| Paavo Helde <myfirstname@osa.pri.ee>: May 24 08:19AM +0300 Stumbled upon an interesting article by by David Chisnall claiming that Spectre, Meltdown et al have become possible because of the desire to let the C programmers to continue to falsely believe they are programming in a low-level language. I think this is relevant to C++ as well as the discussed compiler optimizations machinery is the same and even more important in C++. https://queue.acm.org/detail.cfm?id=3212479 |
| scott@slp53.sl.home (Scott Lurndal): May 24 12:54PM >well as the discussed compiler optimizations machinery is the same and >even more important in C++. >https://queue.acm.org/detail.cfm?id=3212479 Spectre, Meltdown are simply microarchitectural bugs. Speculative execution should never cause detectable effects, particularly over privilege boundaries. |
| David Brown <david.brown@hesbynett.no>: May 24 03:40PM +0200 On 24/05/18 14:54, Scott Lurndal wrote: > Spectre, Meltdown are simply microarchitectural bugs. Speculative > execution should never cause detectable effects, particularly over > privilege boundaries. That's the theory. In practice, it's hard to avoid any possibility of cross-over. As long as you have a target of doing things as fast as you can, there will /always/ be timing attacks. The aim should /not/ be to eliminate detectable effects from speculative execution - the aim should be to reduce the signal, and increase the noise, until it becomes impractical to use as an attack vector. The same applies to other types of cache, other sources of timing differences, and any other kind of indirect information (cpu die temperature, power usage, etc.). Security is all about reducing the risk until it is no longer cost-effective to use that vulnerability - it is never about trying to eliminate the risk. For some cpus, these particular bugs are far too easy to exploit. By disallowing speculation across privilege boundaries, you greatly reduce the risk with only a small cost to performance. To get completely free of risk, however, you need to have deterministic memory - no speculation, no caches, etc. And that is not going to happen for general-purpose cpus. |
| 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