On Oct 5, 2013, at 9:25 PM, Chandler Carruth <[email protected]> wrote:
> > On Sat, Oct 5, 2013 at 9:19 PM, Howard Hinnant <[email protected]> > wrote: > I must admit to not completely understanding how your path forward is any > different from the status-quo. > > An explicit call to operator new (array or single object) cannot be merged > with others according to N3664 (note that the wording has been tweaked in > core since that paper, but not in relevant ways). If we implement the > standard allocator's allocate function with a raw call to operator new, we > don't get the optimizations. > > I'm proposing a Clang builtin which allows us to call operator new *without* > writing a new-expression, but *with* the optimization freedoms provided by a > new-expression. > > This allows us to call the right operator new (ie, not the array version) > when doing a raw allocation while permitting the various optimizations. > > > And in that sense, I have absolutely no objection to it. > > It isn't the status-quo, I'm just explaining it poorly. =] I'll keep trying. > > I do maintain that unless there is a committee change, we need to beware of: > > #include <vector> > > int > main() > { > std::vector<int> v; > v.push_back(1); > return v[0]; > } > > #include <stdio.h> > #include <stdlib.h> > > void* operator new[](size_t sz) > { > printf("I don't like new-array!\n"); > abort(); > return nullptr; > } > > Yes. This means that we cannot implement a raw allocation with "new > char[...]" because it calls the wrong overload. My plan is for us to > implement raw allocation with "__builtin_allocate(...)" which calls the > non-array operator new, but in a way that permits the optimizations. Not positive, but I think dawn is breaking over marble-head. ;-) I look forward to testing this. In case it isn't apparent from my history, I live for avoiding trips to the heap. :-) Howard _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
