On 24 September 2013 01:02, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote:
> On 9/23/13 7:50 AM, Manu wrote: > >> delete is important if your class is being allocated by a pool or >> something... >> > > It's important as an API function, but not as a language primitive. "new" > should also have been a function. I like operator new. It goes blue, and the statement isn't riddled with exclamation marks. Imagine if new was a template (it would have to be a template). Allocating a template would require nested template syntax every time, which is pretty ugly. X x = new!(X!arg(args...)); // ewoo, paren spam... But you said before, people won't use 'new' if they are using an >> allocator. I'm really not sure that's a good idea. >> > > I don't see another way if people are to define and use multiple > allocators. Well if an allocator is somehow associated with a class/struct, then 'new MyClass' would invoke that allocator. If you: pushThreadAllocator(myAllocator); X x = new X; popThreadAllocator(); Then new will use your thread-local allocator. Continue for global, fiber, etc. Maybe there's opportunity for 'scope' to offer some nice convenience here? Most people (library authors!) don't actually care about their memory >> allocation, they will continue to use 'new', just because it's a keyword. >> > > "new considered harmful" etc. > > > It also screws with generic code; X should be allocated with 'new', but >> Y should be allocated with yAllocator.alloc()? >> What if you decide that Z, which allocates with 'new', becomes a problem >> and you want to switch it into a pool? You now need to track down every >> instance of 'new Z', and change it. >> > > We can only improve that situation by allowing people to replace the > global allocator with their own allocators. Again, there's a disconnect > here - I'm discussing "how to make it easy for people to define allocators" > and you discuss "how to make it possible for people to plug allocators, > once defined, as the global allocator". These are two distinct endeavors. > At the level I'm at, I'm concerned with making good allocators easy to > implement. You may say you don't care, and that's good feedback, but it's > what I have for the time being. Well, I'm discussing "how do people affect/override 'new' in various circumstances?" But sure, I said before, if we're limiting this discussion to the API of an allocator then it looks fine, I see no obvious issues. But I think the question requires consideration of the intended goal to make informed decisions about the design, even at this level.