- Why does vector::reserve() not grow exponentially ? - 9 Updates
- C++ namespace question - 4 Updates
| "Öö Tiib" <ootiib@hot.ee>: Jun 14 10:49PM -0700 On Tuesday, 15 June 2021 at 01:35:31 UTC+3, Sam wrote: > Hint: when that happens to you your earnest appeal to the maintainers of > those "standard libraries" (that were always "designed in that way", until > they didn't) is not going to go very far. It was nineties when all compilers were different and optimized weakly. It was OK to ignore what Stroustrup thinks C++ is; to read standard library code and to use gained knowledge to optimize your programs. Some are stuck there. Then when it was standardized some of such code had to be rewritten. It had to be rewritten with every next version of same standard library of compiler that survived (and only few did survive). It made sense to stop usage of knowledge about implementation and to use what standard says. Some are stuck there. The platform agnostic libraries (like OpenGL, SDL, Qt, Boost and some smaller too) did great job of uniforming where standard and/or compilers failed or did not want to. Things started to become really portable. For a while ... but if to use versions released around 2015, then these mostly work. Some (including me) are stuck there. IMHO starting from C++17 the language was sabotaged through standardization. It is overly complicated. Stroustrup and Sutter try hard to collect advice how to use C++. They do it ... for years ... see <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines> Lot of it is good advice but they also seem to be stuck in C++14 like me. No u8 literals, "launder" or "if constexpr" in it. So now it is perhaps best idea to not even read standard but take it narrower and read what Stroustrup thinks C++ is. It has nothing to do with Montero however. He on one hand does not understand why standard library does not fix his misuse of reserve and/or shrink_to_fit and on other hand assumes certain design, is willfully ignorant, moves goalposts uses snip and run tactics ... basically relatively primitive troll. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 15 08:01AM +0200 It simply works the way I said. |
| Sam <sam@email-scan.com>: Jun 15 08:11AM -0400 Öö Tiib writes: > IMHO starting from C++17 the language was sabotaged through > standardization. It is overly complicated. Stroustrup and Sutter > try hard to collect advice how to use C++. I would move the point of no return to C++20, and I would describe it as hijacked rather than sabotaged. "if constexpr" was somewhat discombobulating but I can see some merit to it. It does simplify some things that would, otherwise would require a novel to implement. On the other hand, co-routines are a solution in search of a problem. Their only reason for existence is because Microsoft Windows sucks shit with real multi-threaded code, but it can implement that fake-threading model reasonably well. It is no accident that co-routines were authored by Microsoft, and they successfully hijacked the standardization process to cram it in. And, of course, Visual C++ was pretty prompt in implementing it. |
| Sam <sam@email-scan.com>: Jun 15 08:12AM -0400 Bonita Montero writes: > It simply works the way I said. Until it won't. |
| MrSpook_ka1o_g@otuej9sdvqn8a4.gov.uk: Jun 15 12:54PM On Tue, 15 Jun 2021 08:11:43 -0400 >but I can see some merit to it. It does simplify some things that would, =20 >otherwise would require a novel to implement. >On the other hand, co-routines are a solution in search of a problem. The= IMO a lot of new C++ since 98 is a solution in search of a problem. The big wins from 2011 onwards for me are: auto for(<type> <var>: <container>) C++ threads (for simple threading) lambdas std::function std::shared_ptr initialiser lists variadic templates The rest is just noise and probably there to tick boxes because 0.01% of devs might use them. As for co-routines I can't think of any sane use case for them either that can't be solved much more neatly using a normal function/method and class member or static/global variables. >only reason for existence is because Microsoft Windows sucks shit with re= >al =20 >multi-threaded code, but it can implement that fake-threading model =20 Sucks shit with multiprocess too. IIRC however co-routines are one of the few C++ language facilities that cannot be simulated in C, you'd have to use assember too to munge the stack correctly. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 15 03:34PM +0200 >> It simply works the way I said. > Until it won't. It never will because there are too much people which want to replace memory-allocation through a malloc()-replacement. |
| Manfred <noname@add.invalid>: Jun 15 08:30PM +0200 On 6/15/2021 7:49 AM, Öö Tiib wrote: > me. No u8 literals, "launder" or "if constexpr" in it. So now it is > perhaps best idea to not even read standard but take it narrower > and read what Stroustrup thinks C++ is. Wholeheartedly agree. BTW stressing the point on "std::launder" that IMO is a sick solution for a sick problem created by the committee - a problem that was simply non-existing in Stroustrup's C++. And he knows very well about the problem too, that C++ has become overly complicated as you say: "...C++17 did little to make our foundation more solid, regular, and complete. Instead, it added significant surface complexity and increased the number of features people need to learn. C++ could crumble under the weight of these – mostly not quite fully-baked – proposals." ... "We are on the path to something that could destroy C++. We must get off that path!" https://www.stroustrup.com/P0977-remember-the-vasa.pdf |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 15 01:09PM -0700 > auto > for(<type> <var>: <container>) > C++ threads (for simple threading) I would also add C++ atomics and memory barriers. |
| Sam <sam@email-scan.com>: Jun 15 05:37PM -0400 Bonita Montero writes: >> Until it won't. > It never will because there are too much people which want > to replace memory-allocation through a malloc()-replacement. I think I conversed with maybe ... two or three people in the last 25 years who were interested in that sort of a thing. Not an insurmountable problem. Besides, my stuff broke many more peoples' stuff during that time. Everyone was understandable, once the reasons for doing so were explained. Forward march of progress is unstoppable, and must continue. I have no doubt that if the relevant people concluded that existing allocator behavior must change then it's going to happen, and the very, very few dominoes that could only topple in one direction will have no problems facing themselves the other way. It's not the end of the world. Nobody's going to fall into a lava pit. They'll just change a few lines of code, and things will continue to work again. It was a problem for me, when I had to adapt in similar situations, and I'm confident it won't be a problem for other competent developers. |
| Richard Damon <Richard@Damon-Family.org>: Jun 14 08:48PM -0400 On 6/14/21 4:26 PM, Louis Krupp wrote: > } > === > doesn't work with g++: but namespace n { void nf1() {} } void gf2() {} namespace n { void nf3() {} } Does. Remember you can close and reopen namespaces unlike classes. |
| Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr>: Jun 15 12:51AM > } > Does. > Remember you can close and reopen namespaces unlike classes. That was the exact thing OP did and now asks for the way to avoid it. |
| Richard Damon <Richard@Damon-Family.org>: Jun 14 09:01PM -0400 On 6/14/21 8:51 PM, Nikolaj Lazic wrote: >> Does. >> Remember you can close and reopen namespaces unlike classes. > That was the exact thing OP did and now asks for the way to avoid it. But if it IS right way to do it, it is the right way to do it. The other option that I find messier but might work would be: namespace n; void n::hf1() {} void gf2() {} void n::nf3() {} |
| David Brown <david.brown@hesbynett.no>: Jun 15 09:38AM +0200 On 15/06/2021 02:51, Nikolaj Lazic wrote: >> Does. >> Remember you can close and reopen namespaces unlike classes. > That was the exact thing OP did and now asks for the way to avoid it. That was indeed one of the ways I know it can be done. I was hoping there was a syntax that avoided that, which I had overlooked - basically because I think it would have been neater in my code if something like "void ::g() {}" had been allowed by the language. It looks like there is no such syntax that I am missing. That's what I had expected, but it was worth a try. Thanks to all in the thread for their suggestions. |
| 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