- comp.lang.c++.moderated status - 2 Updates
- Transactional memory pros and cons from ACM Queue - 1 Update
- "C++17 Is Now Official" - 22 Updates
| legalize+jeeves@mail.xmission.com (Richard): Dec 07 08:38PM [Please do not mail me a copy of your followup] Marcel Mueller <news.5.maazl@spamgourmet.org> spake the secret code >> newsgroup an acceptable alternative to an unmoderated one - but I gather >> that this would require a team of moderators working in coordinated shifts. >Ack. You just argued why I unsubscribed from all moderated groups. Of course reading the moderated group is totally up to the individual. Me, I'm going to have it worse, because now I will have to see all those junk posts as a moderator :) "Time to take one for the team." -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Gareth Owen <gwowen@gmail.com>: Dec 08 05:11PM >> I do not post religious messages to moderated lists. You can verify > You conveniently snipped part of that post so I will repeat the > message here: Also, doesn't Rick's restraint in that regard offer evidence that he knows that what he's doing is wrong? Shouldn't someone who truly believe they were doing God's work spam everywhere equally strongly? |
| Intelli2 <intelli2@mama.com>: Dec 08 12:43PM -0500 Hello... Transactional memory pros and cons from ACM Queue: "We observed that the TM programming model itself, whether implemented in hardware or software, introduces complexities that limit the expected productivity gains, thus reducing the current incentive for migration to transactional programming and the justification at present for anything more than a small amount of hardware support." Read more here: https://insidehpc.com/2008/12/transactional-memory-pro-and-con/ This is why my inventions that are my scalable algorithms such as my C++ Synchronization Objects Library etc. that i am thinking to sell to Embarcadero technologies or Microsoft are still very useful. Thank you, Amine Moulay Ramdane. |
| 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. |
| 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. |
| legalize+jeeves@mail.xmission.com (Richard): Dec 06 11:19PM [Please do not mail me a copy of your followup] Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code >1,605 pages ! ! ! >I would still like to see a standard windowing user interface library. ...presumably because you want to see another 1500 pages added to the standard? -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| 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... |
| 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... |
| Ian Collins <ian-news@hotmail.com>: Dec 08 10:55AM +1300 On 12/08/2017 10:46 AM, Jorgen Grahn wrote: > Does someone has anything to say about the /actual/ C++17? What > features will I use the most when I get around to upgrading, in a few > years? For us it's a bit of dilemma: use the gcc 6.3 based ARM SDK we have been testing for a couple of months or start again with 7.2 to get C++17... Just like when C++11 dropped, it'll take a while to find the new bits that are really useful day to day. Today I tidied up some tool code by using the return value form emplace_back, so the journey has begun :) -- Ian. |
| 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. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 07 09:46PM On Wed, 2017-12-06, Lynn McGuire wrote: > character literals, inline variables, fold expressions, and more. On the > C++ standard library side is parallel versions of the STL algorithms, a > file-system library derived from Boost, and other additions." Good news! > 1,605 pages ! ! ! > I would still like to see a standard windowing user interface library. And yet everyone (I think) who responded, only did so to react to your last comment. Does someone has anything to say about the /actual/ C++17? What features will I use the most when I get around to upgrading, in a few years? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| jacobnavia <jacob@jacob.remcomp.fr>: Dec 08 12:29AM +0100 Le 07/12/2017 à 00:09, Lynn McGuire a écrit : > 1,605 pages ! ! ! This race to featurism and bloat will never stop... Nobody knows or understands the whole language. There are so many esoteric features that to master them all several lifes are necessary. Sorry I have only one, impossible to waste it learning all those 1605 pages. |
| Ian Collins <ian-news@hotmail.com>: Dec 08 12:41PM +1300 On 12/08/2017 12:29 PM, jacobnavia wrote: > Le 07/12/2017 à 00:09, Lynn McGuire a écrit : >> 1,605 pages ! ! ! > This race to featurism and bloat will never stop... I'm sure that will will be shocked to learn that most C++ programmers will welcome and use the new features. You are free to carry on keeping your head in the sand. -- Ian |
| jacobnavia <jacob@jacob.remcomp.fr>: Dec 08 10:39PM +0100 Le 08/12/2017 à 22:20, Richard a écrit : > Yep. My personal KILL file is for spammers, trolls, troll feeders, or > people for whom I've read enough of their posts to conclude that I'm > unlikely to learn anything from future content based on past content. I note that you didn't even start answering anything I said about your famous "constexpr if". You did not say anything because you have absolutely no arguments, and I do not remember you arguing anything with arguments. Just this kind of prose: > I don't record the reason why anyone ends up there, but for this > newsgroup it's probably like 90% are due to troll related postings. So, you do not say anything, you support the party line, and all the people that disagree with his majesty are just trolls, spammers, and the whole list of insults you vomit at each post. Note that I do not have kill files, I do not need them. Nobody can insult me if I do not give any importance to what they are writing or saying. |
| Ian Collins <ian-news@hotmail.com>: Dec 08 02:39PM +1300 > I'm not sure if compiler vendors have realized yet that string_view > and some other things need to be backported to their C++ 2011 > compilers. Abseil won't cut it. I'm sure you realise by now that this will never happen. -- Ian. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Dec 08 03:19AM >> Boost!? > Unfortunately, many projects, especially open source projects, can't use > boost. Hm, is Boost license that restrictive? I saw some open source projects using Boost. -- press any key to continue or any other to quit... |
| Gareth Owen <gwowen@gmail.com>: Dec 08 06:22AM >> esoteric features that to master them all several lifes are necessary. >> Sorry I have only one, impossible to waste it learning all those 1605 pages. > You don't have to use all features ;) And, indeed, who besides compiler writers and serious language wonks actually read language standards all the way through? (I'm sure some people in this group do, but I suspect its a small minority of C++ programmers.) The rest of us learn by browsing cppreference.com or reading descriptions of the new features here or otherwise online. We learn new idioms by example, and dip into the standard only for corner cases. Just like movie review aggregators, online discussions of the new features help us see the stuff that other people like or find useful, and then we can concentrate on learning that. The length of a language standard is of no more relevance than the length of a phone book. |
| David Brown <david.brown@hesbynett.no>: Dec 08 12:15AM +0100 On 07/12/17 22:46, Jorgen Grahn wrote: > Does someone has anything to say about the /actual/ C++17? What > features will I use the most when I get around to upgrading, in a few > years? There are lots of nice small things: template auto class template argument deduction inline variables (it took me a while to figure out what these are) initialisers in "if" and "switch" could be useful sometimes, and make things a little more consistent. And it will put an end to the hideous (IMHO) C idiom "if (x = nextVal()) ... ". "if constexpr" is going to make some templates a /lot/ neater. Along with constexpr lambdas, it also makes compile-time calculation more flexible (something I like, since my compiler PC is probably 1000 times faster than the my target processors!). When I first heard of them, I thought structured bindings would be great. Now we have multiple return values from functions: auto squareroot(double a) { if (a >= 0) { return std::make_pair(std::sqrt(a), true); } return std::make_pair(0.0, false); } auto foo(double x) { auto [sq, valid] = squareroot(x); if (valid) return sq; return -x; } It is all "auto". It is not quite as neat as multiple returns in Python, but it is not bad. But after more thought, I don't like that much. I'd rather write: auto squareroot2(double a) { using Ret = struct {double sq; bool valid;}; if (a >= 0) { return Ret { std::sqrt(a), true }; } return Ret { 0, false }; } auto foo2(double x) { auto y = squareroot2(x); if (y.valid) return y.sq; return -x; } It is still nicely "auto" in the caller, but you no longer have to remember the order of the return values - it is more robust, and clearer in the code. Structured bindings can still be useful for pulling apart arrays. The new attributes might be nice for people writing portable code - my code is gcc-specific, so I expect to stick to gcc __attribute__ in most cases. std::byte is an odd one - it's a good idea, but I think it was wrong to allow bitwise operations on it. std::optional is a good idea, that will lead to code that more clearly shows the intent: std::optional<double> squareroot3(double a) { if (a >= 0) { return std::sqrt(a); } return {}; } auto foo3(double x) { auto y = squareroot3(x); return y.value_or(-x); } With gcc at least, the std::optional version here is slightly less efficient than the others, which is a little surprising and disappointing. It is unlikely to make a big difference in practice. std::variant will be useful in many ways, I think. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Dec 08 07:11AM > The rest of us learn by browsing cppreference.com or reading > descriptions of the new features here or otherwise online. We learn new > idioms by example, and dip into the standard only for corner cases. Heh I learned most reading this group ;p (and browsing cppreference). > and then we can concentrate on learning that. > The length of a language standard is of no more relevance than the > length of a phone book. Yep. Whatever features are there we'll find out if and when we need them ;p -- press any key to continue or any other to quit... |
| David Brown <david.brown@hesbynett.no>: Dec 08 09:46AM +0100 On 08/12/17 09:41, Ian Collins wrote: > thumbed data books, my current hardware colleagues barely have any. The > only things cluttering my desk these days are ever bigger screens and > unopened bills... I still have the bookshelves full, but rarely read them now. But my desk is still cluttered - it has papers to an average depth of a couple of inches, hundreds of dead post-it notes, three keyboards, coffee cups, electronics boards, uncountably many USB sticks. I like to have things at hand! |
| David Brown <david.brown@hesbynett.no>: Dec 08 09:29AM +0100 On 08/12/17 07:22, Gareth Owen wrote: > actually read language standards all the way through? (I'm sure some > people in this group do, but I suspect its a small minority of C++ > programmers.) Indeed. I have read most of the C11 standard and know my way around it quite well now, but C++ standards are a far bigger job. The library parts in particular are only useful for implementers who need the exact specifications - they are certainly not learning resources! > The rest of us learn by browsing cppreference.com or reading > descriptions of the new features here or otherwise online. We learn new > idioms by example, and dip into the standard only for corner cases. Yes - www.cppreference.com is a very useful site. And there are lots of good blogs around for describing the newer features. |
| Ian Collins <ian-news@hotmail.com>: Dec 09 09:40AM +1300 On 12/09/2017 09:16 AM, jacobnavia wrote: >> Oh yeah, now I remember why that guy is in my KILL file:) > Well, apparently you read my posts, so your kill file is not working > properly. He read the bit I quoted. > Asking for simplicity and easy of use, is something C++ guys seem to > take as a personal insult. Any critic is an heresy, a holy wwar is > necessary. We know what drives your vitriolic postings about C++. You have nailed your colours to the mast of a language that, despite your best efforts, is unwilling to change. It's not surprising that you resent a language that embraces change. > Maybe, I do not think that software discussions should be done at a > personal level. C++ can be criticized, as C can, or any language > whatsoever. Very true, but unfounded criticism will never be well received. Rather than snipping you should take heed of Richard's main point about C++17: "The irony is that the new features and "bloat" are very much in the same vein as C++11: they make lots of code simpler and more uniform." -- Ian. |
| bartc <bc@freeuk.com>: Dec 09 12:20AM On 08/12/2017 18:41, Richard wrote: > I like this summary of the new features: > <https://www.viva64.com/en/b/0533/> > - std::byte type Finally, a C++17 feature (in fact a C++ feature) I can understand. Yes, this is just a byte type, that doesn't do anything clever. Why did it take so long to figure out that it was needed? -- bartc |
| Melzzzzz <Melzzzzz@zzzzz.com>: Dec 08 03:17AM > Nobody knows or understands the whole language. There are so many > esoteric features that to master them all several lifes are necessary. > Sorry I have only one, impossible to waste it learning all those 1605 pages. You don't have to use all features ;) -- press any key to continue or any other to quit... |
| Ian Collins <ian-news@hotmail.com>: Dec 08 09:41PM +1300 On 12/08/2017 07:22 PM, Gareth Owen wrote: > actually read language standards all the way through? (I'm sure some > people in this group do, but I suspect its a small minority of C++ > programmers.) Times have certainly changed. I kept hard copies of C99 and C++98 and used them as a reference on an almost daily basis. I've barely dipped into C++11 or 14. > The rest of us learn by browsing cppreference.com or reading > descriptions of the new features here or otherwise online. We learn new > idioms by example, and dip into the standard only for corner cases. As we now do in most things. Where I used to have a shelf of well thumbed data books, my current hardware colleagues barely have any. The only things cluttering my desk these days are ever bigger screens and unopened bills... -- Ian. |
| 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