- sizeof in a template, applied in a template type - 7 Updates
- Awesome compile-time evaluation proposal - 3 Updates
- "The Curious Case of the Longevity of C" - 1 Update
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 09 09:02AM +0200 > node<T>* pnd; > int sz; > function(void) There's a missing return-type here. |
| David Brown <david.brown@hesbynett.no>: Oct 09 08:33PM +0200 On 07/10/17 22:53, Richard Damon wrote: > resource management. All new does is create object space from the heap, > and then call the object constructor on it. Its advantage is that you > can't forget to construct the object. The use of "new" (and, crucially, "delete") means that constructors and destructors are called properly. You still have to be careful about the outer level - anything your code allocates with "new", it must remember to "delete". But use of "new" and "delete" at least means any sub-objects are managed responsibly. To complete the picture, you should use a smart pointer or a standard library container on the outside level, as you point out below. But it is the "new" bit that does the allocation, and so that's where you mix in your own allocator - even though you ideally only want "new" to be called indirectly from functions like "make_unique". |
| asetofsymbols@gmail.com: Oct 09 11:48AM -0700 Bonita Montero wrote > node<T>* pnd; > int sz; > function(void) There's a missing return-type here. ---- I write: yes that would not compile perhaps it was better "int function(void)" ---- |
| "Öö Tiib" <ootiib@hot.ee>: Oct 09 12:45PM -0700 On Monday, 9 October 2017 21:33:28 UTC+3, David Brown wrote: > But it is the "new" bit that does the allocation, and so that's where > you mix in your own allocator - even though you ideally only want "new" > to be called indirectly from functions like "make_unique". Note that the operator new is typically called from lower layer of abstraction. I mean it is usually 'std::allocator::alloc' that makes memory management of containers to work. That 'alloc' is described to allocate uninitialized memory with '::operator new(std::size_t)' but (for letting containers to optimize better) it is left unspecified when and how it does that. |
| "James R. Kuyper" <jameskuyper@verizon.net>: Oct 09 05:03PM -0400 On 2017-10-09 15:45, Öö Tiib wrote: > to allocate uninitialized memory with '::operator new(std::size_t)' but > (for letting containers to optimize better) it is left unspecified > when and how it does that. std::container<T,Allocator> (where "container stands in for any of the standard containers) uses Allocator::allocate() (NOT alloc) to allocate memory. Allocator defaults to std::allocator, which does indeed use ::operator new(std::size_t). However, since asetofsymbols mentioned using his own home made memory allocator, and David Brown mentioned that you can define your own allocator for use with new, I think it's important to keep track of the fact that you don't have to use std::allocator just because you're using a standard container. More precisely, the standard containers are quite likely to use Allocator::Rebind<U>::other, because not everything that needs to be dynamically allocated by std::container<T,Allocator> is necessarily of type T. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 09 03:33PM -0700 On Tuesday, 10 October 2017 00:03:16 UTC+3, James R. Kuyper wrote: > > when and how it does that. > std::container<T,Allocator> (where "container stands in for any of the > standard containers) uses Allocator::allocate() (NOT alloc) to allocate Thanks for fixing, perhaps my memory mistook "alloc" from Objective-C. > you can define your own allocator for use with new, I think it's > important to keep track of the fact that you don't have to use > std::allocator just because you're using a standard container. I had impression that asetofsymbols did redefine the operator new (that std::allocator uses). User-defined Allocator classes are used but not too often in actual code bases. > Allocator::Rebind<U>::other, because not everything that needs to be > dynamically allocated by std::container<T,Allocator> is necessarily of > type T. The full truth about almost anything in C++ is tiny bit over-complicated. :D Since C++11 the standard containers must actually use std::allocator_traits<Allocator>::rebind_alloc<U> in that situation. On case Allocator is std::allocator<T> then that evaluates to same type like what you wrote (just "rebind" not "Rebind") but that match is AFAIK not required from allocator_traits of user-defined allocators. I trust that "rebind" is optional or planned to deprecate by C++17 or both. |
| asetofsymbols@gmail.com: Oct 09 03:59PM -0700 It is easy: New operator (not std) in few I remember call one malloc type routine that call the OS function that give memory. New/delete/io/ stream/memory functions are in a C++ library .dll (for to say the true someone are in one assembly .dll, and are reached /callable using pointers from the C++ .dll) They have 0 routine in common with C++ std library, no dipendence, follow no standard but have the same names (if I not consider macro) and 50%? of C++ library functionality |
| David Brown <david.brown@hesbynett.no>: Oct 09 02:45PM +0200 On 07/10/17 01:29, Ben Bacarisse wrote: > I was not aware that -fsanitize=undefined altered the language that g++ > compiles, but it seems to. Maybe g++ detecting and complaining about > undefined behaviour in code that is "run" at compile time? That /is/ strange. I don't make much use of the -fsanitize options (they are not well supported in small embedded systems). It is reasonable for a compiler to allow looser but "sensible" syntax with some compiler options and have tighter control with other options, but usually you'd expect that sort of change when choosing -std=c++XXX instead of -std=gnu++XXX, or -Wpedantic. I am very happy that gcc gives better support for constexpr than the standards require (it's cmath functions are declared as constexpr, at least in the setups I tried). But I'd rather it did so by saying in the manual that this is a gcc extension feature and they will guarantee to keep it in -std=gnu++XXX modes, instead of it being something that just happens to work. |
| David Brown <david.brown@hesbynett.no>: Oct 09 03:03PM +0200 On 07/10/17 03:53, Alf P. Steinbach wrote: > Superbly better car information system, with built-in network radio & > integration with emergency services, yep that's good. > But wheels and carriage and engine most important IMHO. I'd recommend you do read this proposal. Metaclasses can't come soon enough. It is not part of the car entertainment system - it is a new way to design bits for the car. It will let you build new types of wheels, or swap them for caterpillar tracks or a hoverboard. If we had had metaclasses from the beginning, then "class", "struct", "union" and "enum" would not be part of the language and compiler, they would be part of the standard library. The potential here is /that/ big. But I don't know if it would fix your const + non-const problem, or your UTF-8 support! |
| legalize+jeeves@mail.xmission.com (Richard): Oct 09 03:57PM [Please do not mail me a copy of your followup] "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code >Strangely, I haven't read it. I'm of the firm opinion that we need many >things fixed before introducing even more language in the language, so >to speak. [...] Herb's point is that people are doing this already, but in a clumsy way and rather than add new extensions to the language one by one, he'd rather add one thing that results in user libraries that can be tested, developed and shipped without further modification to the standard. 'interface' is the big one that wins. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| legalize+jeeves@mail.xmission.com (Richard): Oct 09 03:50PM [Please do not mail me a copy of your followup] Vir Campestris <vir.campestris@invalid.invalid> spake the secret code >> playing around with TECO macros:). >Teco? That takes me back! >Did you ever type 0yy instead of 0tt? I don't recall, but yes 0yy would be a problem :) -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| 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