Предлагаю в этой ветке собрать все что по вашему мнению нужно добавить в стандарт. После чего послать запрос комитетчикам.

1)template typedef
2)Атрибут на функцию обязательна к определению во ВСЕХ потомках
3)Статические конструкторы/деструкторы. Должны быть созданы для ВСЕХ полных инстационирований шаблона.
4)Анонимные методы те
Создается функтор который имеет доступ к локальным переменным

    int sum=0;
    for_each(v.begin(), v.end(), 
        void(int i)
        {
            sum+=i;    
        }
    );

Тоже но еще может достучатся до не статических челенов класса

    int sum=0;
    for_each(v.begin(), v.end(), 
        void this(int i)
        {
            sum+=SomeMemberFunction(i);    
        }
    );

5)Добавить в STL сигнатуры типа

template<class T, class F>
F for_each(T& t, F f)
{
    return for_each(t.begin(), t.end(), f);
}

6)Добавить boost::shared_ptr и компанию
7)Добавить boost\lambda
8)typeof
9)Интерфейсы те

//Не могут быть определены конструкторы/деструктор
//но пустые protected виртуальный деструктор, конструктор по умолчанию, 
//копирующий конструктор, копирующие присваивание создюется автоматически
//
//Может быть наследован только от интерфейса(ов)
//
//Не может содержать данные
//
//По умолчанию pablic
interface ISome1
{
    virtual void Some1()=0;
    virtual void Some2()=0;
};
interface ISome2
    :ISome1
{
    virtual void Some3()=0;
    virtual void Some4()=0;
};
struct CSome1:ISome1
{
};
struct CSome2:ISome2
{
};
struct CSome:CSome1,CSome2
{
    virtual void Some1(){}
    virtual void Some2(){}
    virtual void Some3(){}
    virtual void Some4(){}
};
int main()
{
    ISome1* some=new CSome();//Ошибки не будет ибо будет выбран ЛЮБОЙ ISome1 тк они безразличны
}

Что забыл?

IMHO стоит добавить:
1) Сссылку на ссылку
2) Часто реализуемые разработчиками компиляторов расширения языка, проблема то что они реализуются везде по разному. Такие как property и closure и д.р.
3) Добавить все нововведения стандарта C99, иначе C/C++ совсем разойдуться (хотя возможно это и к лучшему)
Вроде больше ничего не приходит в голову...

WolfHound
Честно говоря, я не понял некоторые пункты , название о многом не говорит...
Но кое что мне кажется не нужно, конечно IMHO

Анонимные методы
Я думаю не стоит этого делать, т.к. Функтор — это артефакт STL и воодить его в язык, как то странно.
Что мешает написать обычный функтор???
Да и с реализацией такого механизма возможно возникнут проблемы...

Добавить в STL сигнатуры типа
Опять таки протеворечит духу STL, итераторы созданы чтобы абстрагироваться от контейнеров, а вы наоборот...
Да и кто мешает написатьэту функцию... Или если очень хочется такой define:

#define BEG_END( arg ) arg.begin(), arg.end() 
исоответственно 
for_each( BEG_END( T ), f );

typeof
Я наверно не совсем понял, но так есть же уже typeid и dynamic_cast...

Интерфейсы
А что мешает сделать так
[code]
struct ISome1
{
virtual void Some1()=0;
virtual void Some2()=0;
};
struct ISome2: public virtual ISome1
{
virtual void Some3()=0;
virtual void Some4()=0;
};
struct CSome1: public virtual ISome1
{
};
struct CSome2: public ISome2
{
};
struct CSome:public CSome1, public CSome2
{
virtual void Some1(){}
virtual void Some2(){}
virtual void Some3(){}
virtual void Some4(){}
};
int main()
{
ISome1* some=new CSome(); //теперь ISome1 только один, все работает
}

Здравствуйте, WolfHound, Вы писали:

WH>Предлагаю в этой ветке собрать все что по вашему мнению нужно добавить в стандарт. После чего послать запрос комитетчикам.

Я бы добавил:

1. Вложенные классы — это те, что могут быть только членами других классов и имееют указатель на этот класс... (так проще делать вложенные объекты — например контролы в диалоге)...
2. Статические конструкторы
3. Если будет мета программинг — тоже классно.
4. Замена трем точкам (функциям с переменным числом параметров) — вариантов много...

Ну хватит для начала...

Здравствуйте, NightWind, Вы писали:

NW>1) Сссылку на ссылку
Это как? И зачем?

NW>WolfHound
NW>Честно говоря, я не понял некоторые пункты , название о многом не говорит...
NW>Но кое что мне кажется не нужно, конечно IMHO

NW>Анонимные методы
NW>Я думаю не стоит этого делать, т.к. Функтор — это артефакт STL и воодить его в язык, как то странно.
STL это часть языка. К томуже функторы далеко не только там встечаются.
NW>Что мешает написать обычный функтор???
Есть такое понятие локальность.
NW>Да и с реализацией такого механизма возможно возникнут проблемы...
Какие? Не вижу.

