On 08/11/2011, at 8:40 AM, Olivier Goffart wrote: > On Monday 07 November 2011 19:52:37 Thiago Macieira wrote: >> On Monday, 7 de November de 2011 17:42:22 [email protected] wrote: >>> Don't we need to agree on what criteria a platform needs to fulfill in >>> order to be supported? The supported platforms will change as times go >>> by, so the list will need to be updated by some criteria (it might >>> cause discussion when some platforms are removed from the list, or if >>> some are favored above others) >>> >>> * Is the criteria the number of installed platform SDKs? >>> * Is the criteria availability of platform SDK for people in the >>> community?> >>> (e.g. MinGW has wider availability than MSVC) * Is the criteria that it >>> should be used for automatic compile tests? >>> >>> For instance, I'm not sure if Qt will have significant increased >>> adoption >>> because ICC is a supported platform, (it would be nice with some >>> numbers, >>> maybe a poll would suffice? >> >> For this purpose, since we're talking about what kind of compiler and >> language features will be allowed in the source code, we have to be very >> broad. > > I disagree. it is the set of supported compiler/platform that define the set > of feature we can or cannot use without #ifdef > > >> For example, suppose we want to allow template-template parameters >> in the code without restrictions. That means TTPs may enter into our API. >> >> Now imagine someone wants to port Qt to a platform with a compiler that >> doesn't support TTPs. That will be impossible because TTPs are mandatory and >> cannot be worked around. So this port is dead before it even starts >> happening. >> >> This is why I'm recommending being very conservative. Once we allow a >> feature unrestrictedly and it enters the API, there's no going back. > > In that case, #ifdef are going to be added around that kind of API that > cannot > be used with that compiler. > This is one reason rvct did not have QtConcurrent. >
I think we should differentiate between API and implementation here. If you include things in the API that some compilers don't support, you are dead in the water since the API requires it to be supported for client code to work. If the required feature only appears in the implementation, then you have the option of providing some alternative way of fulfilling the API which client code doesn't need to care about. I know it's not ideal to have different rules for API and implementation, but there would seem to be good reasons to put tighter restrictions on the API here. Put another way, it's like relaxing the rules for implementation only, ie giving more freedom to the developers implementing the API on different platforms/compilers. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
