- Why does vector::reserve() not grow exponentially ? - 25 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 16 02:17AM +0200 What I said is the most reasonable assumption. It is also the most reasonable assumption because you often mix C and C++-code. If their memory-allocations woudln't come from the same pools the consumption of standby memory woould bow up. |
| Sam <sam@email-scan.com>: Jun 15 09:11PM -0400 Bonita Montero writes: > What I said is the most reasonable assumption. No it's not. It's not at all reasonable. > It is also the most reasonable assumption because you often mix > C and C++-code. If their memory-allocations woudln't come from > the same pools the consumption of standby memory woould bow up. Mixing C and C++ code is completely irrelevant. C++ containers can use a custom allocator/deallocator in the same program that also includes C code, too, and everyone will happily and deallocate what they need, without interfering with each other. |
| Juha Nieminen <nospam@thanks.invalid>: Jun 16 04:33AM > 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. I think you are painting too negative of a picture about the standardization process and new versions of the language. C++98 is complicated and rather quickly people discovered side-effects that could be used for interesting applications, but which were never originally designed for it. SFINAE would be the quintessential example. That small specification of the language, which was merely intended to make templates less likely to cause conflicts with each other, turned out to serendipitously allow for a limited form of compile-time introspection. But this... kludge, if you will, is quite complicated to understand, because the language was never designed with that in mind. Ask the average experienced C++ programmer to explain SFINAE, and he'll have no idea. Heck, ask the average experienced C++ programmer what std::enable_if is, and how it's used, and he'll have no idea. You might know it perfectly well, but let me assure you, the average C++ programmer doesn't. Not even the experienced one. And even if someone has some vague grasp of how it's used, ask him how and why it works, and chances are that he doesn't have a clue. It essentially works by magic. Likewise entire books were written about C++98 template metaprogramming. Something that was never originally designed for the language, but which arose serendipitously as a side-effect of how templates work. Yet, the average experienced C++ programmer, even to this day, has very limited knowledge and understanding of template metaprogramming. As, indeed, the "feature" is complicated and difficult to use, and results in very complicated-looking code. Thus, things like 'constexpr', 'consteval' and 'requires' were introduced to make all these much simpler and versatile. (For example C++98 template metaprogramming was extremely limited in what you could do, as it was limited to, essentially, basic integer arithmetic.) People love to complain about how such new features "make the language too complicated". They fail to see *why* these features were added: To actually make *using* the language simpler. To replace the ugly complicated hacks that were in common use in C++98 that were not only complicated to use, but also resulted in complicated source code that's hard to read and understand. People also love to complain that new features require programmers to have to learn more. Yet, the average C++ programmer doesn't even fully understand the entirety of C++98 either (see SFINAE, for example), yet they don't have much of a problem in writing C++ programs. It's not about knowing the entirety of the language. It's about having the tools to do what you need when you need them. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 16 07:09AM +0200 > Mixing C and C++ code is completely irrelevant. C++ containers can use > a custom allocator/deallocator in the same program that also includes > C code, too, ... They don't. |
| David Brown <david.brown@hesbynett.no>: Jun 16 10:35AM +0200 On 16/06/2021 06:33, Juha Nieminen wrote: <snip for brevity> > much of a problem in writing C++ programs. It's not about knowing the > entirety of the language. It's about having the tools to do what you need > when you need them. I agree with a lot of what you wrote here. C++ has been changing significantly. Many of the new features make the language simpler to use, to do the things people previously did in complex ways. A fine example is the "safe boolean idiom". It used to be ridiculously complicated with conversions via pointer types and the rest of the package. Now you just write "explicit operator bool" - simple, clear, safe and easy. You used to write complicated enable_if and SFINAE stuff - now you use "if constexpr" and concepts. You used to use templates as their own ugly, slow and limited compile-time programming language - now you use constexpr, and soon constinit and consteval. These are things people use in real code. Not everyone uses them, but some people do. There is also plenty of stuff in newer C++ that is hard for people to comprehend - there is too much, and some of it is too weird. But much of it is not for the normal application programmer - it is for the library programmer. Most people want to just /use/ std::vector, std::optional and the rest of it - it's usually only the people who /implement/ these that need the ugly details of perfect forwarding and whatever else is new. I currently use C++17 (with gcc extensions). This is embedded programming - I don't use much of the standard library, but I do use std::optional. I use "if constexpr" and inline variables. From C++14 I use return type deduction, more general constexpr functions, binary literals with digit separators. From C++11 - well, basically I didn't consider C++ to give me much beyond C until C++11 was a realistic choice. When C++20 is ready I will be using concepts, constinit and consteval (the more that is done at compile time, the better). I'll use modules when I can. As soon as contracts, reflection and metaclasses make it to the language, I'll be using them too. And there is /lots/ that I will have no use for - but other people will. (This is a concept many seem to find difficult.) |
| MrSpook_b1My5@751smt.edu: Jun 16 08:44AM On Tue, 15 Jun 2021 13:09:23 -0700 >> for(<type> <var>: <container>) >> C++ threads (for simple threading) >I would also add C++ atomics and memory barriers. The problem with C++ atomics is that they're not always atomic. Eg when using +=, -= type operators, which makes them a bit pointless IMO. Better to just use a lock and be 100% sure. |
| MrSpook_3_fdyox@sg5nvjmv741xbigdp6.info: Jun 16 09:04AM On Wed, 16 Jun 2021 10:35:42 +0200 >And there is /lots/ that I will have no use for - but other people will. > (This is a concept many seem to find difficult.) That however is the problem. The language is so big now its not realistic to expect a developer to know all of it never mind know all of it well enough to use. Yet company A will use a certain subset of C++, company B will use another, company C yet another and so on, and in their interview process will expect candidates knowledge to intersect with their use case. If it doesn't they may well dismiss a very good developer because he didn't know some obscure features of the language he could pick up in a few hours of learning anyway. And yes, it has happened to me. |
| David Brown <david.brown@hesbynett.no>: Jun 16 11:18AM +0200 > That however is the problem. The language is so big now its not realistic to > expect a developer to know all of it never mind know all of it well enough to > use. Most modern languages, along with their standard libraries, are too big for a developer to know it all. People regularly refer to Python as a language that is easy to learn and use - how many Python users understand metaclasses, __slots__, generators, decorators? I would not expect it to be even 1% of people who program in Python regularly. Yet they are very useful features to have in the language for those that need them, and very useful for people to use indirectly via libraries. Similarly, no one has the full Python standard library in their heads. How many POSIX programmers can say they know all of POSIX? How many Windows programmers know all of the Windows API? Being a big language (or standard library) is only a problem if the amount you need to understand to work reasonably effectively is intractable. > they may well dismiss a very good developer because he didn't know some obscure > features of the language he could pick up in a few hours of learning anyway. > And yes, it has happened to me. That is a problem with interviewers, not the language. There have been bad interviewers and bad hiring processes from long before C++ existed, and there always will be. |
| Juha Nieminen <nospam@thanks.invalid>: Jun 16 09:20AM > That however is the problem. The language is so big now its not realistic to > expect a developer to know all of it never mind know all of it well enough to > use. As I commented in my post, C++ has *always* been so big, ever since C++98, that almost no C++ programmer fully knows the ins and outs of it. The thing is, you don't need to know all of it. I have been programming in C++ like 25 years, about 15 of them professionally, and to this day things like SFINAE are mostly a mystery to me. Only recently did I learn some basic usage of std::enable_if (which, while it was added to the standard library in C++11, it's fully compatible with C++98 and you can use it if you implement it there). But that's fine. It has never really been a problem. The main thing that's beneficial to a C++ programmer is knowing what different tools exist in the language, even if he has no knowledge about how to use them. When you encounter a situation which sounds like the tool could be useful for, you can then find out how to use it. > they may well dismiss a very good developer because he didn't know some obscure > features of the language he could pick up in a few hours of learning anyway. > And yes, it has happened to me. I wouldn't be surprised if the same is the case with almost any programming language being used in the industry, such as Java, C# and Python. They probably have their obscure corner cases that only a fraction of programmers know and use fluently. |
| MrSpook_u_kch7_3@abbbp5z5c0iw8rwgxg4.gov: Jun 16 09:34AM On Wed, 16 Jun 2021 11:18:21 +0200 >> use. >Most modern languages, along with their standard libraries, are too big >for a developer to know it all. People regularly refer to Python as a I'd suggest its fairly easy to know C (minus libraries) in its entirety. >language that is easy to learn and use - how many Python users >understand metaclasses, __slots__, generators, decorators? I would not I'd be surprised if an experienced python programmer didn't know about generators (fancy name for co-routines) or decorators. >That is a problem with interviewers, not the language. There have been >bad interviewers and bad hiring processes from long before C++ existed, >and there always will be. The size of C++ makes it ever easier. And its not just interviewers - a lot of companies use online tests which always seem to include questions on the latest and greaters features of the language. (Plus the obligatory multiple inheritence questions even though almost no one uses it). |
| Tim Woodall <news001@woodall.me.uk>: Jun 16 09:49AM > when I can. > As soon as contracts, reflection and metaclasses make it to the > language, I'll be using them too. Great points and pretty close to my usage. I've never tried to implement the standard library and I'd not something I can imagine trying even in retirement although I accept it is probably a great way to really get to know the more esoteric bits of C++. > And there is /lots/ that I will have no use for - but other people will. > (This is a concept many seem to find difficult.) But here, I think, is where people's problems are, when you're on a huge code base with many developers, people use their own "pet feature" and you end up needing to understand far, far more than you would wish (or worse, end up guessing what code really does when you need to modify it and get it working by "coincidence" rather than by "understanding") I suffer this problem with python in particular, I use quite a lot of python as glue logic but I don't pretend to be a python developer. And the number of times someone "improves" something that I am then left having to google to understand exactly what is happening. I've been forced to learn a lot of python, but not because it's useful to me or I will ever need it, but merely because someone else wanted to use a feature rather than something that looks like what a C++ developer would write. |
| David Brown <david.brown@hesbynett.no>: Jun 16 11:53AM +0200 >> Most modern languages, along with their standard libraries, are too big >> for a developer to know it all. People regularly refer to Python as a > I'd suggest its fairly easy to know C (minus libraries) in its entirety. Sure (though there are subtle points that often elude people). But C is not a modern language. I am not suggesting that there are no simple languages, merely that C++ is far from being unique amongst large languages - and that people use similarly large languages all the time. >> understand metaclasses, __slots__, generators, decorators? I would not > I'd be surprised if an experienced python programmer didn't know about > generators (fancy name for co-routines) or decorators. People use generators, iterators and decorators - they rarely define their own. > of companies use online tests which always seem to include questions on the > latest and greaters features of the language. (Plus the obligatory multiple > inheritence questions even though almost no one uses it). Again, it is not the language that is the problem. |
| Paavo Helde <myfirstname@osa.pri.ee>: Jun 16 01:11PM +0300 > The problem with C++ atomics is that they're not always atomic. Eg when > using +=, -= type operators, which makes them a bit pointless IMO. Better to > just use a lock and be 100% sure. What makes you think so? These operations are guaranteed to be atomic: https://en.cppreference.com/w/cpp/atomic/atomic/operator_arith2 |
| MrSpook_ge@ldwlviy1f9uwd19thc.gov: Jun 16 10:19AM On Wed, 16 Jun 2021 11:53:44 +0200 >> latest and greaters features of the language. (Plus the obligatory multiple >> inheritence questions even though almost no one uses it). >Again, it is not the language that is the problem. But it is - there's an awful lot of cruft thats been added to C++ that is of dubious use yet at some point you have to know about it. Its been a long long time since I looked at a problem and thought "I don't know how to solve that easily in C++". A lot of the compile time rubbish added recently seems like someones undergraduate compiler project rather than anything of use. Eg people here seem to like constexpr. Why? What problem does it solve? If you need to calculate a value just bloody calculate it yourself and hardcode it, you don't need the compiler to do it for you at compile time. |
| MrSpook_p6g@ktmy0vg8lj7jxt.biz: Jun 16 10:21AM On Wed, 16 Jun 2021 13:11:04 +0300 >> using +=, -= type operators, which makes them a bit pointless IMO. Better to >> just use a lock and be 100% sure. >What makes you think so? These operations are guaranteed to be atomic: Well I've tried to use them in multithreaded code and I can assure you, at least on whatever version of gcc I was using at the time, they were not. |
| Sam <sam@email-scan.com>: Jun 16 06:37AM -0400 Bonita Montero writes: >> a custom allocator/deallocator in the same program that also includes >> C code, too, ... > They don't. Of course they do, it happens all the time. |
| Sam <sam@email-scan.com>: Jun 16 06:41AM -0400 > >What makes you think so? These operations are guaranteed to be atomic: > Well I've tried to use them in multithreaded code and I can assure you, at > least on whatever version of gcc I was using at the time, they were not. There's a common misconception that using atomics is sufficient for thread- safety. That's not true. Using +=10 and +=17, for example, only guarantees at some point the end result will be 27 more than where it started, presuming that nothing else happens. However, it is unspecified when this joyous event occurs and is observable by a given execution thread. That requires sequencing. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 16 01:01PM +0200 >>> C code, too, ... >> They don't. > Of course they do, it happens all the time. What I meant was that you can be assured that std::allocator<> directly or indirectly uses malloc() because what I said. Custum allocators are almost never used since there's much complpexity in providing a full-featured allocator; imagine you've to provide the ability for the allocator to be rebound via typename allocator_traits<alloc>::template rebind_alloc<new_alloc> for any type, so you have to provide nearly everything a C-allocator has to provide. No one does that; it's mich easier to replace the whole allocation by replacing it by a thread-cache malloc() implementation. |
| David Brown <david.brown@hesbynett.no>: Jun 16 01:09PM +0200 > Eg people here seem to like constexpr. Why? What problem does it solve? If you > need to calculate a value just bloody calculate it yourself and hardcode it, > you don't need the compiler to do it for you at compile time. To quote myself: """ And there is /lots/ that I will have no use for - but other people will. (This is a concept many seem to find difficult.) """ |
| MrSpook_F2ryro5_b@ugk_rvxkkm.gov: Jun 16 11:11AM On Wed, 16 Jun 2021 06:41:01 -0400 >presuming that nothing else happens. However, it is unspecified when this >joyous event occurs and is observable by a given execution thread. That >requires sequencing. Then whats the point of std::atomic? The only time people need atomic operations is precisely during multithreaded or parallel style programming. Even SysV semaphores can manage true atomicity between threads. |
| David Brown <david.brown@hesbynett.no>: Jun 16 01:14PM +0200 On 16/06/2021 11:49, Tim Woodall wrote: > you end up needing to understand far, far more than you would wish (or > worse, end up guessing what code really does when you need to modify it > and get it working by "coincidence" rather than by "understanding") That can certainly be a problem - but it is a general development and team problem rather than a language specific problem. Even if the programming language doesn't have unusual and rarely used features (and which language doesn't? Hands up those C experts who know what the "static" in "void bar(int a[static 10]);" is doing?), people will find unusual ways to express things. And it is best solved by reading each other's code, talking together, and sharing information. |
| MrSpook_G1Sw6pdcqz@5a69.edu: Jun 16 11:25AM On Wed, 16 Jun 2021 13:14:31 +0200 >which language doesn't? Hands up those C experts who know what the >"static" in "void bar(int a[static 10]);" is doing?), people will find Hand up. What does it do? Or is it simply the same as static int because the compiler doesn't care about certain syntax order, the same way that a[0] and 0[a] are equivalent? |
| Paavo Helde <myfirstname@osa.pri.ee>: Jun 16 02:37PM +0300 16.06.2021 08:09 Bonita Montero kirjutas: >> a custom allocator/deallocator in the same program that also includes >> C code, too, ... > They don't. They do. We have a large C++ library which uses strings and STL containers with a custom allocator built on top of the Intel TBB allocator. OTOH, all third-party C or C++ libraries and any host executables where our library might be loaded into still use whatever they want, typically standard malloc(). It would even be conceptually impossible for our dynamically loaded library to change the process malloc(), it would be far too late for that. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 16 01:40PM +0200 > allocator. OTOH, all third-party C or C++ libraries and any host > executables where our library might be loaded into still use > whatever they want, typically standard malloc(). Better replace the global memory-allocation through mimalloc. |
| "Öö Tiib" <ootiib@hot.ee>: Jun 16 04:55AM -0700 On Wednesday, 16 June 2021 at 07:34:06 UTC+3, Juha Nieminen wrote: > to make all these much simpler and versatile. (For example C++98 template > metaprogramming was extremely limited in what you could do, as it was > limited to, essentially, basic integer arithmetic.) You have lost capability to read, Juha, so you build straw-men that I did not write about C++98 and so then argue with those. The constexpr of C++14 was awesome. The sabotage of C++17 breaking it to hard to use and adding non-working 'if constexpr', 'consteval' and other horrible std::lawyer::laundry is very disappointing. Here you continue about people with whom I've nothing to do: > much of a problem in writing C++ programs. It's not about knowing the > entirety of the language. It's about having the tools to do what you need > when you need them. In C++14 the only issue is std::initializer_list that they never repaired all rest is good. C++17 copy-pasted some fine classes from boost all rest is trash. |
| 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