NW>Добавить в STL сигнатуры типа
NW>Опять таки протеворечит духу STL, итераторы созданы чтобы абстрагироваться от контейнеров, а вы наоборот...
Да я и многие другие всеравно определяют эти сигнатуры ибо очень удобно и работает для всех контейнеров с begin/end так что никакой привизки не будет. К томуже старые сигнатуры ни кто отменять не собирается.
NW>Да и кто мешает написатьэту функцию... Или если очень хочется такой define:
Вот дефайнов не надо.

NW>typeof
NW>Я наверно не совсем понял, но так есть же уже typeid и dynamic_cast...
И что? typeof это для времени компиляции при создании сложных шаблонов.

NW>Интерфейсы
NW>А что мешает сделать так
ТОРМОЗА!

Здравствуйте, lboss, Вы писали:

L>1. Вложенные классы — это те, что могут быть только членами других классов и имееют указатель на этот класс... (так проще делать вложенные объекты — например контролы в диалоге)...
Хм. Полезно.
L>2. Статические конструкторы
Я уже предложил.
L>3. Если будет мета программинг — тоже классно.
Расшифруй пожалуйста. Что именно ты под этим понимаешь.
L>4. Замена трем точкам (функциям с переменным числом параметров) — вариантов много...
А по конкретней можно?

Да ещё:

1. интерфейсы пора уже ввести — виртуальное наследование не очень прикольно...
2. Утилитные классы — это те что добавляют в класс функциональность не меняя его (но имеющие доступ к приватным полям)- например утилиты для работы с именем файла...

Здравствуйте, WolfHound, Вы писали:

skip

А я бы добавил forward declaration для typedef. То есть, чтобы работало что-то вроде:

// file1.h
struct CMyStruct
{
  // ...
};

typedef std::vector<CMyStruct> CMyVector;


// file2.h
class CMyVector;  // или какое-то новое ключевое слово?


void SomeFunction(const CMyVector& vec);


// file2.cpp
#include "file2.h"
#include "file1.h"


void SomeFunction(const CMyVector& vec)
{
  // ...
}

Зачем это надо? Для ослабления зависимостей. Иногда ради одного такого определения приходится включать целый файл, содержащий кучу других ненужных в данном случае объявлений.

Здравствуйте, WolfHound, Вы писали:

L>>3. Если будет мета программинг — тоже классно.
WH>Расшифруй пожалуйста. Что именно ты под этим понимаешь.

ну например http://home.fnal.gov/~wb/metaprogramming.ppt

L>>4. Замена трем точкам (функциям с переменным числом параметров) — вариантов много...
WH>А по конкретней можно?

Например вызов итератора для таких параметров — чтоб можно было проверить тип и правильно сложить...
Основная идея в typesafe'ости...

Пример:

Декларируем:

   class PrintfParams
   {
   public:
     template <class T>
     PrintfParams & operator , (T val);
   };
   void printf(const char * format, [PrintfParams]);

Юзаем:

   printf("%d, %s", 10, "Test");

Превращается в:

   {
      PrintfParams tmpParams;
      tmpParams.operator , (10);
      tmpParams.operator , ("Test");
      printf("%d, %s", tmpParams);
   }

L>4. Замена трем точкам (функциям с переменным числом параметров) — вариантов много...

А зачем их заменять?

Здравствуйте, NightWind, Вы писали:

NW>2) Часто реализуемые разработчиками компиляторов расширения языка, проблема то что они реализуются везде по разному. Такие как property и closure и д.р.

Полностью поддерживаю
Правда, до конца не уверен, в том что у того же BCB с __property нет никаких проблем — в том смысле что нельзя делать логические ляпы.

Например, насколько я помню (проверить лень), компилятор из BCB3 разрешает передачу свойства в качестве не константного ссылочного аргумента функции, хотя, что естественно, изменения-то не сохраняются. В прочем, возможно, в последнем BCB это уже запрещено.

А __closure - это да, нирвана

Здравствуйте, NightWind, Вы писали:

NW>1) Сссылку на ссылку

Нет, это полная бессмыслица. Ссылка может быть только на объект (и только тогда она осмыслена), а сама ссылка объектом не является.

NW>2) Часто реализуемые разработчиками компиляторов расширения языка, проблема то что они реализуются везде по разному. Такие как property и closure и д.р.

property — всего лишь синтаксическое приукрашивание. С ним есть определенные вопросы. Например, если p — свойство, в BC++B запрещена конструкция x = p = y. И вправду, каков должен быть ее смысл: ( set_p(y), x = get_p() ) или ( set_p(y), x = y ) — ?

Типобезопасные делегаты — это уже серьезно, хотя есть и пути обхода, скажем, реализация событийных интерфейсов. Но удобство делегатов в некоторых применениях просто огромно — так же как использование классов в Си++ в сравнении с эмуляцией ОО-стиля на Си.

