On Feb 6, 11:23 am, Nikolay Ivchenkov <ts...@mail.ru> wrote:
> Many potential improvements on C++ are impossible without breaking
> changes. Theoretically many potential breaking changes could keep any
> existing (old) code valid if the language will support some kind of
> its version control. For example, suppose the C++0x language
> specification corresponds to "C++1" (version 1 of C++) and some part
> of the next language specification with large number of breaking
> changes corresponds to "C++2" (version 2 of C++). There can be special
> preprocessor directives that could say to compiler which version of
> language specification is currently implied:
>
>  .... // "C++1" code ("C++1" is taken by default)
>  #language "C++2"
>  .... // "C++2" code (incompatible with the specification of "C++1")
>  #language "C++1"
>  .... // "C++1" code again
>
> Of course, many entities declared in a code conforming to "C++1" shall
> be available for the use in a code conforming to "C++2" and vice versa
> (while the declarations are just parsed in different ways), so our
> hypothetical new language specification shall contain additional
> compatibility rules.

There is no need for special preprocessor directives, since one can
already use #if and __cplusplus:

#if __cplusplus == 199711L
    // C++98/03
#elif __cplusplus == ...
   // future version
#endif

(The exact value of __cplusplus for C++0x isn't defined in the current
draft yet)


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 9 Feb, 07:27, Pavel Minaev <int...@gmail.com> wrote:
> There is no need for special preprocessor directives, since one can
> already use #if and __cplusplus:
>
> #if __cplusplus == 199711L
>     // C++98/03
> #elif __cplusplus == ...
>    // future version
> #endif

Conditional inclusion doesn't solve compatibility issues. Suppose we
have the following two radical changes:
1) implicit class member access is eliminated;
2) implicitly uninitialized variables are prohibited (this change can
decrease performance of an existing code), new keyword 'uninitialized'
is added.

The main question is how to efficiently use existing old code with new
compiler. Extensive rewriting of a source code by hand is very awkward
way. I see two possible solutions:
1) to create some external tool that can automatically transform old
code into its equivalent according to new rules;
2) to create a hybrid compiler that can translate multi-language
programs (I think, this way is more flexible).

The example below illustrates the second approach:

     // "C++1" code:

     int variable;

     bool uninitialized()   // OK
         { return something(); }

     class C1
     {
     public:
         void f()
         {
             variable = 1;   // (*this).variable = 1
             int i;   // i is uninitialized
             ....
         }
         ....
     private:
         int variable;
     };

     #language "C++2"
     // "C++2" code:

     class C2
     {
     public:
         void f()
         {
             variable = 1;   // ::variable = 1
             .variable = 1;   // (*this).variable = 1
             int i;   // i is zero-initialized
             int j(uninitialized);   // j is uninitialized
             bool b =
                 ??uninitialized();   // calls the function
             C1().f();
   ....
         }
         ....
     private:
         int variable;
     };

Here "C++2" code uses entities ::variable, ::uninitialized, ::C1,
and ::C1::f defined in "C++1" code as if the entire code was
transformed into:

     #language "C++2"

     int variable;
     bool __non_keyword_uninitialized()
         { return something(); }

     class C1
     {
     public:
         void f()
         {
             .variable = 1;   // (*this).variable = 1
             int i(uninitialized);   // i is uninitialized
             ....
         }
         ....
     private:
         int variable;
     };

     class C2
     {
     public:
         void f()
         {
             variable = 1;   // ::variable = 1
             .variable = 1;   // (*this).variable = 1
             int i;   // i is zero-initialized
             int j(uninitialized);   // j is uninitialized
             bool b =
                 __non_keyword_uninitialized();
             C1().f();
   ....
         }
         ....
     private:
         int variable;
     };


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Many potential improvements on C++ are impossible without breaking
changes. Theoretically many potential breaking changes could keep any
existing (old) code valid if the language will support some kind of
its version control. For example, suppose the C++0x language
specification corresponds to "C++1" (version 1 of C++) and some part
of the next language specification with large number of breaking
changes corresponds to "C++2" (version 2 of C++). There can be special
preprocessor directives that could say to compiler which version of
language specification is currently implied:

 .... // "C++1" code ("C++1" is taken by default)
 #language "C++2"
 .... // "C++2" code (incompatible with the specification of "C++1")
 #language "C++1"
 .... // "C++1" code again

Of course, many entities declared in a code conforming to "C++1" shall
be available for the use in a code conforming to "C++2" and vice versa
(while the declarations are just parsed in different ways), so our
hypothetical new language specification shall contain additional
compatibility rules.

This approach looks very promising, but there may be many difficulties
to realize it, and I wanna see any opinions about such difficulties.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]