[Development] Use of Standard Library containers in Qt source code

Thiago Macieira thiago.macieira at intel.com
Sat Jul 2 09:48:29 CEST 2016


On sábado, 2 de julho de 2016 07:46:28 PDT Marc Mutz wrote:
> Don't make this about the STL. Your arguments trivally extend to any third-
> party code.
> 
> So what you are actually proposing is to not use any third-party code in Qt
> unless it is wrapped in a Qtsy API first.

Not exactly. The Standard Library API is close enough to Qt's that it could be 
mistaken for Qt's, but subtly different. No one will mistake the Win32 API, 
Objective C API or, for that matter, any C library's API for Qt's.

The only thing worse than code you don't understand is code that you 
misunderstand.

> This is a bit over the top, isn't it? We want to allow our users to stay in
> the cozy Qt bubble for their own projects. As implementers of that bubble,
> we have no right to stay in it ourselves if doing so would be to the
> detriment of our users. And even creating an API wrapper is to the
> detriment of our users, because it requires resources that are then no
> longer available to fix real problems.

I get your point: we'd spend resources on something other than fixing real 
things. My counter point is that creating these wrappers increases our 
productivity. At the very least, it increases mine.

> If this is straw poll, I'm voting for Option 5. C++ programmers (those that
> wish to implement a C++ library) should be familiar with the STL.

In my opinion, Qt's existence negates your reasoning: we are creating a set of 
libraries that allow users not to know the Standard Library. And I am a 
product of that generation, as are many of our own developers.

Anyway, for the record, I vote for option 3: create simple wrappers. I will 
volunteer to do them too, if this is the option we choose.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list