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. -- 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