Текущий Стандарт С++ и перспективы его развития

[archimed7592]

Цитата mo3r @ 14.06.07, 04:47

Opaque typedef

Очень интересная штука, но, AFAIK, в С++09 её не будет

[archimed7592]

Чего НЕ будет в С++09

С большой долей уверенности можно заявить, что следующие пункты не будут включены в готовящийся стандарт С++09. С не меньшей долей уверенности можно считать, что все эти пункты будут в следующим за С++09 стандарте С++1x.

---

Properties.(n1384, n1600, n1615)


Имеющиеся во многих языках свойства.
Предполагаемый синтаксис:

class foo
{
    int get_value ();
    int _bar;
public:
    property<int> bar =
    {
        read = get_value,
        write = _bar
    };
};

---

Dynamic Libraries(n1400, n1418, n1428, n1496)

Все мы в той или иной мере используем *.dll, *.so и т.п. динамические библиотеки. Их написание и использование сопровождаются нестандартными расширениями компиляторов.
Комитет собирается стандартизировать динамические библиотеки.
Предполагаемый синтаксис:

shared int i;        // shared linkage
 
shared
{
    int j;          // shared linkage
    static int k;   // internal linkage
}
 
shared class C
{
    int c0;         // no linkage
    static int c1;  // shared linkage
    void f();       // shared linkage
};
 
template <class T> class D
{
    int d0;         // no linkage
    static int d1;  // no linkage
    void f();       // no linkage
};
 
shared template <> D<int>; // D<int>::d1 and D<int>::f have shared linkage

---

Class namespaces(n1420)

При определении члена класса вне его(класса) определения приходится повсюду писать приставочку с именем класса.
Предлагается упростить реализацию класса внего его определения.
Предполагаемый синтаксис:

class MyClass
{
    typedef int value_type;
    value_type foo(); // declaration
    value_type bar(); // declaration
};
MyClass::value_type MyClass::foo() // definition
{
}
namespace class MyClass
{
    value_type bar() // definition
    {
    }
}
 
 
 
// class definition
class A
{
    // declarations
};
// elsewhere
// class namespace definition
namespace class A
{
    // definitions
}
 
 
template <class T> class A
{
    // declarations
};
// elsewhere
template <class T>
namespace class A
{
    // definitions
}
 
 
// full specialization
template <> class A<void*>
{
    // declarations
};
// partial specialization
template <class T> class A<T*>
{
    // declarations
};
// elsewhere
// add definitions to a full specialization
template<>
namespace class A<void*>
{
    // definitions
}
// add definitions to a partial specialization
template <class T>
namespace class A<T*>
{
    // definitions
}
 
 
 
 
template <class T> class outer
{
    template <class U> class inner
    {
        // declarations
    };
};
// elsewhere
template <class T>
namespace class outer
{
    template <class U>
    namespace class inner
    {
        // definitions
    }
}
// equivalent
template <class T>
template <class U>
namespace class outer<T>::inner
{
    // definitions
}
 
 
 
 
class outer
{
    class inner; // incomplete type
};
namespace class outer
{
    class inner
    {
        // declarations and definitions
    };
}
namespace class outer::inner
{
    // definitions
}

---

Security and Standard C Libraries(n1461)

Включает в себя усовершенствования безопасности. Те самые, что многие видели в VS-8.0(7.0? 7.1?) - Security Enhancements in the CRT.
Речь о printf_s, fscanf_s, blablabla_s.
Т.к. стандартная библиотека С разрабатывалась в те времена, когда о безопасности думали в последнюю очередь, её архитектура в этом плане оставляет желать лучшего.
Предлагается модифицировать все стандартные ф-ции по нескольким критериям.

В т.ч. следующие критерии
• Ф-ции, которые берут на вход какой-либо буфер, должны также брать его размер.
  printf_s, strcpy_s, etc.
• Ф-ции, которые берут на вход какой-либо callback, должны обеспечивать возможность хранения контекста между вызовами этого callback.
  qsort_s, bsearch_s, strtok_s, etc.
• Все входные указатели ф-ция обязана проверять на валидность(не равность NULL).

---

Multimethods(n1529)

