| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 09 07:39AM On Fri, 2018-06-08, Öö Tiib wrote: >> Also compare with how Boost.Asio wraps getaddrinfo(). (I'm not sure I >> like it 100%, though.) > When we like something 80% then it is probably quite good. ;) I had roughly this problem with it in one project: there are socket options you must set after creating the socket, but before connect() (I needed TCP connect() to give up early, not after a minute or more of attempts). The async API for this bundled everything from getaddrinfo() to connect(), with no hooks for me to set the options, so I had to reimplement much of it. That left me with the feeling that that particular part of the API hadn't been used much for serious work. (They may have fixed that by now though; this was ~2 years ago.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Öö Tiib" <ootiib@hot.ee>: Jun 09 06:22AM -0700 On Saturday, 9 June 2018 10:39:40 UTC+3, Jorgen Grahn wrote: > That left me with the feeling that that particular part of the API > hadn't been used much for serious work. (They may have fixed that by > now though; this was ~2 years ago.) I have worked with it rarely but it feels to me pretty straightforward. So we can have asio socket: asio::ip::tcp::socket the_socket; Then we can call things like the_socket.open() or the_socket.bind() and the like. To get native socket there is method native(). SOCKET n_socket = the_socket.native(); With it can be done platform-specific things like option changes before connect(): int result = SOCKET_ERROR; if (INVALID_SOCKET != n_socket) { result = ::setsockopt(n_socket, SOL_SOCKET, blah blah SO_RCVTIMEO); } If there are multiple platforms to support then such function can be moved to platform-specific unit and linked in depending on platform. Sure, if it was couple of years back then you do not remember the details, but to me it seemed OK more or less. So at least 80% "like" from me. ;) |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 09 07:10PM +0200 >> [snip code] > 0. 1st, I don't know window stuff, can't compile and test (this code > seems to be your implements), Ideally you just need to replace Winsock2 headers with your system's sockets implementation, and re-implement the little Library_envelope class that initializes and cleans up Winsock2, for your implementation. Disclaimer: I haven't tried it. > and the newer C++ key word auto and > syntax, the trailing "->int" seems to be a hint of the type of auto > So, try to understand as I can There's not much to understand, it's just notation that for this code maps directly (mechanically, one to one) to C++03 notation. The modern C++ notation is much like Rust and like math notation. But I don't think either notation has any strong advantage for this particular concrete code. > 1. catch( exception const& x ) { > }; // older compiler has to end with ';'. I didn't try newer compilers A semicolon there has never been a requirement in standard C++, and as I recall not in ARM C++ before the first standard, either. Throw that compiler on the fire. > 2. Quite some codes are dedicated for implementing iterator which I had > decided not to use (reason?...) You can directly reuse that code (perhaps more properly beefed up for reuse), by just moving it to a header. I put everything in a single file so that it would be easy to check out. > probably that's something I should learn, but exposing it to public > interface is questionalbe to me, now. (probably fine, template > may encounter problems using POD pointer or reference plus const) In my view, `ptr_<T>` is more direct and readable than `T*`. The latter can be more easily recognized, yes, but leads to undecipherable declarations like those for signal handlers, and needs to be learned. Re the "needs to be learned" of stars: I first encountered the star notation in SPL on the HP3000. I didn't understand it then. Now I'm pretty sure it must have been just about the same as in C. If instead the SPL notation had been ptr_, or like that, then I would most likely have understood it because it's self-describing. > 4. A basic goal of Wy::AddrInfo (the library in general) is to avoid > modification of the source wrapper from the underlying things that > can change over time Sorry, I don't understand that. Can you give an example? > 5. getaddrinfo(2) uses different set of return value and meaning. Sorry, I don't understand that either. The docs I found for *nix systems: <url: https://linux.die.net/man/3/getaddrinfo> Are you referring to a different function? > Wy::AddrInfoList alst; > hints.set_socktype(SOCK_STREAM); > hints.set_family(AF_UNSPEC); I don't see any problem with providing the hinting functionality, that's just adding an argument. > [snip more code] > I was seeking for suggestions and idea. All the above are just my > thoughts of the moment, no criticism intended. Communication is IMHO good. That's what Usenet groups and now to some degree Reddit, are about. With communication we can learn, and we can get corrected, and we can get an idea of what other folks think. Generally, on Usenet and to a large degree still on Reddit, you're expected to provide feedback and generally say what you mean and provide what facts you know, which is a positive thing. On Reddit some users (kids? manipulative?) will downvote any corrective communication as perceived negativity, maybe like ooh you're not friendly-friendly, go away. On Stack Overflow which is even more of a social site that [correction or disagreement = negative social signal] reaction is the norm, plus the SO mods are likely to remove critical context from the comment flow, and some times, though rarely, even from the comments themselves, plus you can't in general back up your comments with code examples because you can't have formatted code in SO comments. Plus there's not a comment hierarchy, just linear. Plus no support for quoting in comments. And so on; it's designed to stifle any debate. Plus you can be suspended for mentioning competence. I think that's my current situation, a comment about please don't use mod tools until competent to do so, but the mods are very tight-lipped about it except that in their view I've been more "rude" again. Happily there's no need to assume the silly SO authoritarianism and herd behavior on Usenet. Cheers!, - Alf |
| 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