- Union type punning in C++ - 4 Updates
- explicit specialization problem - 5 Updates
- How to overload get<>() ? - 2 Updates
- Tap the shoulder of the person moderating the Boost dev list - 10 Updates
| Daniel <danielaparker@gmail.com>: Jan 08 10:41PM -0800 On Wednesday, January 8, 2020 at 4:24:03 PM UTC-5, Öö Tiib wrote: > 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? No :-) Daniel |
| Daniel <danielaparker@gmail.com>: Jan 08 10:52PM -0800 On Wednesday, January 8, 2020 at 4:24:03 PM UTC-5, Öö Tiib wrote: > 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. But if the last item in the packet is half a float, do you still memcpy directly into floats? Daniel |
| "Öö Tiib" <ootiib@hot.ee>: Jan 09 12:59PM -0800 On Thursday, 9 January 2020 08:52:31 UTC+2, Daniel wrote: > > Then we memcpy from there into our floats. > But if the last item in the packet is half a float, do you still memcpy > directly into floats? What you mean by "half a float"? Half-received? If half-received then may be yes, may be no. Hard to tell without context. For example if program needs to process received floats even without all received then I probably would not copy half-floats. But if it may refuse to work until all floats are received then I probably would copy half but would throw after timeout destroying all the received floats and not processing anyway. |
| Daniel <danielaparker@gmail.com>: Jan 09 01:32PM -0800 On Thursday, January 9, 2020 at 3:59:40 PM UTC-5, Öö Tiib wrote: > What you mean by "half a float"? Half-received? Half-received > But if it may refuse to work until all floats are received then > I probably would copy half but would throw after timeout > destroying all the received floats and not processing anyway. Fair enough. Daniel |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 09 02:20AM >> 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 Not sure what you mean by "working". I just tried gcc.Godbolt.org and the oldest version that rejects the code is 8.1. -- Ben. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 08 07:42PM -0800 On 1/8/2020 6:20 PM, Ben Bacarisse wrote: >> Fwiw, still working with: >> g++.exe (Rev1, Built by MSYS2 project) 7.3.0 > Not sure what you mean by "working". Compiling, and generating an executable. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 09 06:17PM >>> g++.exe (Rev1, Built by MSYS2 project) 7.3.0 >> Not sure what you mean by "working". > Compiling, and generating an executable. I see. That's what I said, though I gave more a general answer. Your word "still" suggested you weren't simply give an example of what I'd said. -- Ben. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 09 07:40PM On Thu, 2020-01-09, Ben Bacarisse wrote: > I see. That's what I said, though I gave more a general answer. Your > word "still" suggested you weren't simply give an example of what I'd > said. I think what really happened was, when you wrote "not accepted by recent gcc versions (8.x and above)" you had an implicit "but accepted in 7.x" and Chris thought you implied "... and I don't know when it stopped being accepted". /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 09 09:21PM > recent gcc versions (8.x and above)" you had an implicit "but accepted > in 7.x" and Chris thought you implied "... and I don't know when it > stopped being accepted". Oh yes. That's likely how it was read. Thanks. Anyway, not disagreement exists about the facts! -- Ben. |
| boltar@nowhere.org: Jan 09 09:37AM Morning Is there a way to overload get so that when used on a user defined class it will return values defined by the user , not simple an index value? Or to put it another way, what do standard classes like tuple have to implement in order for get<>() to work with them? eg: struct myclass { blah b; int i; string s; : : }; cout << get<0>(obj); <- How would I make this return string s for example? |
| "Öö Tiib" <ootiib@hot.ee>: Jan 09 12:42PM -0800 > : > }; > cout << get<0>(obj); <- How would I make this return string s for example? The std::tuple is variadic template and so its elements are enumerated during its generation. For such stinky myclass it is most trivial to make those manually. Random attempt of mine for example: #include <iostream> // for cout and endl using blah = double; // to make stinky myclass to compile using string = void*; // to make stinky myclass to compile struct myclass { blah b; int i; string s; // : <- stinky syntax error commented out // : <- same here template<int> auto get(); }; template<> auto myclass::get<0>() {return b;} template<> auto myclass::get<1>() {return i;} template<> auto myclass::get<2>() {return s;} int main() { myclass m {42.42, 42, nullptr}; std::cout << m.get<0>() << " " << m.get<1>() << " " << m.get<2>() << std::endl; } Seems to work on online compiler. <http://coliru.stacked-crooked.com/a/bab622316924d788> |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Jan 08 11:49PM -0800 I posted my idea for a "static allocator" to the Boost dev mailing list 2 days ago. It's a moderated list and so I'd expect a delay in my posts showing up. Not two days though. If any of you know who is moderating the Boost dev list, could you please tap them on the shoulder. There was a long delay when I posted by last idea too for a limited input iterator. (Also unrelatedly I posted to comp.std.c++ two days ago to tell them to put __COUNTER__ in the standard but again it hasn't shown up yet -- so if anyone knows that moderator then please tap them on the shoulder) |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 09 12:08PM +0100 On 09.01.2020 08:49, Frederick Gotham wrote: > I posted my idea for a "static allocator" to the Boost dev mailing list 2 days ago. It's a moderated list and so I'd expect a delay in my posts showing up. Not two days though. > If any of you know who is moderating the Boost dev list, could you please tap them on the shoulder. He's not the maintainer, but in the worst case where this continues contact Dave Abrahams, one of the two original founders of Boost. > There was a long delay when I posted by last idea too for a limited input iterator. > (Also unrelatedly I posted to comp.std.c++ two days ago to tell them to put __COUNTER__ in the standard but again it hasn't shown up yet -- so if anyone knows that moderator then please tap them on the shoulder) comp.std.c++ is long dead. After that the discussion moved to a couple of Google Group groups. Now, a few months ago, it's moved again, to a couple of mailing lists. See <url: https://isocpp.org> for details. - Alf |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Jan 09 04:24AM -0800 On Thursday, January 9, 2020 at 11:09:11 AM UTC, Alf P. Steinbach wrote: > He's not the maintainer, but in the worst case where this continues > contact Dave Abrahams, one of the two original founders of Boost. I fired an email to David, Beman and Nicolai. > comp.std.c++ is long dead. Nostalgic anecdote: I remember when I was teenager posting to that group as I found an error in the 1998 Standard. > After that the discussion moved to a couple of Google Group groups. > Now, a few months ago, it's moved again, to a couple of mailing lists. > See <url: https://isocpp.org> for details. I'll take a look. Also I think two of three guys named above are on the Standards Committee. The preprocessor macros __COUNTER__ should really be in the standard. |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 09 03:01PM +0200 On 9.01.2020 14:24, Frederick Gotham wrote: > The preprocessor macros __COUNTER__ should really be in the standard. If __COUNTER__ is used in header files, then it might easily produce different values for the same usage point if headers are included in a different order in different compilation units. This in turn may easily violate ODR rules and produce other nasty bugs. This is especially relevant for C++ where the tendency is to put yet more and more stuff in the header files. I believe we don't need yet another readily abusable misfeature in C++. |
| David Brown <david.brown@hesbynett.no>: Jan 09 02:28PM +0100 On 09/01/2020 14:01, Paavo Helde wrote: > relevant for C++ where the tendency is to put yet more and more stuff in > the header files. > I believe we don't need yet another readily abusable misfeature in C++. Lots of features can be abused as well as used. __COUNTER__ can be useful when you want an identifier within a macro that must be different from any other identifier each time the macro is invoked. But you should never depend on what the actual value is. An example of where I have used it is for a "static_assert" macro for pre-C11 or pre-C++11. Clearly this is no longer needed for modern language standards, but it is very useful for C99 coding: #define STATIC_ASSERT_NAME_(count) STATIC_ASSERT_NAME2_(count) #define STATIC_ASSERT_NAME2_(count) assertion_failed_at_line_##count #define static_assert(claim, warning) \ typedef struct { \ char STATIC_ASSERT_NAME_(__COUNTER__) [(claim) ? 1 : -1]; \ } STATIC_ASSERT_NAME_(__COUNTER__) This lets you write, for example: static_assert(sizeof(int) == 4, "Code assumes 4-byte int"); You can put it outside or inside functions, and no code is generated and no code is wasted. The alternative to __COUNTER__ is __LINE__. I used to use that, but if you coincidentally have static_assert's at the same line number in two headers (or a header and the C or C++ file) used in the same compilation, you get a collision. __COUNTER__ avoids that. Does this mean it would be nice to see __COUNTER__ standardised? Well, there would be no point in doing it for this use-case. Maybe there are other use-cases that benefit from it, where there are similar advantages over __LINE__. I don't think there are many new possibilities for errors or bad code that it would open up, compared to using the current standard alternative of __LINE__. (I have no idea what use Frederick has for __COUNTER__.) |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 09 01:52PM On Thu, 2020-01-09, David Brown wrote: >>> The preprocessor macros __COUNTER__ should really be in the standard. >> If __COUNTER__ is used in header files, then it might easily produce >> different values for the same usage point if headers are included in a ... > (I have no idea what use Frederick has for __COUNTER__.) Presumably his proposal makes that clear; maybe he can repost it here? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 09 03:55PM +0200 On 9.01.2020 15:28, David Brown wrote: > } STATIC_ASSERT_NAME_(__COUNTER__) > This lets you write, for example: > static_assert(sizeof(int) == 4, "Code assumes 4-byte int"); If you have this inside an inlined function in an header, then you already may have violated the ODR if the inline function definition happens to not consist of the same sequence of tokens in all TU-s. Most probably the program still behaves as you would expect, but formally you have UB. |
| David Brown <david.brown@hesbynett.no>: Jan 09 03:09PM +0100 On 09/01/2020 14:55, Paavo Helde wrote: > happens to not consist of the same sequence of tokens in all TU-s. > Most probably the program still behaves as you would expect, but > formally you have UB. Good point. As the declared struct is never used, it is unlikely to have any effect - but you are right that it would technically be UB (unless, of course, __COUNTER__ happens to match in all cases where the function is declared). Another reason to use C11 or C++11 or greater! |
| Cholo Lennon <chololennon@hotmail.com>: Jan 09 01:25PM -0300 On 9/1/20 04:49, Frederick Gotham wrote: > If any of you know who is moderating the Boost dev list, could you please tap them on the shoulder. > There was a long delay when I posted by last idea too for a limited input iterator. > (Also unrelatedly I posted to comp.std.c++ two days ago to tell them to put __COUNTER__ in the standard but again it hasn't shown up yet -- so if anyone knows that moderator then please tap them on the shoulder) If you use slack, workspace "Cpplang" (cpplang.slack.com), channels "boost" (or "general"), for sure you will get some kind of answer. -- Cholo Lennon Bs.As. ARG |
| Manfred <noname@add.invalid>: Jan 09 07:48PM +0100 On 1/9/2020 2:01 PM, Paavo Helde wrote: > relevant for C++ where the tendency is to put yet more and more stuff in > the header files. > I believe we don't need yet another readily abusable misfeature in C++. Agreed. 1) It is a (predefined) macro. Wherever macros are going, C++ is going the other way. 2) The way I see it, it may be useful mostly for debugging or early development. So not really needed to release products. |
| 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