- "Is C++ fast?" - 14 Updates
- Two vectors of ints or one vector of std::pair<int, int> ? - 1 Update
- Code to investigate basics of destructor - 2 Updates
- What is clean code? - 3 Updates
- if cargo blocks - 2 Updates
- Boost.Spirit parsing of JSON is slow (Was: Latest compiler and/or Boost.Variant issue with forward declarations) - 3 Updates
| Michael Powell <mwpowellhtx@gmail.com>: Jan 19 03:32PM -0800 On Saturday, January 19, 2019 at 2:18:36 PM UTC-5, Mr Flibble wrote: > that feature off). > Seriously changing an existing C++ codebase to make it pre-C++11 really is > a dumb idea. This is 2019. Boy, not kidding, I agree. Dumb, even imbecilic, given standards are well beyond even C++1y at this point, I think, and working on C++2z standards. Now, that said, I'm not suggesting because there is a fancy new shiny thing you should necessarily adopt it just because it's there; along the same lines as Stroustrup himself would encourage: KEEP IT SIMPLE. But if there is something you can leverage from a standard, by all means, DO IT! |
| "Chris M. Thomasson" <ahh_f_it@crap.nothing>: Jan 19 03:36PM -0800 On 1/19/2019 2:57 PM, Ian Collins wrote: >> For the same reason people care how fast their car can go in first gear. > That's a useful number - especially if it can get from 0 to 60 without > changing up :) 0 to 60 in first gear: Exotic cars are nice! http://newmotoring.com/what-cars-will-do-60mph-in-first-gear |
| Robert Wessel <robertwessel2@yahoo.com>: Jan 19 09:26PM -0600 On Sat, 19 Jan 2019 15:36:09 -0800, "Chris M. Thomasson" >> changing up :) >0 to 60 in first gear: Exotic cars are nice! >http://newmotoring.com/what-cars-will-do-60mph-in-first-gear Oddly they didn't include the Tesla S. Admittedly it one has only one gear, but it'll get well past sixty in that one. A base model 2012 S could do 0-60 in 5.9s. By 2015 (and the article is from 2016), you could get a 2.6s 0-60 in your S with the "Ludicrous Mode" option. |
| woodbrian77@gmail.com: Jan 19 07:31PM -0800 On Saturday, January 19, 2019 at 3:35:43 PM UTC-6, Ian Collins wrote: > >> Who cares about the performance of unoptimized builds? > > I do. > Why? Some of my software is meant to be portable. Just because some compilers do a good job of optimizing doesn't mean all of them will. There may also be some compile-time advantage to minimizing your dependency on optimizers. > > as far back as I can go to reach out. I've wondered > > if 2011 C++ is the new C. > Why don't you just wrote C++11? Let me guess. You haven't adopted :: prefixes yet. https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/genz.cc Brian Ebenezer Enterprises http://webEbenezer.net |
| Ian Collins <ian-news@hotmail.com>: Jan 20 04:38PM +1300 >>> if 2011 C++ is the new C. >> Why don't you just wrote C++11? > Let me guess. You haven't adopted :: prefixes yet. Why would anyone adopt such a superfluous abomination? No sane programmer would either overload C standard library function names or introduce their own namespace std. -- Ian |
| woodbrian77@gmail.com: Jan 19 07:59PM -0800 On Saturday, January 19, 2019 at 9:38:23 PM UTC-6, Ian Collins wrote: > Why would anyone adopt such a superfluous abomination? > No sane programmer would either overload C standard library function > names or introduce their own namespace std. Sure, but there are insane and/or malicious hackers out there. |
| Ian Collins <ian-news@hotmail.com>: Jan 20 05:05PM +1300 >> names or introduce their own namespace std. > Sure, but there are insane and/or malicious hackers out > there. So how does a :: prefixe solve that problem? -- Ian. |
| "Chris M. Thomasson " <ahh_f_it@crap.nothing>: Jan 19 09:10PM -0800 On 1/19/2019 7:26 PM, Robert Wessel wrote: > gear, but it'll get well past sixty in that one. A base model 2012 S > could do 0-60 in 5.9s. By 2015 (and the article is from 2016), you > could get a 2.6s 0-60 in your S with the "Ludicrous Mode" option. Agreed. I think "Ludicrous Mode" costs a lost as an add-on? |
| "Chris M. Thomasson " <ahh_f_it@crap.nothing>: Jan 19 09:15PM -0800 On 1/19/2019 9:10 PM, Chris M. Thomasson wrote: >> could do 0-60 in 5.9s. By 2015 (and the article is from 2016), you >> could get a 2.6s 0-60 in your S with the "Ludicrous Mode" option. > Agreed. I think "Ludicrous Mode" costs a lost as an add-on? For some reason, that typo makes me think of: https://youtu.be/J-wl8j-F9Tk Leisure Suit Larry 6: La Costa Lotta Or wasting away in the Land of Lost Wages... |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 20 07:44AM >> Why? > Some of my software is meant to be portable. Just because some > compilers do a good job of optimizing doesn't mean all of them will. A C++ compiler with a low-performing or buggy optimizer is virtually useless, as far as I can tell. There will be a runtime penalty for writing normal C++ code. When I started programming in C in the early 1990s, many didn't trust or use their optimizers. Perhaps partly for good reasons ... but it also didn't matter as much in old C. I wonder if that's where the quoted author is coming from. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Robert Wessel <robertwessel2@yahoo.com>: Jan 20 09:28AM -0600 On Sat, 19 Jan 2019 21:10:49 -0800, "Chris M. Thomasson " >> could do 0-60 in 5.9s. By 2015 (and the article is from 2016), you >> could get a 2.6s 0-60 in your S with the "Ludicrous Mode" option. >Agreed. I think "Ludicrous Mode" costs a lost as an add-on? I think that on the S, Ludicrous mode is now standard with on the P100D model, about $133K (list). |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 20 11:30AM -0500 On 1/19/19 23:05, Ian Collins wrote: > On 20/01/2019 16:59, woodbrian77@gmail.com wrote: >> On Saturday, January 19, 2019 at 9:38:23 PM UTC-6, Ian Collins wrote: >>> On 20/01/2019 16:31, woodbrian77@gmail.com wrote: ... >> Sure, but there are insane and/or malicious hackers out >> there. > So how does a :: prefixe solve that problem? Whenever you use such a prefix, you prevent yourself from accidentally using a corresponding identifier defined by such programmers. Of course, if you're absolutely certain that your code will never have to work with code written by such people, then you don't need such prefixes. |
| scott@slp53.sl.home (Scott Lurndal): Jan 20 04:31PM >> Seriously changing an existing C++ codebase to make it pre-C++11 really is >> a dumb idea. This is 2019. >What he said! Disagree. There are situations where C++11 isn't supported (compat. with third-party libraries and existing development environments being a typical driver). When you have thousands of servers running RHEL6 and third-party software, upgrading the entire farm is a massive undertaking (including verifying upgraded tools (source control, grid management, simulation tools, IC design and layout tools, open source software, libraries and kernels for compatability with existing flows). We have, for example a great deal of python2 code, which becomes a second-class citizen in newer distributions. Nobody is going to spend the time or dollars to upgrade the python code for python3. We have also discontinued use of various C++ features in certain parts of the codebase (such as soi disant smart pointers) for performance reasons. Sure, we'll eventually move forward, but that's a long process, and in the mean time, pre-C++11 code is required. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 20 04:47PM On 20/01/2019 16:31, Scott Lurndal wrote: > parts of the codebase (such as soi disant smart pointers) for performance reasons. > Sure, we'll eventually move forward, but that's a long process, and in the > mean time, pre-C++11 code is required. You are doing it wrong (TM). /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "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." |
| Juha Nieminen <nospam@thanks.invalid>: Jan 20 11:12AM > if they aren't near each other you'll get two cache misses. > And even then it's probably a very small effect. > Premature optimisation (google it) is normally a bad thing. It depends on how many (consecutive) operations you need to do with the data. If you need to do tons and tons of operations at once on the same data, cache optimization can make it several times faster. In fact, most game engines have been moving towards that direction in later years. So-called data-oriented design (put all data that needs to be handled at once as tightly packed in memory as possible, in in arrays, and minimize the amount of branching as much as possible. Code cache misses also can have a significantly detrimental effect in terms of speed.) --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Richard Damon <Richard@Damon-Family.org>: Jan 19 10:14PM -0500 On 1/19/19 6:45 AM, Paul wrote: > obj.print(); > return 0; > } The reason for the double destructor call is that when an blocked scope object goes out of scope, its destructor WILL be called, the compiler doesn't need to be smart enough to see if it has been manually called. The normal use of explicitly calling the destructor for an object is that the programmer is also handling the life of the storage the object is in (and thus the object was typically created with placement new. Another possible case is to destroy an object in place, and the rebuild it (again with placement new). One reason for needing the this-> on the destructor call is that your destroy function is a very unusual case, and my technically be invoking undefined behavior (since after you call the destructor, you are in a member function for a now non-existent object.) |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 20 11:02AM +0200 On 19.01.2019 13:45, Paul wrote: > 1) Why do I need this-> for an explicit destructor call? > ~Test() gives a compiler error on the grounds of no match for > operator ~ I don't understand why we need an explicit this here. Because ~Test() means something else by grammar rules. Here is an example (continuing the style of printing out meaningless gibberish): #include<iostream> using namespace std; class Test { private: int x; public: ~Test() { cout << " yes"; } Test() { cout << " no "; x = 0; } void destroy() { ~Test(); } void print() { cout << " x = " << x; } void operator~() { cout << " maybe"; } }; int main() { Test obj; obj.destroy(); obj.print(); return 0; } OUTPUT: no no maybe yes x = 0 yes |
| Real Troll <real.troll@trolls.com>: Jan 20 01:30AM -0400 <https://www.cs.helsinki.fi/u/luontola/tdd-2009/kalvot/02-Code-Quality.pdf> |
| "Chris M. Thomasson " <ahh_f_it@crap.nothing>: Jan 19 09:30PM -0800 On 1/19/2019 9:30 PM, Real Troll wrote: > <https://www.cs.helsinki.fi/u/luontola/tdd-2009/kalvot/02-Code-Quality.pdf> Have you ever seen code so bad that you wanted to print it out, then clean something up with the result? |
| Real Troll <real.troll@trolls.com>: Jan 20 01:49AM -0400 On 20/01/2019 05:30, Chris M. Thomasson wrote: >> <https://www.cs.helsinki.fi/u/luontola/tdd-2009/kalvot/02-Code-Quality.pdf> > Have you ever seen code so bad that you wanted to print it out, then > clean something up with the result? No but I have seen something happening like this when communication is a serious problem: <http://projectcartoon.com/cartoon/46980> |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 19 04:28PM -0800 On Saturday, January 19, 2019 at 5:53:53 PM UTC-5, Chris M. Thomasson wrote: > > virtual machines at first. > Looking forward to it. Do you happen to have an ISO that can install > _any_ version of your OS right now? No. It's in pieces still in development, and incompkete. > > now due to my several-month delay for my current side-step gaming > > projects diversion. > Well, just keep your eye on the prize, CAlive! :^) CAlive is one part of the project, a fundamental component. It is the sole focus of my current project efforts. These are all bridge projects, Chris. They won't work in pieces. Pieces are built separately, but they don't really work until it's all hooked up. When I release it, you'll be able to compile and run most C projects, and some C++ ones depending on what features they use. The IDE and debugger will all be close to production ready, and I will be using it to bootstrap my own compiler changes, meaning CAlive will be compiled in CAlive. Patience, Chris. And I would appreciate if you stop asking about CAlive. You won't speedup or slowdown my work on it. I'm 3+ years into this project now, and I'm about 6 years away from my target completion date of full hardware and software stack, including my own OS, drivers, apps, as well as CPU, and supporting peripheral hardware. Village Freedom Project: In God's sight, we've come together. We've come together to help each other. Let's grow this project up ... together! In service and Love to The Lord, forever! It's a specific purpose, and a goal. James 4:15 ... it's my intent to complete it and give it freely to the world. -- Rick C. Hodgin |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 20 01:38AM On 20/01/2019 00:28, Rick C. Hodgin wrote: > all hooked up. > When I release it, you'll be able to compile and run most C projects, > and some C++ ones depending on what features they use. If CAlive doesn't support all of the C++ language then it doesn't support C++; you are deluded to think otherwise. If at the very minimum it doesn't support C++11 then it is next to useless. "most C projects" doesn't sound very promising either given how simple the C language is: I could probably knock up a C compiler in a few weeks. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "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." |
| Daniel <danielaparker@gmail.com>: Jan 19 03:45PM -0800 On Saturday, January 19, 2019 at 5:30:45 PM UTC-5, Michael Powell wrote: >> relative performance is a little bit better on those, but not by much, e.g. 8 x slower than cJSON vs 12 times slower. > Hello, > I didn't check, but do you have that benchmark? Have what? I've posted the links to all the benchmarks I referred to. Daniel |
| Michael Powell <mwpowellhtx@gmail.com>: Jan 19 04:34PM -0800 On Saturday, January 19, 2019 at 6:45:57 PM UTC-5, Daniel wrote: > > Hello, > > I didn't check, but do you have that benchmark? > Have what? I've posted the links to all the benchmarks I referred to. Oh, I see; I guess I misunderstood and read that to mean you had a specifically "large" test case apart from the benchmarks. |
| Daniel <danielaparker@gmail.com>: Jan 19 04:50PM -0800 On Saturday, January 19, 2019 at 7:34:30 PM UTC-5, Michael Powell wrote: > Oh, I see; I guess I misunderstood and read that to mean you had a > specifically "large" test case apart from the benchmarks. I do, but I earlier provided a link to that :-) Anyway, here's the full set: Parsing and serializing text and integers: https://github.com/danielaparker/json_benchmarks/blob/master/report/performance.md Parsing and serializing text and doubles: https://github.com/danielaparker/json_benchmarks/blob/master/report/performance_fp.md Compliance comparisons: https://danielaparker.github.io/json_benchmarks/ Just to note, my primary interest in these benchmarks is to evaluate how jsoncons, of which I am the author, measures in comparison to other libraries that use different architectures, especially on large files. Daniel |
| 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