On sexta-feira, 1 de julho de 2016 12:34:15 PDT Thiago Macieira wrote: > On sexta-feira, 1 de julho de 2016 11:36:56 PDT Thiago Macieira wrote: > > Option 1: > > Not use Standard Library containers, just use the Qt containers as they > > exist. > > > > Option 2: > > Create new Qt containers to have the same complexity as Standard Library > > containers, but following the Qt naming conventions. Possibly with > > implicit > > sharing. > > > > Option 3: > > Create Qt API wrappers for those containers like std::deque, adding only a > > few inline functions to match the Qt-style API where the Standard Library > > > > API deviates. Examples are: > > empty -> isEmpty > > push_back -> append > > front -> first > > pop_front -> takeFirst > > cbegin -> constBegin > > cfind -> constFind > > Of course, Option 4: > Continue to allow Standard Library containers in internal code (no API or > ABI constraining) where there's a clear gain in performance and/or size. > > Option 5: > Allow Standard Library containers in internal code even if performance or > code size gains are not appreciable or have not been measured.
Concluding this thread: The opinions are pretty much evenly split among the respondents, so for now we'll remain at status quo (Option 4). In case we're not getting the deserved attention due to Summer vacations, I'll post again in a month or so to see if there's any change. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
