- Making std::list::size() O(1) is a mistake - 1 Update
- Upcoming presentations on asynchronous network programming - 7 Updates
- Copy constructor with non-const argument - 2 Updates
- Stored in Big Endian. . . . . . inside Little Endian - 3 Updates
| Mr Flibble <flibble@reddwarf.jmc.corp>: Feb 16 08:54PM Hi! Making std::list::size() O(1) is a mistake as it breaks std::list::splice; instead it should be amortized O(1) using, perhaps, mutable std::optional<std::size_t> for size or such. Some say nobody cares that I think making std::list::size() O(1) is a mistake but I am sure others agree with me: the whole point of using std::list::splice is the performance benefit of manipulating linked lists. /Flibble |
| Muttley@dastardlyhq.com: Feb 16 09:12AM On Wed, 15 Feb 2023 20:54:39 -0000 (UTC) >- Getting Started with Boost.Asio: Timers and Serial Ports (March) >- TCP/IP Networking with Boost.Asio (April) >- Basic HTTP and WebSocket Programming with Boost.Beast (May) Boost? *gag* Who uses it now anyway given C++17 does everything useful that it used to do bar a few specialised maths algos? Plus the standard C sockets API is fairly simple so why you'd need it wrapped up in that outdated library is anyones guess. Whatever happened to the ACE library? >- C++ Promises/A+ library in the Javascript style (June) Javascript style? You've got to be f*cking kidding. |
| Paavo Helde <eesnimi@osa.pri.ee>: Feb 16 11:52AM +0200 >> - Basic HTTP and WebSocket Programming with Boost.Beast (May) > Boost? *gag* Who uses it now anyway given C++17 does everything useful that > it used to do bar a few specialised maths algos? Is this a trick question? From where exactly do you think major portions of enhancements to the C++ standards have come over the last 20 years? C++17 *is* halfway Boost, even when renamed std::. To answer the obvious, one currently uses Boost libraries when one needs the functionality and the particular library is not yet included in C++ standards. Like Boost.asio. > Plus the standard C sockets API is fairly simple so why you'd need it wrapped > up in that outdated library is anyones guess. Please code up a scalable, portable, TLS-capable HTTP server in C++ without using any third-party libraries, then come back again. We might be still here. About "outdated": the last version of boost came out exactly 2 months ago, including 37 listed enhancements and fixes in Boost.asio. > Whatever happened to the ACE library? Whatever that is, it seems to be not included in C++ standards either. |
| Muttley@dastardlyhq.com: Feb 16 10:07AM On Thu, 16 Feb 2023 11:52:03 +0200 >Is this a trick question? From where exactly do you think major portions >of enhancements to the C++ standards have come over the last 20 years? >C++17 *is* halfway Boost, even when renamed std::. I know. C++ took the good bits and left the junk behind. Also when something is built into the language rather than being a load of hacky macros mixed with playing silly buggers with the template system it tends to work a lot better. >To answer the obvious, one currently uses Boost libraries when one needs >the functionality and the particular library is not yet included in C++ >standards. Like Boost.asio. Why does it need to be in C++ when theres the O_NONBOCK & O_ASYNC sockets flag not to mention select() and poll()? >Please code up a scalable, portable, TLS-capable HTTP server in C++ >without using any third-party libraries, then come back again. We might >be still here. I don't have a problem with 3rd party libraries, I have a problem with Boost. For HTTP any sane person would use Curl though frankly openSSL is fairly simple to use and basic HTTP is easy to implement - I've done it. >ago, including 37 listed enhancements and fixes in Boost.asio. >> Whatever happened to the ACE library? >Whatever that is, it seems to be not included in C++ standards either. It was a C++ networking (and a few other things) library that was briefly popular in the 2000s. But it had little advantage over just using the sockets API directly. |
| Paavo Helde <eesnimi@osa.pri.ee>: Feb 16 12:33PM +0200 > openSSL is fairly simple to use I see. I currently have a task to encode Diffie-Hellman parameter generation with openssl library calls (as opposed to the command-line). I'm sure it's simple if one knows how to do it, which I unfortunately don't. |
| Muttley@dastardlyhq.com: Feb 16 04:21PM On Thu, 16 Feb 2023 12:33:31 +0200 >I see. I currently have a task to encode Diffie-Hellman parameter >generation with openssl library calls (as opposed to the command-line). >I'm sure it's simple if one knows how to do it, which I unfortunately don't. Most people use it as a higher level sockets library but whatever floats your boat. |
| scott@slp53.sl.home (Scott Lurndal): Feb 16 04:58PM >>I'm sure it's simple if one knows how to do it, which I unfortunately don't. >Most people use it as a higher level sockets library but whatever floats >your boat. I would disagree with that charactization. Pretty much every time I've used openssl over the last two decades has been for access to the crypto functionality (and the fact that openssl can be configured to off-load to crypto hardware if available is a bonus), not for Transport Level Security. |
| Muttley@dastardlyhq.com: Feb 16 05:06PM On Thu, 16 Feb 2023 16:58:12 GMT >crypto functionality (and the fact that openssl can be configured >to off-load to crypto hardware if available is a bonus), not for Transport >Level Security. I suspect your use case is rather uncommon. |
| Joseph Hesse <joeh@gmail.com>: Feb 16 09:34AM -0600 If a non-const argument is given for a copy constructor, with a non-empty body, does the code in the body execute first or is the initialization first? In the following example the code in the body executes first. Is this always the case? Thank you, Joe #include <iostream> class X { public: X(int u = 0) : x(u) {} X(X &rhs) : x(rhs.x) { x += 2; } // non-const argument for copy constructor int getx() const { return x; } private: int x; }; int main() { X x1(5); X x2(x1); std::cout << x2.getx() << '\n'; // g++ and clang++ output 7 } |
| Markus Schaaf <mschaaf@elaboris.de>: Feb 16 05:11PM +0100 Am 16.02.23 um 16:34 schrieb Joseph Hesse: > If a non-const argument is given for a copy constructor, with a > non-empty body, does the code in the body execute first or is the > initialization first? First initialization, then body. > In the following example the code in the body > executes first. No. > X x2(x1); > std::cout << x2.getx() << '\n'; // g++ and clang++ output 7 > } Of course. `X x1(5)` calls `X::X(int)`, which initializes `x1.x` to 5. Then `X x2(x1);` calls `X::X(X&)`, which initializes `x2.x` to 5, and then adds 2. BR |
| Richard Damon <Richard@Damon-Family.org>: Feb 15 07:53PM -0500 On 2/15/23 12:38 PM, Vir Campestris wrote: > you expected it. I'd expect to be able to make a union with unsigned > char[4] and see the data correctly - and this mapping does that. > Andy And I would expect that the description of the data being stored in an "unsigned long" within the packet structure is likely incorrect, and an anacronism to when long was a synonym for a 32 bit number. The packet structure likely actually matches how the bytes are presented on the wire, and thus the IP address is stored in a 4 byte unsigned value. Of course putting it into an unsigned long when outside the packet structure works, but just wastes some memory. This documentation predates the creation of uint32_t, which is likely what would be used if it was decided to rewrite the documentation today. Of course, the short/long <-> s/l in the function names becomes a bit of disconnect at that point. |
| scott@slp53.sl.home (Scott Lurndal): Feb 16 03:07AM >structure works, but just wastes some memory. >This documentation predates the creation of uint32_t, which is likely >what would be used if it was decided to rewrite the documentation today. I think that would be very unlikely. IPv4 addresses aren't (and never were) the only form of network endpoint addressing on ethernet or any other transport (IPv6, X.25, BNA, SNA, DECnet, UDS). Since bind(2) can bind to IPv4, IPv6 and unix domain socket addresses, the address field by its very nature must be variable length. |
| Richard Damon <Richard@Damon-Family.org>: Feb 15 10:35PM -0500 On 2/15/23 10:07 PM, Scott Lurndal wrote: > transport (IPv6, X.25, BNA, SNA, DECnet, UDS). Since bind(2) can bind > to IPv4, IPv6 and unix domain socket addresses, the address field by its very > nature must be variable length. But the OP is talking about looking into the structure format that is specifically IPv4. (sockaddr_in). Yes, a generic sockaddr structure needs to store all sorts of stuff for all types of interfaces, and if I understand it right, stores IPv4 addreess like they are stored in sockaddr_in. |
| 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