NW>3) Добавить все нововведения стандарта C99, иначе C/C++ совсем разойдуться (хотя возможно это и к лучшему)

Некоторые нововведения Си действительно очень важны (по крайней мере для меня — в работе с вещественными числами и restricted). Но, с другой стороны, это разные языки, и Си++, наверное, не стоит быть уж очень низкоуровневым.

NW>Анонимные методы
NW>Я думаю не стоит этого делать, т.к. Функтор — это артефакт STL и воодить его в язык, как то странно.

Замечу, STL — часть языка.

Здравствуйте, lboss, Вы писали:

L>1. интерфейсы пора уже ввести — виртуальное наследование не очень прикольно...

Что-то ты напутал кислое с пресным.

L>2. Утилитные классы — это те что добавляют в класс функциональность не меняя его (но имеющие доступ к приватным полям)- например утилиты для работы с именем файла...

Совершенное излишество. Есть, например, классы-примеси.

Здравствуйте, Аноним, Вы писали:

А>property — всего лишь синтаксическое приукрашивание. С ним есть определенные вопросы. Например, если p — свойство, в BC++B запрещена конструкция x = p = y. И вправду, каков должен быть ее смысл: ( set_p(y), x = get_p() ) или ( set_p(y), x = y ) — ?

Скорее всего — первый вариант. Вот что я нашел в своих исходниках

void TREGUnitData::Terminator(TREGBasePersonData* pEmployer)
{
 m_fkTerminator=m_TerminatorPtr=pEmployer;
}

m_fkTerminator и m_TerminatorPtr — это смарт указатели разных классов у которых определены:

• self_type& operator = (TREGBasePersonData* pEmployer);
  
• operator TREGBasePersonData* ()const;

получается последовательность вызовов

• присвоить m_TerminatorPtr
  
• прочитать из m_TerminatorPtr
  
• присвоить m_fkTerminator

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, lboss, Вы писали:

L>>1. интерфейсы пора уже ввести — виртуальное наследование не очень прикольно...

А>Что-то ты напутал кислое с пресным.

Аргументы? Или просто наезд?

L>>2. Утилитные классы — это те что добавляют в класс функциональность не меняя его (но имеющие доступ к приватным полям)- например утилиты для работы с именем файла...

А>Совершенное излишество. Есть, например, классы-примеси.

Угу — а попробуй в std::string getbuffer сделать...

Здравствуйте, SWW, Вы писали:

L>>4. Замена трем точкам (функциям с переменным числом параметров) — вариантов много...

SWW>А зачем их заменять?

Затем, что:
1. Не type safe'но это...
2. Многие фичи сделать нельзя — например прокси...

Здравствуйте, Андрей, Вы писали:

А>

А> // file1.h
А> struct CMyStruct { };
А> typedef std::vector<CMyStruct> CMyVector;

А> // file2.h
А> class CMyVector;  // или какое-то новое ключевое слово?
А> void SomeFunction(const CMyVector& vec);
А>

А> Зачем это надо? Для ослабления зависимостей.

Ты лучше расскажи, как оно будет работать Например, при вызове SomeFunction
из файла file2.cpp, не включающего file.h, компилятор не будет иметь возможности
правильно составить декорированное имя для SomeFunction.

Здравствуйте, Павел Кузнецов, Вы писали:

skip

Ну ведь в классическом случае оно как-то работает
Хотя по большому счету ты прав — проблем будет больше, чем пользы. Жаль...

Здравствуйте, Андрей, Вы писали:

А> Ну ведь в классическом случае оно как-то работает

"Классический" — это в котором пишут "class A;"? Там все работает по той простой
причине, что для декорирования имен вся нужная информация уже присутствует: известно,
что это класс, известно из какого namespace и т.п. В случае "typedef A;" совершенно
неясно, что на самом деле A следует декорировать так же, как и std::vector<B>.

А> Жаль...

Та да...

Здравствуйте, Аноним, Вы писали:

NW>>1) Сссылку на ссылку
А>Нет, это полная бессмыслица. Ссылка может быть только на объект (и только тогда она осмыслена), а сама ссылка объектом не является.

Дело не в осмысленности, а в "затычке" для принципиального упрощения реализации некоторых темплейтов, например std::bind2nd. Разрешить ссылку на ссылку — значит всего лишь рассматривать ее как ссылку на изначальный нессылочный тип. Противоречий в этом не больше чем в операции & для массивов.

Здравствуйте, Владик, Вы писали:

NW>>>1) Сссылку на ссылку
А>>Нет, это полная бессмыслица. Ссылка может быть только на объект (и только тогда она осмыслена), а сама ссылка объектом не является.

В>Дело не в осмысленности, а в "затычке" для принципиального упрощения реализации некоторых темплейтов, например std::bind2nd. Разрешить ссылку на ссылку — значит всего лишь рассматривать ее как ссылку на изначальный нессылочный тип. Противоречий в этом не больше чем в операции & для массивов.

Стандарт уже содержит все, что нужно.