Мультиметод - это механизм, подобный виртуальным функциям, только выбор ф-ции, которая должна быть вызвана основывается на динамическом типе нескольких аргументов(в отличии от одного для вирутальных ф-ций - this).
Предполагаемый синтаксис:

struct  shape            {...};
struct  square   : shape {...};
struct  triangle : shape {...};
 
bool    overlap( virtual shape& a, virtual shape& b);
    
bool    overlap( static square&   a, static triangle& b) {...}
bool    overlap( static triangle& a, static square&   b) {...}
bool    overlap( static shape&    a, static square&   b) {...}
bool    overlap( static square&   a, static shape&    b) {...}

---

Expliciting default parameters(n1466)

Пока что для аргументов ф-ции по умолчанию есть чёткое требование: они должны быть в конце списка аргументов. В C++1x это требование скорее всего уберут и добавят возможностей работы с такими ф-циями.

Предполагаемый синтаксис:

void f(int x = 1, int y=2);
void use()
{
    f(default, 3);
    f( );
}
 
 
template <class T>
T* allocAndClone (
    AllocatorType1 <T> alloc = MyAllocator <T>::instance(),
    T& prototype = T(),
    size_t size);
 
template <class T>
T* allocAndClone (
    AllocatorType2 <T> alloc = MyAllocator <T>::instance(),
    T& prototype = T(),
    size_t size);
 
void process(char t = ‘\n’);
void process(const char* = “end of line”);
 
void use(void)
{
    MyClonableClass* p;
    p = allocAndClone(
        default<AllocatorType1<MyClonableClass> >,
        default,
        10);
    
    process(default<char>);
    process(default); // error: ambiguity
    process(default<const char*>);
    process(default<float>); //error
}

---

Nested Namespace Definition(n1524)

Предполагаемый синтаксис. Предлагается вместо этого:

namespace grammars
{
    namespace cplusplus
    {
        ...
    }
}

Писать вот это:

namespace grammars::cplusplus
{
    ...
}

---

Implicitly-Callable Functions(n1611)

Неявно вызываемые ф-ции - это ф-ции, которые вызываются без применения постфиксного оператора "()".
Предполагаемый синтаксис.

double pi() implicit { return 3.1415926; } // ICF
double two_pi() implicit { return 2.0 * pi; } // ICF; note also the implicit call
 
double & pi() implicit
{
    static double pi = 3.1; // poor approximation
    return pi;
}
 
 
// primary definition of ICF template function:
template< class T = double >
T pi() implicit { return 3.141592653589793; }
// specializations, each an ICF based on primary declaration:
template<> float pi<float >() { return 3.14159F; }
template<> long double pi<long double>() { return 3.141592653589793L; }
 
template< class T >
T area( T radius )
{
    return pi<T> * radius * radius;
}
 
 
class Square
{
public:
    explicit Square( double s = 0.0 ) : side_(s) { }
    double & side() implicit { return side_; }
    // ...
private:
    double side_; // length in cm
};
 
 
 
 
class SerialNumberGenerator
{
public:
    SerialNumberGenerator( int start_from ) : next_(start_from) { }
    int operator()() implicit { return next_++; }
private:
    int next_;
};
 
SerialNumberGenerator unique( 1 ); // instantiation
// ...
cout << unique; // use

---

Contract Programming(n1942)

Идея добавить pre- и post-conditions, class invariant и block invariant.
Эти вещи очень часто встречаются в документации обобщённых классов. Также встречаются в стандарте в описании стандартной библиотеки.
Контрактное программирование имеет много плюсов. Хотя бы то, что код становится более самодокументированным. У компилятора появляется возможность делать некоторые предположения т.о. и возможность генерить более производительный код.
Отладка и тестирование станут проще. И т.п.

Предполагаемый синтаксис. Пример определения класса vector:

///////////////////////////////////////
// Tools
///////////////////////////////////////
 
template< class Iter, class T >
bool all_equals( Iter first, Iter last, const T& val )
{ /* for simplicity, let us assume T's can be compared */ }
 
template< class Iter, class Size >
bool equal_distance( Iter first, Iter last, Size size )
{ /* internal tagging mechnism so even input iterators can be passed */ }
 
