- comp.lang.c++.moderated status - 7 Updates
- [oft] from blocking to nonblocking server - 4 Updates
- "C++17 Is Now Official" - 9 Updates
- Visual Studio is not really comparable to C++ Builder - 2 Updates
- Sequencing of "<<" - 2 Updates
- Here is more information about me.. - 1 Update
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Dec 07 08:08AM +0100 On 07.12.17 00.20, Richard wrote: > FYI, I am working with Daveed Vandevoorde to revive moderation of > comp.lang.c++.moderated so we can all get away from the spam and the > trolls. Hopefully we can get moderation back online by January, 2018. From my experience the latency of moderated groups is more bothersome than the junk posts that can be mostly filtered by blacklists. In fact a common, /moderated filter list/ would be significantly more effective. Too bad that there is no standard for that. Marcel |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 06 11:11PM -0800 On Thursday, December 7, 2017 at 2:08:31 AM UTC-5, Marcel Mueller wrote: > than the junk posts that can be mostly filtered by blacklists. In fact a > common, /moderated filter list/ would be significantly more effective. > Too bad that there is no standard for that. A while back I proposed us writing an add-on to Thunderbird which would allow connection to a central database whereby individual posts could be flagged as spam, as well as users, and then they would either not appear in Thunderbird, or they would be shown only in a special folder. We are software developers. Such things are within our grasp. -- Rick C. Hodgin |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 07 10:58AM On Wed, 6 Dec 2017 23:11:44 -0800 (PST) > would either not appear in Thunderbird, or they would be shown > only in a special folder. > We are software developers. Such things are within our grasp. Assuming you are the real Rick Hodgin, you have got one hell of a nerve. The irony of your posting, and your own lack of self-knowledge, is extraordinary. When you have written the software to which you refer, you could call it the "Rick Hodgin spam filter" and pass into history as being like the Oracle of Delphi: the only oracle (as far as I am aware) to foretell its own demise. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 07 04:00AM -0800 On Thursday, December 7, 2017 at 5:58:31 AM UTC-5, Chris Vine wrote: > refer, you could call it the "Rick Hodgin spam filter" and pass into > history as being like the Oracle of Delphi: the only oracle (as far as I > am aware) to foretell its own demise. I am the real Rick. And none of you understand. You all think the posts I make are spam, that I'm here because I enjoy posting spam and making this intrusion into people's lives, like I in some perverse way enjoy that intrusion. The message of the cross is an offering by God. We could not save ourselves from sin, so He came here to save us. He commands His servants to go forth and teach about Him, but there is nothing given to us to make anyone believe. Even He Himself will honor our choice, even if that choice sends us to Hell. The message of the cross is given for those who will be saved. It is not given for other people, except as a witness against them in God's final court. All who wish to separate themselves from the message are free to do so. The warning is: It will cost you your eternal soul. -- Rick C. Hodgin |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 07 12:23PM On Thu, 7 Dec 2017 04:00:49 -0800 (PST) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: [snip] > You all think the posts I make are spam, that I'm here because I > enjoy posting spam and making this intrusion into people's lives, > like I in some perverse way enjoy that intrusion. [snip] You have posted the elided text probably 100 times over the past year. We do understand. We also understand that you are a nuisance, you are one of the causes of the need for a moderated group, you have minimal self-awareness, you lack regard for others and lo: verily I counsel thee, that my teaching unto thee wast not minded to provoke thee to a further posting of thy erstwhile utterings.[1] Chris You seem to like "unto"s and other archaic language. I hope this makes the position clearer. This could be more pithily put as "fuck off". |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 07 04:37AM -0800 On Thursday, December 7, 2017 at 7:23:49 AM UTC-5, Chris Vine wrote: > You have posted the elided text probably 100 times over the past year. > We do understand... You are not the only readers / regulars in clc++. The message is given for those who will hear, not those who won't. You have the ability to ignore anyone's posts, and add people to filters using apps like Thunderbird and Eternal September. In Google Groups you can mark the thread spam and you'll never see it again. You'll note I don't generally post in other threads, but only to address questions or some related content. My concerns are you do not realize that without Jesus forgiving your sin, you are literally choosing a long running leap into eternal Hellfire. Nobody wants that end. I keep holding onto hope because for all who believe today, there was a yesterday they didn't. And it is God who draws men to His Son, not me. I am obedient to Him and am here when someone does come to believe. You are very rude, Chris, using profanity toward me. Is that really the way you want to be? To not only deny Christ, but also amp up in anti- Christ activities? It's about you, sin, Jesus, and eternity, Chris. Think about your end. -- Rick C. Hodgin |
| "Öö Tiib" <ootiib@hot.ee>: Dec 07 05:33AM -0800 On Thursday, 7 December 2017 14:37:36 UTC+2, Rick C. Hodgin wrote: > > We do understand... > You are not the only readers / regulars in clc++. The message is > given for those who will hear, not those who won't. Who they actually are? I once asked you, Rick, if you did over all these years get any followers? You said then that none, never. Have you at least got much positive feedback from other Christians? I trust that it is also close to none. Somehow you are unable to take under consideration that it is your own repulsive behavior that scares everybody away. Away from you and away from your God. Faith is easy to lose and hard to gather when "messenger" is behaving so rudely and unpleasantly. I hope that if He really exist then He can forgive that to you. |
| "Fred.Zwarts" <F.Zwarts@KVI.nl>: Dec 07 08:49AM +0100 "fir" schreef in bericht news:cd8a5b40-e4ed-4f13-b0d7-0fefe3d7d16f@googlegroups.com... >for a code snipped for firing non-blocking connect on client side >(some 2h of slow googling and reading dont show me that snippet, does >anybody maybe have that? tnx) Why do you need non-blocking connect? It usually causes code that is difficult to read, because it is not sequential. C++ makes it easy to create a separate thread to make the connection, so that other threads can continue to do their work. It is no problem if a separate thread blocks. |
| fir <profesor.fir@gmail.com>: Dec 07 02:00AM -0800 W dniu czwartek, 7 grudnia 2017 08:49:58 UTC+1 użytkownik F.Zwarts napisał: > difficult to read, because it is not sequential. C++ makes it easy to create > a separate thread to make the connection, so that other threads can continue > to do their work. It is no problem if a separate thread blocks. i managed to made nonblocking sends and receives also nonblocking accept connection on serber side - it was all fairly easy, you just repeat those calls and they return zero (metafiorically speaking) when nothing comes and return something wen comes - its not harder than blocking and nonblocking imo should be standard (blocking you could maybe probably even not mention) but is i said i still not found nonblocking connect.. it seems is somewhat more complicated becouse they failed something, read " Due to ambiguities in version 1.1 of the Windows Sockets specification, error codes returned from connect while a connection is already pending may vary among implementations. As a result, it is not recommended that applications use multiple calls to connect to detect connection completion. " this is page on this but still no code example https://msdn.microsoft.com/en-us/library/windows/desktop/ms737625(v=vs.85).aspx |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 07 10:34AM On Thu, 7 Dec 2017 02:00:47 -0800 (PST) > detect connection completion. " > this is page on this but still no code example > https://msdn.microsoft.com/en-us/library/windows/desktop/ms737625(v=vs.85).aspx There is no point in doing nonblocking i/o unless you are using an event loop, otherwise you are just doing a CPU-expending busy version of normal blocking i/o. On unix you do this by basing your event loop on the select() or poll() POSIX system calls (linux and some BSDs have a faster version, epoll() and BSDs also have kqueue). I believe windows has select() support, and also has its own windows-only event system as well (I don't program windows). Indeed, the Microsoft documentation page to which you have referred explicitly tells you this: "Use the select function to determine the completion of the connection request by checking to see if the socket is writeable." You know when an asynchronous connect has occurred because when it has, the file descriptor will signal itself to select()/poll() as ready to write. More completely, a non-blocking connect will return immediately with the EINPROGRESS error set and (from the man page) you use "select(2) or poll(2) for completion by selecting the socket for writing. After select(2) indicates writability, use getsockopt(2) to read the SO_ERROR option at level SOL_SOCKET to determine whether connect() completed successfully (SO_ERROR is zero) or unsuccessfully (SO_ERROR is one of the usual error codes listed here, explaining the reason for the failure)". You need to look at the documentation. Chris |
| fir <profesor.fir@gmail.com>: Dec 07 05:22AM -0800 W dniu czwartek, 7 grudnia 2017 11:36:02 UTC+1 użytkownik Chris Vine napisał: > explaining the reason for the failure)". > You need to look at the documentation. > Chris i want a piece of code, becouse i usually do more things than one at the same time and a long reading session will stop that all getting just code sniped and im done with this .. weird i cant find it (not googled very long but some notable amount and didint found it yet) |
| Daniel <danielaparker@gmail.com>: Dec 06 07:06PM -0800 On Wednesday, December 6, 2017 at 6:09:51 PM UTC-5, Lynn McGuire wrote: > I would still like to see a standard windowing user interface library. I'd settle for a date and a decimal class. Daniel |
| Melzzzzz <Melzzzzz@zzzzz.com>: Dec 07 05:39AM > file-system library derived from Boost, and other additions." > 1,605 pages ! ! ! > I would still like to see a standard windowing user interface library. That is pretty difficult as if this can be implemented portably. -- press any key to continue or any other to quit... |
| Andrey Karpov <karpov2007@gmail.com>: Dec 06 10:45PM -0800 Most interesting innovations introduced in C++17: https://www.viva64.com/en/b/0533/ |
| "Öö Tiib" <ootiib@hot.ee>: Dec 06 10:50PM -0800 On Thursday, 7 December 2017 01:09:51 UTC+2, Lynn McGuire wrote: > file-system library derived from Boost, and other additions." > 1,605 pages ! ! ! > I would still like to see a standard windowing user interface library. Standard windowing user interface would be very helpful for lot of software. However for majority of software it does not make any sense. Same is perhaps with several other things like with database support or with networking support. I would like standard modules support. Had there been standard way to incorporate modules into our software then such things could be easily made as separate standards about separate modules. |
| David Brown <david.brown@hesbynett.no>: Dec 07 09:03AM +0100 On 07/12/17 07:50, Öö Tiib wrote: > software. However for majority of software it does not make any > sense. Same is perhaps with several other things like with database > support or with networking support. There can be no way to make a windowing user interface library that pleases everyone. C++ stretches from massive multi-processing systems to tiny microcontrollers, and screen usage stretches from multiple synchronised high-resolution screens in a flight simulator to a e-ink watch display. The range is too great - a standard solution would be "one size fits nobody", not "one size fits all". If something can be done to modernise and standardise common toolkits, and maybe form a common basis and core, that might be practical. Instead of every toolkit having its own string class, for example, get them all to use utf-8 in std::string. Move them from their old containers to standard C++ containers. And so on. > I would like standard modules support. Had there been standard way > to incorporate modules into our software then such things could be > easily made as separate standards about separate modules. Modules would be good. Other things that need finished off and put in the standard are Concepts and Ranges. Coroutines are another potential big step (these require a lot more run-time support, but offer a very different way of structuring code). Then there are other minor but useful building blocks like the library fundamentals, concurrency and parallelism TS's. These are all fundamentals for C++. Something like windowing support (and networking, filesystems, etc.) are outer layers - these can be made independently. The standards should concentrate on the fundamental parts. The real biggie is metaclasses. That is still at the idea and brain-storming stage - but assuming the key people can get a consistent, simple yet flexible solution (and it is looking that way), then I hope the C++ folks put a great deal of emphasis on these. |
| Juha Nieminen <nospam@thanks.invalid>: Dec 07 08:06AM > software. However for majority of software it does not make any > sense. Same is perhaps with several other things like with database > support or with networking support. Maybe they should make a *separate* standard for such a system. A compiler can implement it as a library or not. (If a compiler does implement it, it should adhere strictly to the standard, of course.) But keep it separate from the main C++ standard. |
| Chris Ahlstrom <OFeem1987@teleworm.us>: Dec 07 05:43AM -0500 Daniel wrote this copyrighted missive and expects royalties: > On Wednesday, December 6, 2017 at 6:09:51 PM UTC-5, Lynn McGuire wrote: >> I would still like to see a standard windowing user interface library. > I'd settle for a date and a decimal class. Boost!? -- Q: Where's the Lone Ranger take his garbage? A: To the dump, to the dump, to the dump dump dump! Q: What's the Pink Panther say when he steps on an ant hill? A: Dead ant, dead ant, dead ant dead ant dead ant... |
| "Öö Tiib" <ootiib@hot.ee>: Dec 07 03:56AM -0800 On Thursday, 7 December 2017 10:03:51 UTC+2, David Brown wrote: > synchronised high-resolution screens in a flight simulator to a e-ink > watch display. The range is too great - a standard solution would be > "one size fits nobody", not "one size fits all". Advanced modern UI has other output (like sounds) and various user input (microphones, cameras, mouses, touch panels, keyboards). UI design typically expects most input gestures to be tied to and seamlessly accompanied by output animations and sounds to give immediate feedback to user that input was recognized. So making standard windowing interface that takes it all into account would be fun. > Instead of every toolkit having its own string class, for example, get > them all to use utf-8 in std::string. Move them from their old > containers to standard C++ containers. And so on. Everybody would love that but the C++ committee will never start to push utf-8. Likes of microsoft and qt are too glued to their legacy and so will reject all sanity. > brain-storming stage - but assuming the key people can get a consistent, > simple yet flexible solution (and it is looking that way), then I hope > the C++ folks put a great deal of emphasis on these. I am not sure of those generics of generics like Concepts and Metaclasses. These can bring some uniformity but these can also bring unneeded complexities and preliminary pessimizations. All my life I have seen creep of unneeded or rarely needed features into good things. Such features complicate architecture of the thing. There always will be some corner case of rare corner case in that rarely needed feature and that constrains the good thing to be inefficient for everything. ;) |
| David Brown <david.brown@hesbynett.no>: Dec 07 02:07PM +0100 On 07/12/17 12:56, Öö Tiib wrote: > immediate feedback to user that input was recognized. So making > standard windowing interface that takes it all into account would > be fun. Yes, but it also makes it even less suitable for being a part of standard C++. It would make a lot more sense to have this a separate project, outside of standard C++. The kinds of things you want here are very different from what you want in the main standards - you want fast moving projects that add support for new features in common systems, new hardware, new fads. You need to support a massive range of features - image types, 3D systems, fonts, widgets, events, etc. There are several very different ways of handling things - callbacks, event loops, messaging, etc. Some people will want small and limited systems, others will want big and feature-filled systems. So you might want more than one separate project here - again not something you would want in the C++ standard library. Oh, wait - we already have this. QT, wxWidgets, GTK, etc. > Everybody would love that but the C++ committee will never start to > push utf-8. Likes of microsoft and qt are too glued to their legacy > and so will reject all sanity. QT are coming round to UTF-8. But it is not easy to change history - compatibility with previous versions is important, and changes must be gradual. (The same applies to MS, I think.) > I am not sure of those generics of generics like Concepts and Metaclasses. > These can bring some uniformity but these can also bring unneeded > complexities and preliminary pessimizations. I can't see how either of these might be pessimisations. They will both greatly simplify the way classes and templates are written. Concepts don't give you anything more or less than you could write before - it's just that you no longer have to have so many enable_if's, template specialisations, and so on in order to say "this class or template has /this/ functionality". They also let you make templated functions and classes in a much neater manner. Metaclasses improve compile-time generation, remove boiler-plate code, and make it simpler and more reliable to write classes with common characteristics. They mean that many nice features can be added to C++ as metaclass libraries instead of language changes. |
| Chris Ahlstrom <OFeem1987@teleworm.us>: Dec 07 05:59AM -0500 Intelli2 wrote this copyrighted missive and expects royalties: > Builder C++ 6.0) > 7- You can't beat the RAD tools in C++ Builder for C++ development, > nothing comes close Does it still base most of its functionality on Delphi? If so, forget about it! I was dumbfounded the first time I stepped through a constructor in the Builder debugger. > The biggest recommendation I can make is DO NOT MOVE TO MFC, that's > where the pain starts. People still use that? -- A banker is a fellow who lends you his umbrella when the sun is shining and wants it back the minute it begins to rain. -- Mark Twain |
| "Öö Tiib" <ootiib@hot.ee>: Dec 07 04:55AM -0800 On Thursday, 7 December 2017 13:13:35 UTC+2, Chris Ahlstrom wrote: > Does it still base most of its functionality on Delphi? > If so, forget about it! I was dumbfounded the first time I stepped through > a constructor in the Builder debugger. Amine Moulay Ramdane can't discuss things with other people (some mental defect). He clearly copy-pasted the content of Gregor Brandt answer to that stack overflow question: https://stackoverflow.com/questions/4234434/c-builder-or-visual-studio So ... it is (and likely will remain forever) unclear if he has any opinion on the topic or just wanted to post something and so copied random piece of text from internet. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 07 10:52AM On Wed, 6 Dec 2017 09:23:11 -0800 (PST) > sub-expression (namely, the left operand) of the second << > expression, and therefore does NOT qualify as a full-expression. I > don't find that a difficult definition to follow. I am pleased for you. > Full-expressions are most commonly expression-statements, or > initializers, but it's quite commonplace for them to occur in other > contexts, such as items 5-7 above. On reflection I think you are right that 'cout << ++i << i++' is a single full expression. Your examples 1 to 4 are wrong though I think. The standard gives as an example 'B b[2] = { B(), B() };', about which it says "full-expression is the entire initialization including the destruction of temporaries" On the bigger picture, when you said: "The fact that A is sequenced before B, and that the sub-expressions of A are sequenced before A, and that the sub-expressions of B are sequenced before B, does not mean that the sub-expressions of A are sequenced before the sub-expressions of B", I think that is wrong (and that 'cout << ++i << i++' is now guaranteed to work) by virtue of the last sentence of §4.6/15 of C++17: "An expression X is said to be sequenced before an expression Y if every value computation and every side effect associated with the expression X is sequenced before every value computation and every side effect associated with the expression Y". Chris |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 07 12:47PM On Thu, 7 Dec 2017 10:52:10 +0000 Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote: [snip] > if every value computation and every side effect associated with the > expression X is sequenced before every value computation and every > side effect associated with the expression Y". This is quite an interesting topic, which I have researched a little more. This is the WG21 paper dealing with the point: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf It seems to have been realized that the kind of chaining of method calls below, which is a common idiom and also appears in TCPL 4th edition as an example, has undefined behaviour because although prior to C++17 it was provided that the evaluation of a function call took place after the evaluation of its arguments, it didn't say anything about the evaluation of subexpressions, and the chain comprises a single full expression: s.replace(0, 4, "").replace(s.find("even"), 4, "only") .replace(s.find("don't"), 6, " "); The new text deals with this. |
| Juha Nieminen <nospam@thanks.invalid>: Dec 07 08:03AM > Here is more information about me.. Dude, nobody cares. Just talk about C++, or shut up. |
| 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