- Vector with fixed memory size? - 5 Updates
- Pragma once support - 8 Updates
- YouTube comment moderation intrigues me. - 2 Updates
| JiiPee <no@notvalid.com>: Dec 12 08:48PM Is it possible to use std::vector so that it keeps the memory allocation size fixed at some size the whole lifespan? I need this kind of behaviour in gaming programming where I add elements and delete but I dont want any memory allocations happening after initial memory allocation. I read that the c++ standard does not talk anything about capacity() when resizing to zero. So I guess its undefined what happens to capacity after deleting elements? Or any alternative good way implementing this? |
| red floyd <dont.bother@its.invalid>: Dec 12 01:20PM -0800 On 12/12/2018 12:48 PM, JiiPee wrote: > when resizing to zero. So I guess its undefined what happens to capacity > after deleting elements? > Or any alternative good way implementing this? std::vector<>::reserve() |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 12 10:33PM On 12/12/2018 20:48, JiiPee wrote: > when resizing to zero. So I guess its undefined what happens to capacity > after deleting elements? > Or any alternative good way implementing this? neolib::vecarray /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." |
| JiiPee <no@notvalid.com>: Dec 12 10:46PM On 12/12/2018 21:20, red floyd wrote: >> happens to capacity after deleting elements? >> Or any alternative good way implementing this? > std::vector<>::reserve() but reserve would do re-allocation. So clear() would first delete me memory and reserve would allocate again. And this is what I would like to prevent... I would like to keep the original allocated memory even after clear(). |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 13 12:23AM +0100 On 12.12.2018 23:46, JiiPee wrote: > memory and reserve would allocate again. And this is what I would like > to prevent... I would like to keep the original allocated memory even > after clear(). The point is to call `reserve` right after creating the vector. Deleting items from a vector will not cause it to reallocate. C++11 added a `shrink_to_fit` function for when you want that, but I wouldn't trust it to actually do things, and the old idiom of swapping with an empty vector is trivial to code anyway. Cheers!, - Alf |
| woodbrian77@gmail.com: Dec 11 07:06PM -0800 On Tuesday, December 11, 2018 at 3:53:44 PM UTC-6, Vir Campestris wrote: > guards vs #pragma. > And yes, I did check the #pragma once was working. > GCC 7.3, Ubuntu 18, Xeon E5-2640 with SSD and 32Gb RAM. I've heard that GCC has a performance problem with its #pragma once implementation. If I remember right, there's a bug open on the matter for a long time. |
| David Brown <david.brown@hesbynett.no>: Dec 12 09:15AM +0100 > I've heard that GCC has a performance problem with its > #pragma once implementation. If I remember right, there's > a bug open on the matter for a long time. I think it might be better to say that gcc does not need a non-standard pragma to efficiently handle multiply included files, because it has highly efficient handling of the standard include guards. There may be other compilers - like MSVC - that don't have such efficient handling of include guards, and which then benefit from non-standard additions like #pragma once. But you are using gcc for your internal code. And you are generating standard code for other compilers. It seems obvious to me that you should be using standard include guards in both cases, and can drop all thoughts of non-standard solutions (#pragma once, #import). They are always unnecessary, not always supported, and give no compile speed benefits. It's a no-brainer, except perhaps for people working specifically on MSVC code. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 12 11:44AM +0100 On 12.12.2018 09:15, David Brown wrote: > always unnecessary, not always supported, and give no compile speed > benefits. It's a no-brainer, except perhaps for people working > specifically on MSVC code. Focusing on build efficiency with a given compiler is IMHO the entirely wrong thing to do, a not smart thing to do. I would recommend to focus primarily on /correctness/. And secondarily on productivity, e.g. time wasted on checking uniqueness of new include guard names; time wasted on realizing that a copied include guard was the cause of errors; reduced motivation and joy due to grappling with too archaic technology (include guards)... I believe that these costs far outweigh the costs of build times with a given compiler. In the Reddit thread cited by Brian in original posting, no-one reported any problems with using `#pragma once`. Several people reported problems with classical include guards. Cheers! - Alf |
| Bo Persson <bop@gmb.dk>: Dec 12 01:36PM +0100 On 2018-12-12 09:15, David Brown wrote: > other compilers - like MSVC - that don't have such efficient handling of > include guards, and which then benefit from non-standard additions like > #pragma once. This might have been true once, but MSVC fixed the include guard handling more than 5 years ago. Now there is no difference. Bo Persson |
| David Brown <david.brown@hesbynett.no>: Dec 12 02:32PM +0100 On 12/12/18 11:44, Alf P. Steinbach wrote: >> specifically on MSVC code. > Focusing on build efficiency with a given compiler is IMHO the entirely > wrong thing to do, a not smart thing to do. It makes sense - /if/ it is the compiler you are using for development, and the project is big enough that compile time has become an issue, and you have exhausted other more effective ways of improving build times (decent build manager, parallel builds, ccache, etc.). This does not sound like the case for the OP. So the sensible solution is to stick to the standard method - and as a bonus, this is highly efficient with his choice of tools. > the cause of errors; reduced motivation and joy due to grappling with > too archaic technology (include guards)... I believe that these costs > far outweigh the costs of build times with a given compiler. Yes, those are all much more important than the build times. > In the Reddit thread cited by Brian in original posting, no-one reported > any problems with using `#pragma once`. Several people reported problems > with classical include guards. I haven't looked at the thread. I can't say I have ever had problems with include guards - certainly no problems that were not part of a bigger issue (such as a project having more than one include file of the same name, from different directories). |
| David Brown <david.brown@hesbynett.no>: Dec 12 02:34PM +0100 On 12/12/18 13:36, Bo Persson wrote: >> #pragma once. > This might have been true once, but MSVC fixed the include guard > handling more than 5 years ago. Now there is no difference. Great - one less reason to use anything other than include guards. (I don't use MSVC myself, and don't keep up with all its changes, so it is good to be updated.) |
| scott@slp53.sl.home (Scott Lurndal): Dec 12 02:08PM >In the Reddit thread cited by Brian in original posting, no-one reported >any problems with using `#pragma once`. Several people reported problems >with classical include guards. Which means little to nothing. A small handful of people use #pragma once, while millions use classic include guards. |
| woodbrian77@gmail.com: Dec 12 11:31AM -0800 On Wednesday, December 12, 2018 at 8:08:18 AM UTC-6, Scott Lurndal wrote: > >with classical include guards. > Which means little to nothing. A small handful of people use #pragma once, > while millions use classic include guards. I think more people would use #pragma once if Gcc improved the performance of their implementation of it. Brian Ebenezer Enterprises http://webEbenezer.net |
| "Colonel Edmund J. Burke" <burkesbabes@bigass-babes.com>: Dec 12 08:20AM -0800 On 12/10/2018 11:37 AM, % wrote: >> Her "*snicker*" is childish. >> YouTube comment moderation intrigues me. > "so does a semi hard dick," says the village idiot. You mean the one in yer mouth? LOL |
| "Colonel Edmund J. Burke": Dec 12 11:44AM -0700 On 2018-12-12 9:20 a.m., Colonel Edmund J. Burke wrote: >> "so does a semi hard dick," says the village idiot. > You mean the one in yer mouth? > LOL all he is is mouth |
| 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