On 15/06/2020 16:27, Dimitry Sibiryakov wrote: > 15.06.2020 20:03, Adriano dos Santos Fernandes wrote: >> I'm also playing with some containers I think we should allow: >> shared_ptr (with adaptor for our pools), unique_ptr. > > unique_ptr is fine if you know a sure way to prevent its usage with > default allocator by mistake.
AFAIK unique_ptr does not allocate memory. make_unique does, but this is another thing. > shared_ptr AFAIK uses dynamically allocated helper structure with > reference counter which may be bad from memory usage POV and slow down > dereferencing. This price may be too high for Firebird. > shared_ptr without make_shared does make two allocations. With make_shared only one. It certainly has its price for what it does. When I mean allow it uses, I mean allow it uses. When and as needed. We do not disallow sleep and it's used, of course, where needed, not in the middle of a critical code place. We should also base our classes in what STL people is doing (when we have a real reason to not use it). Lot's of people are thinking on them. Our RefPtr, for example, has some automatic casts that make terrible easy to be wrongly used. AutoPtr is certainly not better than unique_ptr today. The fact is that today Firebird uses STL a lot (see re2 code). Instead of avoid STL (when needed, as anything, and when well interfaced it our code base) we should better think on avoid reimplementing its well portable parts in the compilers we support. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
