На главную
ПРАВИЛА FAQ Помощь Участники Календарь Избранное DigiMania RSS
msm.ru
Модераторы: JoeUser, Qraizer, Hsilgos
Страницы: (75) « Первая ... 3 4 [5] 6 7 ...  74 75  ( Перейти к последнему сообщению )  
> Текущий Стандарт С++ и перспективы его развития
    Цитата mo3r @
    Opaque typedef

    Очень интересная штука, но, AFAIK, в С++09 её не будет :no-sad:
    If you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.
    © George Bernard Shaw
      Чего НЕ будет в С++09

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




      Properties.(n1384, n1600, n1615)


      Имеющиеся во многих языках свойства.
      Предполагаемый синтаксис:
      ExpandedWrap disabled
        class foo
        {
            int get_value ();
            int _bar;
        public:
            property<int> bar =
            {
                read = get_value,
                write = _bar
            };
        };





      Dynamic Libraries(n1400, n1418, n1428, n1496)

      Все мы в той или иной мере используем *.dll, *.so и т.п. динамические библиотеки. Их написание и использование сопровождаются нестандартными расширениями компиляторов.
      Комитет собирается стандартизировать динамические библиотеки.
      Предполагаемый синтаксис:
      ExpandedWrap disabled
        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)

      При определении члена класса вне его(класса) определения приходится повсюду писать приставочку с именем класса.
      Предлагается упростить реализацию класса внего его определения.
      Предполагаемый синтаксис:
      ExpandedWrap disabled
        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).
      Предполагаемый синтаксис:
      ExpandedWrap disabled
        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 это требование скорее всего уберут и добавят возможностей работы с такими ф-циями.

      Предполагаемый синтаксис:
      ExpandedWrap disabled
        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)

      Предполагаемый синтаксис. Предлагается вместо этого:
      ExpandedWrap disabled
        namespace grammars
        {
            namespace cplusplus
            {
                ...
            }
        }

      Писать вот это:
      ExpandedWrap disabled
        namespace grammars::cplusplus
        {
            ...
        }





      Implicitly-Callable Functions(n1611)

      Неявно вызываемые ф-ции - это ф-ции, которые вызываются без применения постфиксного оператора "()".
      Предполагаемый синтаксис.
      ExpandedWrap disabled
        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:
      ExpandedWrap disabled
        ///////////////////////////////////////
        // 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.
      Их назначение - описать поведение ф-ции с точки зрения, интересной оптимизатору. Все они, в отличии от спецификаций исключений являются частью типа ф-ции.

      Предполагаемый синтаксис:
      ExpandedWrap disabled
        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)

      Суть: указатели на члены можно будет вызывать. Относится как к методам, так и к членам-данным.
      Вызвав указатель на член нужно передать ему первым аргументом указатель(или ссылку) на объект.
      ExpandedWrap disabled
        struct X
        {
            void f() const;
        };
         
        int main()
        {
            std::vector<X> v;
         
            std::for_each( v.begin(), v.end(), &X::f ); // well-formed
         
            return 0;
        }


      Добавлено


      И как уже было сказано, не будет Opaque typedef: Новый стандарт C++: C++09 (сообщение #1601368)
      If you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.
      © George Bernard Shaw
        А шаблоны по прежнему надо будет писать только в одном файле? Т.е. разделять из в *.h/*.cpp нельзя?
          =MOHAX=, шаблоны и сейчас можно разделять в разные файлы - export template... Другой вопрос, что не все компиляторы это поддерживают.
          If you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.
          © George Bernard Shaw
            Цитата archimed7592 @
            =MOHAX=, шаблоны и сейчас можно разделять в разные файлы - export template... Другой вопрос, что не все компиляторы это поддерживают.

            А разве вообще есть такие компиляторы, которые полностью поддерживают export template??
              gryz, насчет полностью - не знаю, а так, AFAIK, comeau поддерживает...
              If you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.
              © George Bernard Shaw
                интеловский вроде тоже поддерживает export..
                  Вроде поддерживает: Экспорт шаблонов в icc :lol:

                  Добавлено
                  Хотя, может и поддерживает - сам не пробовал... Может чел чего-то неправильно делал просто...
                  If you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.
                  © George Bernard Shaw
                    Появилось обещанное описание TR1:
                    TR1. Technical Report on C++ Library Extensions
                    If you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.
                    © George Bernard Shaw
                      А следующая конструкция будет легальной?
                      ExpandedWrap disabled
                        int n = 5;
                        int a[n];
                      Мой сайт - www.prografix.narod.ru
                        Цитата prografix @
                        А следующая конструкция будет легальной?

                        int n = 5;
                        int a[n];

                        Надеюсь нет. Она не нужна в С++. хотя может для совместимости с С99..
                          prografix, нет. :no:
                          Согласен с LuckLess - она не нужна :).
                          If you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.
                          © George Bernard Shaw
                            Цитата

                            Expliciting default parameters(n1466)

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


                            Народ, это действительно кому-то нужно ???
                            Помоему это только усложнит читабельность кода. Когда видишь expr понять что это expr, а если сделать на манер паскаля, всегда сомнения будут. Да и не такие программисты лентяи чтобы 2 скобки не поставить.
                              Devilguard Ты не внимательно читаешь.
                              Цитата archimed7592 @
                              Чего НЕ будет в С++09

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

                                Devilguard, представь себе, да :).
                                Эта альтернатива именованным аргументам, описанным у Страуструпа в D&E.
                                Суть проблемы в том, что порой, разработчикам библиотеки необходимо предоставить поведение по умолчанию, а мы хотим оставить это поведение таким же, за исключением одной маленькой детали, причём, мы хотим указать только эту деталь и всё. С именованными аргументами это можно сделать так же, как и в VB:
                                ExpandedWrap disabled
                                  window w0; // all default
                                  window w1(Color := 5, Height := 7);

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


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

                                Чует моё сердце, что ты говоришь про Implicitly-Callable Functions.
                                Ничего не усложнит. Если ты пишешь expr, то где гарантия, что не будет вызвано неявное преобразование?
                                If you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.
                                © George Bernard Shaw
                                1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (75) « Первая ... 3 4 [5] 6 7 ...  74 75


                                Рейтинг@Mail.ru
                                [ Script Execution time: 0,1605 ]   [ 15 queries used ]   [ Generated: 19.09.18, 22:32 GMT ]