///////////////////////////////////////
// New vector interface
///////////////////////////////////////
 
template< class T, class Alloc = allocator<T> >
class vector
{
    invariant
    {
        ( size() == 0 ) == empty();
        size() == std::distance( begin(), end() );
        size() == std::distance( rbegin(), rend() );
        size() <= capacity();
        capacity() <= max_size();
    }
    
    
public:
    typedef Alloc                             allocator_type;
    typedef typename Alloc::pointer           pointer;
    typedef typename Alloc::const_pointer     const_pointer;
    typedef typename Alloc::reference         reference;
    typedef typename Alloc::const_reference   const_reference;
    typedef typename Alloc::value_type        value_type;
    typedef ...                               iterator;
    typedef ...                               const_iterator;
    typedef ...                               size_type;
    typedef ...                               difference_type;
    typedef reverse_iterator<iterator>        reverse_iterator;
    typedef reverse_iterator<const_iterator>  const_reverse_iterator;
 
             vector()                  
                 postcondition { empty(); }
                
    explicit vector( const Alloc& al )
                 postcondition { empty();
                                 al == get_allocator(); }
                
    explicit vector( size_type count )
                 postcondition { size() == count;
                                 all_equals( begin(), end(), T() ); }
                
             vector( size_type count, const T& val )
                 postcondition { size() == count;
                                 all_equals( begin(), end(), val ); }
            
             vector( size_type count, const T& val, const Alloc& al )
                 postcondition { size == count;
                                 all_equals( begin(), end(), val );
                                 al == get_allocator(); }:
            
             vector( const vector& right )
                 postcondition { right == *this; }
    
             template< class InIt >
             vector( InIt first, InIt last )
                 postcondition { equal_distance( first, last, size() ); }
                
             template< class InIt >
             vector( InIt first, InIt last, const Alloc& al );
                 postcondition { equal_distance( first, last, size() );
                                 al == get_allocator(); }
 
             void reserve( size_type count )
                 precondition { count < max_size(); }
                 postcondition { capacity() >= count; }
                
             size_type capacity() const;
                 postcondition( result ) { result >= size(); }
                
             iterator begin()
                 postcondition( result ) { if( empty() ) result == end(); }
            
             const_iterator begin() const
                 postcondition( result ) { if( empty() ) result == end(); }
            
             iterator end();
             const_iterator end() const;
 
    // ....
};

Полную версию можно увидеть здесь.

---

Улучшенные возможности оптимизации(n1664, n1703)

Речь идёт о чём-то вроде спецификаций исключений, но, совсем в ином виде.
Если спецификации исключений никак в оптимизации не помогают(дай Б-г, если они не ухудшают производительность), то предложенные спецификаторы, вроде, должны.
Предложены спецификаторы: reading, writing, throwing, nothrow и pure.
Их назначение - описать поведение ф-ции с точки зрения, интересной оптимизатору. Все они, в отличии от спецификаций исключений являются частью типа ф-ции.

Предполагаемый синтаксис:

int f( int ) reading() writing() throwing();
// ---------------------------------------------------
// client code:
#include <cerrno>
int f( int x ) reading() writing(errno) throwing();
// library code:
#include <cerrno>
int f( int x ) reading() writing(errno) throwing()
{
    errno = 0;
    return 7 * x;
}
// ---------------------------------------------------
// Отличия от спецификаций исключений
int f( int ) throw()
{
    throw 2; // compiles; ultimately calls unexpected()
}
int g( int ) throwing()
{
    throw 2; // fails to compile: inconsistent with g’s declaration
}
// ---------------------------------------------------
float hypotenuse( float s1, float s2 ) writing()
{
    return sqrt( s1*s1 + s2*s2 ); // error; sqrt writes to errno
}
// ---------------------------------------------------
// pure <=> no reading, no writing no updating(доступ к volatile объектам)
float hypotenuse( float s1, float s2 ) pure
{
    return sqrt( s1*s1 + s2*s2 ); // error; sqrt is not pure
}
// ---------------------------------------------------
float hypotenuse( float s1, float s2 ) pure nothrow
{
    try
    {
        pure
        {
            return sqrt( s1*s1 + s2*s2 );
        }
    }
    catch(...) { }
}

