[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::c_plus_plus

Title:C++
Notice:Read 1.* and use keywords (e.g. SHOW KEY/FULL KIT_CXX_VAX_VMS)
Moderator:DECCXX::AMARTIN
Created:Fri Nov 06 1987
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3604
Total number of notes:18242

3434.0. "Microsoft dialect" by WOTVAX::FODDY (Dave foddy, 851-1723) Thu Feb 06 1997 09:33

    I've seen that we have said that we are implelmenting the Microsoft
    dialect of C++. Have we said what time lag there will be ? I don't
    expect that we will be able to do concurrent releases. Also having read
    3345, there is the implication that we might not be implementing it
    fully. What is the position on this ?
    
    I've mailed the Product Manager, George Pappas, but not yet had a
    reply.
T.RTitleUserPersonal
Name
DateLines
3434.1George Pappas?ORION::SAVAGENeil SavageThu Feb 06 1997 13:154
    I don't beleve George Pappas any longer has any association with DEC
    C++.
    
    You might try Anne Persels or Diane Davis. 
3434.2Engineering thoughs on Microsoft compatibilityDECCXX::MITCHELLFri Feb 07 1997 15:0530
We believe that a high degree of compatibility with MS is very, 
very important for DEC C++.  We've done a lot on this in the past 
and intend to do a lot in the future.  We have some ancedotal 
evidence that is is easier to port from Visual C++ to DEC C++ 
than other non-Windows C++ implementions, and we know of many 
customers who are using a combination of Visual C++ and DEC C++.

Can we do better?  Yes.  

Is there a time lag between the time  that Visual C++ supportsa 
language feature and when DEC C++ supports it?  Yes 

Is it important to minimize the time lag?  Absolutely.

Visual C++ V4.0 pulled ahead of us by adding some features from 
the emerging ANSI draft standard, and we have agressive plans in 
place to do the same.  Other work is going on in parallel to improve 
the level of dialect compatibility.  Something else that will help
in the future will the approval of C++ language standard.  This
won't remove the need to support Microsoft extensions, but it 
will help because many customers are interested in being able
to write more portable C++ code and will restrict themselves
to the standard language.

We are very interested in any and all inputs related to Microsoft
compatibility.

By the way, note 3345 (referenced in .0) isn't related to language 
dialect but rather to file format differences.  (Nonetheless, doing 
something to address 3345 would be a good idea.)