- Some C++14 code - 18 Updates
- Book Recommendation - 2 Updates
- Some cool C++14 - 2 Updates
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 12 02:12AM +0200 On 11.07.2018 23:23, bitrex wrote: >> On Tue, 10 Jul 2018 14:37:07 +0200 >> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> wrote: >> [snip] boltar know I don't see his messages, and that as far as I know the last of his identities that I killfiled was the third, but he uses "you" in his posting responding to mine, as if he were writing to me. In his interactions with me he's mostly concentrated on the personal, discussing imagined motivations and so on, as he does above. Thanks for letting me see that, bitrex. I have a relatively clean view of clc++, like a street view, but it's worth knowing about the sewers underneath. Lest one should fall into a manhole for forgetting about it. Cheers!, - Alf |
Ian Collins <ian-news@hotmail.com>: Jul 12 04:49PM +1200 On 12/07/18 09:59, Bart wrote: > That's the last thing I'd want to do when writing applications. I tend > to adopt the KISS principle. (I do know what RAII stands for; what it > means is another matter and another thing to worry about that I don't need.) So you prefer ignoring code that prevents resource leaks? Good plan. Which is the more simple approach, using a standard object to manage reference counting and resource management or doing it all by hand? Which is less error prone? -- Ian |
Paavo Helde <myfirstname@osa.pri.ee>: Jul 12 08:15AM +0300 On 12.07.2018 0:59, Bart wrote: > to adopt the KISS principle. (I do know what RAII stands for; what it > means is another matter and another thing to worry about that I don't > need.) So you have decided to ignore the single most useful and productive feature provided by C++. No wonder you find C++ complicated and clumsy. The KISS principle is fine. What could be more simpler than drop a std::vector in your class and not having to worry about how it resizes and destroys itself. |
boltar@cylonHQ.com: Jul 12 10:25AM On Wed, 11 Jul 2018 17:23:40 -0400 >> be maintainable in the wild. Syntax for its own sake. >it's perfectly understandable there's no mystery to it you're just not >familiar with modern C++. it is what it is. Stop whining Using every syntatic construct he can simply because its there to achieve something that could have been achieved easily using other methods is not clever, its showboating. And no one wants to work with programmers like that. |
Bart <bc@freeuk.com>: Jul 12 11:26AM +0100 On 12/07/2018 06:15, Paavo Helde wrote: > The KISS principle is fine. What could be more simpler than drop a > std::vector in your class and not having to worry about how it resizes > and destroys itself. On paper C++ sounds great. A lot of its features seem natural progressions in language design, especially when the start point is C. (I do a bit of language design and some areas are starting to encroach on C++ territory, but I'm trying to rein it in.) But strangely I'm loath to use it even though it's a free download. And that's not all due to its including nearly all the worst features of C which I'm not a big fan of. Imagine the following rough progression of languages from lower to higher level (here based on increasing sophistication of list-handling, say): ASM....C........C++........Python ^ ^ I mentioned I normally use two languages that fit in roughly where I've marked (both home-made, but that doesn't affect the principle). If I wanted to just have 'drop-in' vectors, I'd use the second language. If I need things to be fast and efficient and with precise control of data structures, I'd use the first. C++ will give me some convenience of those drop-in vectors, but it's not as convenient as the second language, and its code not as simple or as clear. The resulting executable will usually be much faster, but then the build process is considerably more cumbersome. It lacks spontaneity. I would quite like to be able to use some of the stuff in C++ but there are just too many things that put me off. -- bart |
alfsmate@showboater.central.com: Jul 12 10:30AM On Thu, 12 Jul 2018 02:12:41 +0200 >>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> wrote: >>> [snip] >boltar know I don't see his messages, and that as far as I know the last I can make you see my messages if I want, its quite easily done as you have discovered previously and now. But I'd forgotten you had such a fragile ego and can't handle criticism. I imagine you're either self employed or work in a university since I can't imagine many companies hiring someone who deliberately writes complex code and isn't interested in hearing any negative feedback. >In his interactions with me he's mostly concentrated on the personal, >discussing imagined motivations and so on, as he does above. I obviously hit the nail on the head or you wouldn't have killfiled me. >Thanks for letting me see that, bitrex. I have a relatively clean view >of clc++, like a street view, but it's worth knowing about the sewers >underneath. Lest one should fall into a manhole for forgetting about it. Ah, a superiority complex too. What an asset you'd be to any development team! Not. |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 12 02:13PM +0200 > On Thu, 12 Jul 2018 02:12:41 +0200 That's now the fourth Boltar identity I've killfiled. - Alf |
Rosario19 <Ros@invalid.invalid>: Jul 12 02:28PM +0200 On Thu, 12 Jul 2018 11:26:20 +0100, Bart wrote: > ASM....C........C++........Python possibly i'm alone on this i not find many pro (only i like cpu simple instructions) but i like C++ until cpu instruction more than Axiom or any other language that not start to some cpu instruction |
pooroldalf@has.no.clue.com: Jul 12 02:38PM On Thu, 12 Jul 2018 14:13:40 +0200 >On 12.07.2018 12:30, boltar alias alfsmate@showboater.central.com wrote: >> On Thu, 12 Jul 2018 02:12:41 +0200 >That's now the fourth Boltar identity I've killfiled. You seem to be under the impression that I have a limited supply of them and eventually I'll run out. Do you understand how usenet works? |
bitrex <user@example.net>: Jul 12 10:58AM -0400 > Using every syntatic construct he can simply because its there to achieve > something that could have been achieved easily using other methods is not > clever, its showboating. And no one wants to work with programmers like that. the nerds who labored 100,000 man-hours in their momma's basement putting all those new syntactic constructs and features in the more recent dialects of C++ didn't go to all that work for people _not_ to use them! The manuals to the new standards in the section on automatic return type deduction and rvalue references and move semantics didn't come with an addendum that says "This is the dark black magic part! Don't do this _too_ much or you gonna burn out the compiler!! and nobody will like you!" |
boltar@cylonHQ.com: Jul 12 03:19PM On Thu, 12 Jul 2018 10:58:24 -0400 >deduction and rvalue references and move semantics didn't come with an >addendum that says "This is the dark black magic part! Don't do this >_too_ much or you gonna burn out the compiler!! and nobody will like you!" You use a feature when it makes things simpler, not when it complicates the code. |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 12 05:23PM +0200 > [idiocy redacted] 5th Boltar identity killfiled. |
Hergen Lehmann <hlehmann.expires.5-11@snafu.de>: Jul 12 06:00PM +0200 Am 12.07.2018 um 16:58 schrieb bitrex: > deduction and rvalue references and move semantics didn't come with an > addendum that says "This is the dark black magic part! Don't do this > _too_ much or you gonna burn out the compiler!! and nobody will like you!" But they don't say "you have to use this" or "this is preferred over the traditional syntax" either. Think of your colleagues! Use well-known, proven semantics and algorithms, unless the more exotic ones represent a significant advantage. |
bitrex <user@example.net>: Jul 12 12:29PM -0400 >> _too_ much or you gonna burn out the compiler!! and nobody will like you!" > You use a feature when it makes things simpler, not when it complicates the > code. I think if you want to make a counterpoint it would be fair to provide examples of what you consider to be a high-performance non-showboaty codebase that approaches your ideals or else it's hard to say what we're actually talking about. "I know what I like and this ain't it" is a hard proposition to argue with C++ is all about performance that's why you use features like move semantics and template gobblediegook. If one prefers less "complicated" code (to whatever ideal standard of just-simple-enough-but-no-simpler one is making the comparison to) there are many compiled and interpreted languages that many people seem to like better; Python, C#, Go, Rust, and so forth. I know a couple of those too and I also use them they're the right tool for the job a lot of times. There's no law against it it's not a marriage. Many have tried to make the "simplicity of an interpreted language with the speed of C++"-language but few have seemed to succeed so far. I invite you to look at the alternatives and while they may seem much more inviting at first glance, when you actually start trying to leverage them to make super-clean non-showoffy simple code that also has C-like performance some of the stuff you end up with isn't going to be that much more parsable than what we've seen here. |
bitrex <user@example.net>: Jul 12 12:40PM -0400 On 07/12/2018 12:00 PM, Hergen Lehmann wrote: > traditional syntax" either. > Think of your colleagues! Use well-known, proven semantics and > algorithms, unless the more exotic ones represent a significant advantage. I like to give my colleagues the benefit of the doubt and assume that if they have written some code that doesn't seem too off the wall but does some "exotic" stuff I don't understand at first glance they probably have a reason for it and they aren't just trying to make my life difficult as the show-off C++ mastah. If they were trying to make my life difficult they'd format the code in a circular shape and have it calculate its own area the example posted wasn't particularly exotic compared to code you see in the wild or Modern C++ Design by Andrei Alexandrescu, thumb through a copy if you don't believe me. If they're all bad people welp I guess that's the way it is... |
bitrex <user@example.net>: Jul 12 12:46PM -0400 >> underneath. Lest one should fall into a manhole for forgetting about it. > Ah, a superiority complex too. What an asset you'd be to any development > team! Not. Damn son you could've read Modern C++ Design or a recent copy of Effective C++ and understood that snippet forwards and backwards no problem at all in the time you spent bitchin' about it. |
Daniel <danielaparker@gmail.com>: Jul 12 10:34AM -0700 On Thursday, July 12, 2018 at 12:30:05 PM UTC-4, bitrex wrote: > C++ is all about performance with the notable exception of streams, numeric from/to text conversion, the potential for aliasing to stop the compiler from doing some optimizations, and a few other things. Daniel |
woodbrian77@gmail.com: Jul 12 11:29AM -0700 On Thursday, July 12, 2018 at 12:35:04 PM UTC-5, Daniel wrote: > On Thursday, July 12, 2018 at 12:30:05 PM UTC-4, bitrex wrote: > > C++ is all about performance > with the notable exception of streams, numeric from/to text conversion, the potential for aliasing to stop the compiler from doing some optimizations, and a few other things. We don't have static exceptions either. I'm afraid that 2020 ++C will not bring them either. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
Bonita Montero <Bonita.Montero@gmail.com>: Jul 12 05:30PM +0200 > https://www.packtpub.com/application-development/mastering-c17-stl You can get it here: http://www.foxebook.net/mastering-the-c17-stl-make-full-use-of-the-standard-library-components-in-c17/ |
woodbrian77@gmail.com: Jul 12 11:05AM -0700 On Wednesday, July 11, 2018 at 4:18:23 AM UTC-5, Will Watts wrote: > Will Watts > (I should say I have no relationship with the author or Packt, other > than as a satisfied punter.) This one looks interesting: "Discovering Modern C++: An Intensive Course for Scientists, Engineers, and Programmers" by Peter Gottschling I'm connected to the author on Linkedin, but don't have a business relationship with him. Brian Ebenezer Enterprises https://github.com/Ebenezer-group/onwards/ |
Daniel <danielaparker@gmail.com>: Jul 11 08:53PM -0700 On Tuesday, July 10, 2018 at 5:43:17 PM UTC-4, Mr Flibble wrote: > { > buy_value(currentElement, arg); > }, Shouldn't that be std::visit([this, ¤tElement](auto&& arg) { buy_value(currentElement, std::forward<decltype(arg)>(arg)); }, I think 'buy_value' should be 'by_value', no? Daniel |
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 12 06:49PM +0100 On 12/07/2018 04:53, Daniel wrote: > buy_value(currentElement, std::forward<decltype(arg)>(arg)); > }, > I think 'buy_value' should be 'by_value', no? Yes I should be using perfect forwarding thanks however the spelling is correct: a node is being "bought" from the value allocator. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
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