- explicit specialization problem - 16 Updates
- Wading through template instantiation errors for allocator - 4 Updates
- Union type punning in C++ - 2 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 08 07:29AM +0100 >> }; > The `template<>` does not make sense here. > Just remove that line. Thanks. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 07 10:34PM -0800 On 1/7/2020 10:29 PM, Bonita Montero wrote: >> The `template<>` does not make sense here. >> Just remove that line. > Thanks. Your code works for me wrt removing the extra 'template<>'. Actually, in gcc in default, it works as is. I get an output of: void Lib<My<T>>::f() |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 08 07:46AM +0100 > Your code works for me wrt removing the extra 'template<>'. > Actually, in gcc in default, it works as is. I get an output of: > void Lib<My<T>>::f() I think the template<> makes sense because in this case I have also a template<>: template<typename T> struct S { }; template<> struct S<int> { }; When it would be up to Alf I would have to write only: struct S<int> { }; ... which doesn't work. |
| "Öö Tiib" <ootiib@hot.ee>: Jan 07 10:58PM -0800 On Wednesday, 8 January 2020 08:46:55 UTC+2, Bonita Montero wrote: > { > }; > ... which doesn't work. You had: template<> template<typename T> |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 08 10:36AM +0100 > You had: > template<> > template<typename T> Yes, but makes also sense and it is accepted by g++. |
| "Öö Tiib" <ootiib@hot.ee>: Jan 08 03:56AM -0800 On Wednesday, 8 January 2020 11:36:49 UTC+2, Bonita Montero wrote: > > template<> > > template<typename T> > Yes, but makes also sense and it is accepted by g++. It does not make sense in that context but lot of code that does not make sense and even violates some rules is (often incorrectly) accepted without any diagnostic by one or other compiler. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 08 01:00PM +0100 >>> template<typename T> >> Yes, but makes also sense and it is accepted by g++. > It does not make sense in that context ... And why does g++ accept this ? |
| "Öö Tiib" <ootiib@hot.ee>: Jan 08 06:02AM -0800 On Wednesday, 8 January 2020 14:00:36 UTC+2, Bonita Montero wrote: > >>> template<typename T> > >> Yes, but makes also sense and it is accepted by g++. > > It does not make sense in that context ... Restoiring: "but lot of code that does not make sense and even violates some rules is (often incorrectly) accepted without any diagnostic by one or other compiler." > And why does g++ accept this ? Because the part that you snipped that I restored above. Can't you read more than 6 words? |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 08 03:15PM +0100 > "but lot of code that does not make sense and even violates some > rules is (often incorrectly) accepted without any diagnostic by > one or other compiler." If you have a template-specialization of a class that implements all template-parameters it is headed with "template<>". |
| "Öö Tiib" <ootiib@hot.ee>: Jan 08 06:48AM -0800 On Wednesday, 8 January 2020 16:15:20 UTC+2, Bonita Montero wrote: > > one or other compiler." > If you have a template-specialization of a class that implements > all template-parameters it is headed with "template<>". But not with "template<> template<typename T>" |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 08 03:53PM +0100 Am 08.01.2020 um 15:48 schrieb Öö Tiib: >> If you have a template-specialization of a class that implements >> all template-parameters it is headed with "template<>". > But not with "template<> template<typename T>" No, that's not related to the specialization-part. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 08 03:00PM >>> Yes, but makes also sense and it is accepted by g++. >> It does not make sense in that context ... > And why does g++ accept this ? It's not accepted by recent gcc versions (8.x and above). -- Ben. |
| Ian Collins <ian-news@hotmail.com>: Jan 08 10:26AM +1300 On 07/01/2020 23:26, Bonita Montero wrote: > x.cpp(30): note: see declaration of 'Lib<My<T>>' > x.cpp(31): error C2447: '{': missing function header (old-style formal > list?) Use a more friendly compiler... $ clang++ -std=c++17 /tmp/x.cc /tmp/x.cc:22:1: warning: extraneous template parameter list in template specialization template<> ^~~~~~~~~~ -- Ian. |
| "Öö Tiib" <ootiib@hot.ee>: Jan 08 07:16AM -0800 On Wednesday, 8 January 2020 16:53:17 UTC+2, Bonita Montero wrote: > >> all template-parameters it is headed with "template<>". > > But not with "template<> template<typename T>" > No, that's not related to the specialization-part. Fixed g++ also complains about too large count of template parameter lists: http://coliru.stacked-crooked.com/a/417e954f5e129b64 So whatever you tried to tell with that code does not make sense to it as well. |
| Manfred <noname@add.invalid>: Jan 08 04:28PM +0100 On 1/8/2020 3:53 PM, Bonita Montero wrote: >>> all template-parameters it is headed with "template<>". >> But not with "template<> template<typename T>" > No, that's not related to the specialization-part. After restoring proper (rudely removed) attributions, Alf P. Steinbach wrote: >> void f(); >> }; > The `template<>` does not make sense here. It is clearly related to specialization. Ref: template<typename T> struct S { }; template<typename T> struct S<T*> { }; |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 08 02:44PM -0800 On 1/8/2020 7:00 AM, Ben Bacarisse wrote: >>> It does not make sense in that context ... >> And why does g++ accept this ? > It's not accepted by recent gcc versions (8.x and above). Fwiw, still working with: g++.exe (Rev1, Built by MSYS2 project) 7.3.0 In Clang 7.0.0-3 I get: main.cpp:22:1: warning: extraneous template parameter list in template specialization |
| boltar@nowhere.org: Jan 08 10:12AM On Tue, 7 Jan 2020 21:15:32 +1300 >On 04/01/2020 04:04, Frederick Gotham wrote: >> auto main(void) -> int >What kind of an abomination is this? Its for developers who like to show off: "Look at me, I'm using unnecessarily complex syntax for no good reason - I must truly be l33t!" Anyone who wrote that sort of crap in an interview test for me would have their CV shown the bin the minute they left. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jan 08 09:22AM -0800 > On 04/01/2020 04:04, Frederick Gotham wrote: >> auto main(void) -> int > What kind of an abomination is this? There are some advantages to trailing return types (introduced in C++11) particularly for function templates where the return type depends on the argument types. If C++ were being designed from scratch today, I suspect that they would be the only syntax accepted, with the leading "auto" omitted. Other than historical baggage, there's no good reason to have two different syntax for return types. Some have argued that we should use trailing return types consistently in new code. Others would argue that we shouldn't use them in cases where they offer no specific advantages, simply because they're unfamiliar. I tend to fall into the latter camp, but I can imagine changing my mind eventually. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com [Note updated email address] Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jan 08 05:44PM > depends on the argument types. > If C++ were being designed from scratch today, I suspect that they > would be the only syntax accepted, with the leading "auto" omitted. Or fun fn func etc... -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 08 11:00PM +0100 On 08.01.2020 18:22, Keith Thompson wrote: > depends on the argument types. > If C++ were being designed from scratch today, I suspect that they > would be the only syntax accepted, with the leading "auto" omitted. "Implicit auto" for the win! Then, in an even later version of C++ that will be deprecated and one will be required to spell out Unicode `ℱ` (capital script F). > use them in cases where they offer no specific advantages, simply > because they're unfamiliar. I tend to fall into the latter camp, > but I can imagine changing my mind eventually. - Alf |
| Daniel <danielaparker@gmail.com>: Jan 08 09:40AM -0800 On Thursday, January 2, 2020 at 1:26:46 PM UTC-5, Öö Tiib wrote: > instead of other ways of type punning tends to generate better or > same codes. It is hard to find examples where other methods are > really beneficial. Does that observation apply to, eg. bit casting uint8_t v[8000000] to float[1000000] (which is a typical case in deserialization of typed arrays when endiness lines up.) Thanks, Daniel |
| "Öö Tiib" <ootiib@hot.ee>: Jan 08 01:23PM -0800 On Wednesday, 8 January 2020 19:41:11 UTC+2, Daniel wrote: > Does that observation apply to, eg. bit casting > uint8_t v[8000000] to float[1000000] > (which is a typical case in deserialization of typed arrays when endiness lines up.) Note that bytes are special since memory consists of those. It is not type punning to convert between POD object and its bytes. Otherwise memcpy itself would be wrong. With "type punning" things like converting between IEEE double and uint64_t are usually meant. However when we deserialize then we typically get those bytes from somewhere as smaller packets. For example Ethernet packet is 1500 bytes + 26 bytes of header and there are usually other garbage by protocol so for floats there is less than 1500 bytes. Then we memcpy from there into our floats. I can't even imagine how you suggest to use union there instead. Can you? |
| 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