- two's complement idea - 4 Updates
- Template alias destructor call - 2 Updates
- C++ preprocessor and multi-line string literals - 1 Update
- transactional memory idea - 1 Update
| "Fred. Zwarts" <F.Zwarts@KVI.nl>: Jan 23 10:09AM +0100 Op 22.jan..2020 om 20:04 schreef Christian Gollwitzer: > error handling (because it lacks exceptions) - in C++ there is hardly a > good reason IMHO. > Christian Maybe to exit nested loops? I wonder why C++ does not have named loops, so that in a break it would be possible to specify which loop to exit. |
| boltar@nowhere.org: Jan 23 09:24AM On Thu, 23 Jan 2020 10:03:32 +1300 >> It is a better solution than exceptions for breaking out of a nested >> loop, usually. >Extracting the loop is better still! Good luck with that. |
| boltar@nowhere.org: Jan 23 09:29AM On Thu, 23 Jan 2020 10:09:15 +0100 >> Christian >Maybe to exit nested loops? I wonder why C++ does not have named loops, >so that in a break it would be possible to specify which loop to exit. That would be a much more useful addition to the language than the endless edge case rubbish (lambda capture initialisation, digit seperators, auto returns) and pointless STL classes and defs (optional, variant, byte, any, data()) that they've thrown in since 2011. |
| Ian Collins <ian-news@hotmail.com>: Jan 24 07:29AM +1300 >>> loop, usually. >> Extracting the loop is better still! > Good luck with that. Thank you. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 23 11:26AM +0100 On 22.01.2020 16:01, Paavo Helde wrote: > 1 error generated. > Who is right? And if clang, then how to write an explicit B<T> > destructor call without relying on how B<T> happens to be defined? C++17 §10.1.7.2/1 defines the /type-name/ after `~` as one of class-name enum-name typedef-name simple-template-id This suggests that no matter how /simple-template-id/ turns out a fix can be to use a /typedef-name/. §17.2/1 defines /simple-template-id/ as (transcribed to typewriter-ish) template-name `<` template-argument-list OPTIONAL `>` The question is then whether your template alias `B` is a /template-name/. The very same paragraph defines /template-name/ syntactically as identifier It then explains (in a non-normative note plus in normative text in paragraph 3) that it's the name lookup that determines if a name is a /template-name/. I fail to find that. However, §17.5.7 states that An alias template is a name for a family of types. The name of the alias template is a /template-name/. So this is a bug in dang. Workaround probably as mentioned above. - Alf |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 23 01:09PM +0200 On 23.01.2020 12:26, Alf P. Steinbach wrote: > alias template is a /template-name/. > So this is a bug in dang. > Workaround probably as mentioned above. Thanks! The typedef workaround indeed seems to work: template <typename T> void foo(B<T>* x) { typedef B<T> B_t; x->~B_t(); } |
| boltar@nowhere.org: Jan 23 09:22AM On Wed, 22 Jan 2020 10:50:41 -0800 (PST) >> Oh do go fuck yourself you patronising little tit. >You think that vulgar language makes you to look more >immature and so fits better with being a rookie? :D Says the man sitting in his baltic igloo who never posts anything useful, just trolls others. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 22 04:37PM -0800 On 1/17/2020 3:49 PM, Chris M. Thomasson wrote: > caring about any transaction. However, the writers use the transactions > when they mutate the data-structure. The readers are totally free, the > writers are not. I say this because I have had to deal with several transaction systems where a simple read of an in-flight transaction would abort! This can happen in STM, or even in hardware wrt the reservation granule of a LL/SC. I used RCU for the readers, and let the writers deal with the damn transactions. seqlock version numbers are helpful as well... |
| 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