---

Callable Pointers to Members(n1695)

Суть: указатели на члены можно будет вызывать. Относится как к методам, так и к членам-данным.
Вызвав указатель на член нужно передать ему первым аргументом указатель(или ссылку) на объект.

struct X
{
    void f() const;
};
 
int main()
{
    std::vector<X> v;
 
    std::for_each( v.begin(), v.end(), &X::f ); // well-formed
 
    return 0;
}

Добавлено 15.06.07, 00:35

---

И как уже было сказано, не будет Opaque typedef: Новый стандарт C++: C++09 (сообщение #1601368)

[=MOHAX=]

А шаблоны по прежнему надо будет писать только в одном файле? Т.е. разделять из в *.h/*.cpp нельзя?

[archimed7592]

=MOHAX=, шаблоны и сейчас можно разделять в разные файлы - export template... Другой вопрос, что не все компиляторы это поддерживают.

[gryz]

Цитата archimed7592 @ 18.06.07, 06:43

=MOHAX=, шаблоны и сейчас можно разделять в разные файлы - export template... Другой вопрос, что не все компиляторы это поддерживают.

А разве вообще есть такие компиляторы, которые полностью поддерживают export template??

[archimed7592]

gryz, насчет полностью - не знаю, а так, AFAIK, comeau поддерживает...

[LuckLess]

интеловский вроде тоже поддерживает export..

[archimed7592]

Вроде поддерживает: Экспорт шаблонов в icc

Добавлено 18.06.07, 13:15
Хотя, может и поддерживает - сам не пробовал... Может чел чего-то неправильно делал просто...

[archimed7592]

Появилось обещанное описание TR1:
TR1. Technical Report on C++ Library Extensions

[prografix]

А следующая конструкция будет легальной?

int n = 5;
int a[n];

[LuckLess]

Цитата prografix @ 21.06.07, 09:03

А следующая конструкция будет легальной?

int n = 5;
int a[n];

Надеюсь нет. Она не нужна в С++. хотя может для совместимости с С99..

[archimed7592]

prografix, нет.
Согласен с LuckLess - она не нужна .

[Devilguard]

Цитата

Expliciting default parameters(n1466)

Пока что для аргументов ф-ции по умолчанию есть чёткое требование: они должны быть в конце списка аргументов. В C++1x это требование скорее всего уберут и добавят возможностей работы с такими ф-циями.

Народ, это действительно кому-то нужно ???
Помоему это только усложнит читабельность кода. Когда видишь expr понять что это expr, а если сделать на манер паскаля, всегда сомнения будут. Да и не такие программисты лентяи чтобы 2 скобки не поставить.

[=MOHAX=]

Devilguard Ты не внимательно читаешь.

Цитата archimed7592 @ 15.06.07, 00:27

Чего НЕ будет в С++09

[archimed7592]

Цитата Devilguard @ 28.06.07, 20:05

Народ, это действительно кому-то нужно ???

Devilguard, представь себе, да .
Эта альтернатива именованным аргументам, описанным у Страуструпа в D&E.
Суть проблемы в том, что порой, разработчикам библиотеки необходимо предоставить поведение по умолчанию, а мы хотим оставить это поведение таким же, за исключением одной маленькой детали, причём, мы хотим указать только эту деталь и всё. С именованными аргументами это можно сделать так же, как и в VB:

window w0; // all default
window w1(Color := 5, Height := 7);

Только для именованных аргументов в С++ есть некоторые преграды, а вот для Expliciting default parameters - нету...

Цитата Devilguard @ 28.06.07, 20:05

Помоему это только усложнит читабельность кода. Когда видишь expr понять что это expr, а если сделать на манер паскаля, всегда сомнения будут. Да и не такие программисты лентяи чтобы 2 скобки не поставить.

Чует моё сердце, что ты говоришь про Implicitly-Callable Functions.
Ничего не усложнит. Если ты пишешь expr, то где гарантия, что не будет вызвано неявное преобразование?