Agree with Thiago here. We can still drop the requirement later if it turns out we can't easily do it for some reason.
Lars On 8/23/11 11:10 AM, "ext Thiago Macieira" <[email protected]> wrote: >On Tuesday, 23 de August de 2011 13:00:51 Konstantin Tokarev wrote: >> 23.08.2011, 12:58, "Thiago Macieira" <[email protected]>: >> > And the other requirement is that QT_STL be binary compatible with >> > QT_NO_STL. >> Could you explain why this requirement is needed? > >I think I could ask back: why not require it? > >It's not difficult to have Qt be binary compatible in those two versions. >All it >requires is that the Qt non-inline API never have anything that is >disabled by >QT_NO_STL. That means all functions must be present if that is defined, >which >in turn means no function can carry a non-inline STL type in their >signature. > >Tag types might be permitted, but in most cases tags exist for template >and >inline code, so I don't think it's a problem. > >The reason I personally want this is that I'd like to compile Qt without >#include'ing the STL headers everywhere. Nothing wrong with them -- >they're >just non-trivial in size, meaning the compilation time is bigger. For >someone >who needs to compile Qt several times a day and no longer has access to a >nice >compile farm, this could come in very handy. > >Moreover, imagine an embedded device that wants to save space in the >minimal >base system: they could choose to compile Qt and all of their >applications >without STL, thus saving a few hundred kilobytes of libstdc++. But user >applications could still use STL if they wanted and interoperate with Qt, >only >triggering the install of that lib. > >Finally, I've been reading the C++ ABI mailing list and there are several >teams there, from different compilers. They are cooperating to make the >same >ABI between their compilers. That doesn't mean, however, that one >compiler's >STL implementation works on another. > >So a hypothetical scenario is that a device maker chooses to use a >different >compiler for the base system, like RVCT for ARM devices, than the free >compiler that is offered to third-party users in the SDKs (normally GCC). >The >STL implementations are incompatible, so they build the base system >without >STL support, but GCC-built 3rd-party applications can use STL and >interoperate >with Qt. > >-- >Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Software Architect - Intel Open Source Technology Center > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
