BP> OTOH some platforms are frozen. Say, Microsoft develop C++ for WIN32
 BP> but left the 16 bit version as it was some 5 years ago. You can't
 BP> write code portable for WIN16 and WIN32 that really use C++.  There
 BP> are no templates, no exception handling, etc in 1.52.   
This is neither a problem, nor a reason for a C++ Standard.  
It isn't a problem because Borland C++ supports templates and exceptions, and 
so does Watcom C++, and they both have 16-bit compilers that have all of the 
language features of the 32-bit compilers.  So anyone choosing Microsoft C++ 
as their tool has only themselves to blame when it won't do this particular 
job.
It isn't a reason for a C++ Standard because standardising a language does 
nothing for portability in this respect.  The presence or absence of a C++ 
Standard is irrelevant to whether or not there exists an "up-to-date" 
implementation for any given machine architecture.  There is no requirement 
that a C++ implementation be conformant.  Only customer demand can force 
compiler vendors to adhere to a standard.  That's how the standards process 
works.  If customer demand cannot even force Microsoft to keep its 16-bit 
compiler in step with its 32-bit compiler right now, what hope does it have 
of forcing Microsoft to produce a Standard C++ implementation for Win16 when 
the C++ Standard is ratified ?
 ¯ JdeBP ®
--- FleetStreet 1.19 NR
---------------