Re: C++ дополнения
От: Андрей Россия  
Дата: 09.06.03 04:31
Оценка: 4 (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)
{
  // ...
}


Зачем это надо? Для ослабления зависимостей. Иногда ради одного такого определения приходится включать целый файл, содержащий кучу других ненужных в данном случае объявлений.
Re: C++ дополнения
От: lboss Россия  
Дата: 09.06.03 04:21
Оценка: 1 (1)
Здравствуйте, WolfHound, Вы писали:

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


Я бы добавил:

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

Ну хватит для начала...
С уважением Вадим.
Re: C++ дополнения
От: Павел Кузнецов  
Дата: 09.06.03 12:24
Оценка: 1 (1)
Здравствуйте, WolfHound, Вы писали:

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

W> добавить в стандарт. После чего послать запрос комитетчикам.

Не надо. Просто запросов "хочу фичу" в комитет в той или иной форме приходит много. Все они
в конечном итоге игнорируются по одной простой причине: одного желания "фичи" недостаточно.
Кто-то должен проделать всю грязную работу по созданию тестовой реализации и разработке точной
спецификации. Если "хотетель" не может найти кого-нибудь, кто сделает хотя бы первую часть
работы, шансов убедить комитет сделать остальное у него, фактически, нет. Кроме того, желание
что-нибудь добавлять в язык, имхо, должно сопровождаться желанием отслеживать работу комитета
по обработке соответствующих предложений.

W> 1)template typedef


Уже есть formal proposal http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1406.pdf.
Остается сидеть и ждать результатов (будет включено, или нет в следующую версию). При
желании можно помочь авторам formal proposal в уточнениях и дополнениях, или предложить
альтернативное видение в виде другого formal proposal, но уж никак не "хочу фичу".

W> 2)Атрибут на функцию обязательна к определению во ВСЕХ потомках


Без детальной спецификации, включающей описание решаемых проблем, стоимость реализации,
требуемые изменения в стандарте и т.п. — никаких шансов на включение. Разве что можно
ждать, пока кто-нибудь другой предоставит в комитет проработанный formal proposal.

W> 3)Статические конструкторы/деструкторы. Должны быть созданы для ВСЕХ

W> полных инстационирований шаблона.

Аналогично.

W> 4)Анонимные методы те Создается функтор который имеет доступ к локальным переменным

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

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

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

W>
W> template<class T, class F>
W> F for_each(T& t, F f)
W>


Большой вопрос, стоит ли усложнять интерфейс библиотеки без добавления новой
функциональности. Кроме того, в некоторых случаях количество перегруженных
шаблонов растет нелинейно, и далеко не во всех случаях в принципе существует
возможность предоставить подобные интерфейсы. Например:

// [01]
template<class InputIterator1, class InputIterator2>
bool includes(InputIterator1, InputIterator1, InputIterator2, InputIterator2);

// [02]
template<class InputIterator1, class InputIterator2, class BinaryPredicate>
bool includes(InputIterator1, InputIterator1, InputIterator2, InputIterator2, BinaryPredicate);

// сюда нужно добавить шесть перегруженных вариантов:

// [1]
template<class Container1, class InputIterator2>
bool includes(const Container1&, InputIterator2, InputIterator2);

// [2]
template<class InputIterator1, class Container2>
bool includes(InputIterator1, InputIterator1, const Container2&);

// [3]
template<class Container1, class Container2>
bool includes(const Container1&, const Container2&);

// [4]
template<class Container1, class InputIterator2, class BinaryPredicate>
bool includes(const Container1&, InputIterator2, InputIterator2, BinaryPredicate);

// [5]
template<class InputIterator1, class Container2>
bool includes(InputIterator1, InputIterator1, const Container2&, BinaryPredicate);

// [6]
template<class Container1, class Container2, class BinaryPredicate>
bool includes(const Container1&, const Container2&, BinaryPredicate);


При этом, как можно заметить, вариант 1 конфликтует
с вариантоми 2 и 6, а вариант 4 — c 01 и 5.

W> 6)Добавить boost::shared_ptr и компанию


Уже есть formal proposal.
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1431.htm

W> 7)Добавить boost\lambda


Имхо, несколько конфликтует с (4).

Имеется formal proposal:
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1455.htm

W> 8)typeof


formal proposal:
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1478.pdf

W> 9)Интерфейсы те

W>
W> //Не могут быть определены конструкторы/деструктор
W> //но пустые protected виртуальный деструктор, конструктор по умолчанию,
W> //копирующий конструктор, копирующие присваивание создюется автоматически
W> //Может быть наследован только от интерфейса(ов)
W> //Не может содержать данные
W>


Не пойму, почему это нельзя реализовать через public virtual наследование?

W> Что забыл?
Posted via RSDN NNTP Server 1.5 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[2]: C++ дополнения
От: Коваленко Дмитрий Россия http://www.ibprovider.com
Дата: 09.06.03 05:46
Оценка: +1
Здравствуйте, NightWind, Вы писали:

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


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

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

А __closure - это да, нирвана
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
C++ дополнения
От: WolfHound  
Дата: 08.06.03 20:01
Оценка:
Предлагаю в этой ветке собрать все что по вашему мнению нужно добавить в стандарт. После чего послать запрос комитетчикам.

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 тк они безразличны
}


Что забыл?
... << RSDN@Home 1.0 beta 6a >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: C++ дополнения
От: NightWind Россия  
Дата: 08.06.03 21:25
Оценка:
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 только один, все работает
}
Posted via RSDN NNTP Server 1.6 beta
Re[2]: C++ дополнения
От: WolfHound  
Дата: 09.06.03 04:23
Оценка:
Здравствуйте, 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>А что мешает сделать так
ТОРМОЗА!
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: C++ дополнения
От: WolfHound  
Дата: 09.06.03 04:28
Оценка:
Здравствуйте, lboss, Вы писали:

L>1. Вложенные классы — это те, что могут быть только членами других классов и имееют указатель на этот класс... (так проще делать вложенные объекты — например контролы в диалоге)...

Хм. Полезно.
L>2. Статические конструкторы
Я уже предложил.
L>3. Если будет мета программинг — тоже классно.
Расшифруй пожалуйста. Что именно ты под этим понимаешь.
L>4. Замена трем точкам (функциям с переменным числом параметров) — вариантов много...
А по конкретней можно?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: C++ дополнения
От: lboss Россия  
Дата: 09.06.03 04:31
Оценка:
Да ещё:

1. интерфейсы пора уже ввести — виртуальное наследование не очень прикольно...
2. Утилитные классы — это те что добавляют в класс функциональность не меняя его (но имеющие доступ к приватным полям)- например утилиты для работы с именем файла...
С уважением Вадим.
Re[3]: C++ дополнения
От: lboss Россия  
Дата: 09.06.03 05:04
Оценка:
Здравствуйте, 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);
   }
С уважением Вадим.
Re[2]: C++ дополнения
От: SWW Россия  
Дата: 09.06.03 05:32
Оценка:
L>4. Замена трем точкам (функциям с переменным числом параметров) — вариантов много...

А зачем их заменять?
Re[2]: C++ дополнения
От: Аноним  
Дата: 09.06.03 06:07
Оценка:
Здравствуйте, 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 — часть языка.
Re[3]: C++ дополнения
От: Аноним  
Дата: 09.06.03 06:23
Оценка:
Здравствуйте, lboss, Вы писали:

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


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

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


Совершенное излишество. Есть, например, классы-примеси.
Re[3]: C++ дополнения
От: Коваленко Дмитрий Россия http://www.ibprovider.com
Дата: 09.06.03 06:25
Оценка:
Здравствуйте, Аноним, Вы писали:

А>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 — это смарт указатели разных классов у которых определены:

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

-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[4]: C++ дополнения
От: lboss Россия  
Дата: 09.06.03 06:30
Оценка:
Здравствуйте, Аноним, Вы писали:

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


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


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


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

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


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


Угу — а попробуй в std::string getbuffer сделать...
С уважением Вадим.
Re[3]: C++ дополнения
От: lboss Россия  
Дата: 09.06.03 06:32
Оценка:
Здравствуйте, SWW, Вы писали:

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


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


Затем, что:
1. Не type safe'но это...
2. Многие фичи сделать нельзя — например прокси...
С уважением Вадим.
Re[2]: C++ дополнения
От: Павел Кузнецов  
Дата: 09.06.03 09:05
Оценка:
Здравствуйте, Андрей, Вы писали:

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

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


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


Ты лучше расскажи, как оно будет работать Например, при вызове SomeFunction
из файла file2.cpp, не включающего file.h, компилятор не будет иметь возможности
правильно составить декорированное имя для SomeFunction.
Posted via RSDN NNTP Server 1.5 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[3]: C++ дополнения
От: Андрей Россия  
Дата: 09.06.03 09:16
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

skip

Ну ведь в классическом случае оно как-то работает
Хотя по большому счету ты прав — проблем будет больше, чем пользы. Жаль...
Re[4]: C++ дополнения
От: Павел Кузнецов  
Дата: 09.06.03 09:50
Оценка:
Здравствуйте, Андрей, Вы писали:

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


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

А> Жаль...


Та да...
Posted via RSDN NNTP Server 1.5 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[3]: C++ дополнения
От: Владик Россия  
Дата: 09.06.03 11:53
Оценка:
Здравствуйте, Аноним, Вы писали:

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

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

Дело не в осмысленности, а в "затычке" для принципиального упрощения реализации некоторых темплейтов, например std::bind2nd. Разрешить ссылку на ссылку — значит всего лишь рассматривать ее как ссылку на изначальный нессылочный тип. Противоречий в этом не больше чем в операции & для массивов.
Как все запущенно...
Re[4]: C++ дополнения
От: Аноним  
Дата: 09.06.03 11:56
Оценка:
Здравствуйте, Владик, Вы писали:

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

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

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


Стандарт уже содержит все, что нужно.
Re[2]: C++ дополнения
От: AndersZ  
Дата: 09.06.03 12:04
Оценка:
Здравствуйте, NightWind, Вы писали:


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

Если уж на то пошло, функтор — это артефакт старого доброго чистого С. Предлагаемые анонимные методы — вполне логичное его развитие.
Re[5]: C++ дополнения
От: Владик Россия  
Дата: 09.06.03 12:13
Оценка:
Здравствуйте, Аноним, Вы писали:

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


Что именно ты имеешь ввиду? То, что указанную проблему можно обойти — я знаю. Вопрос только в удобстве и практике. А практика такая, что современные популярные компиляторы с идущими вместе с ними STL имеют вполне реальные проблемы с этим самым bind2nd и т.п.
Как все запущенно...
Re[6]: C++ дополнения
От: Аноним  
Дата: 09.06.03 12:16
Оценка:
Здравствуйте, Владик, Вы писали:

В>... современные популярные компиляторы с идущими вместе с ними STL имеют вполне реальные проблемы с этим самым bind2nd и т.п.


Значит, надо улучшать степень соответствия существующих компиляторов стандарту, а не изменять стандарт.
Re[7]: C++ дополнения
От: Владик Россия  
Дата: 09.06.03 12:22
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Значит, надо улучшать степень соответствия существующих компиляторов стандарту, а не изменять стандарт.


Видишь ли, разработчиков STL тоже можно понять — писать в 2 раза больше (если не в 5) никому не хочется, когда и так "как-то" работает. Тоже самое, кстати, касается и return void — конструкция бредовая, зато "дешево, надежно и практично".
Как все запущенно...
Re[2]: C++ дополнения
От: vgrigor  
Дата: 09.06.03 12:27
Оценка:
А не поясните с чего вы решили, что ваши предложения не учтены, другими людьми ?

Если учтены, дайте ссылку, чтобы было понимание у людей.
А то получается типа: собрались мужики у речки на песке, и стали велосипед изобретать.
Винтовку добудешь в бою!
Re: C++ дополнения
От: skyline Россия  
Дата: 09.06.03 15:16
Оценка:
Здравствуйте, WolfHound

WH>Что забыл?

Мне например, больше всего нехватает хэщей.
А из тог, что ты перечислил, по моему, самое полезное — boost::lambda.
If the milk turns out to be sour,
I ain't the kind of pussy to drink it
Re[2]: C++ дополнения
От: WolfHound  
Дата: 09.06.03 16:17
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это не так просто, как кажется. Насколько я знаю, у многих есть твердое желание иметь

ПК>подобную функциональность в языке, но есть серьезные вопросы, на которые нет однозначных
ПК>ответов: можно ли возвращать полученные подобным образом объекты из функций,
Нет ибо эти обьекты имею доступ к контексту функции. Болие того они становятся не валидными при выходе из облости видимости те
void(*fnPtr)(int);
{
    int i=0;
    fnPtr=void(int x)//Создается не видимый, автоматический (не временный) обьект
        {
            i+=x;
        };
    //Тут валидно
    {
        //Тут валидно
    }
    //Тут валидно
}
//Тут невалидно
//И вобще он уже разрушился

ПК>если да, то как будет освобождаться память этого объекта, как гарантировать невозможность доступа
ПК>к контексту закончившей выполнение функции и т.п.
ИМХО из серии
Some& Fumc()
{
    Some some;
    return some;
}

Наступил — сам дурак.

ПК>Большой вопрос, стоит ли усложнять интерфейс библиотеки без добавления новой

ПК>функциональности.
Ну сокращение клиентского кода ИМХО вещь не маловажная.
for_each(mySuperPuperContainer.begin(), mySuperPuperContainer.end(), SomeFunctor);
//или
for_each(mySuperPuperContainer, SomeFunctor);

ПК>Кроме того, в некоторых случаях количество перегруженных
ПК>шаблонов растет нелинейно, и далеко не во всех случаях в принципе существует
ПК>возможность предоставить подобные интерфейсы. Например:
Уверен?
А VC++7.1 с тобой не согласен.
template<class T, class U>
void Test(T, T, U)
{
    std::cout<<"(T, T, U)"<<std::endl;
}
template<class T, class U>
void Test(T, U, U)
{
    std::cout<<"(T, U, U)"<<std::endl;
}
template<class T, class U, class D>
void Test(T, U, D)
{
    std::cout<<"(T, U, D)"<<std::endl;
}
template<class T, class U, class D>
void Test(T, U, U, D)
{
    std::cout<<"(T, U, U, D)"<<std::endl;
}
template<class T, class U, class D>
void Test(T, T, U, D)
{
    std::cout<<"(T, T, U, D)"<<std::endl;
}
template<class T, class U>
void Test(T, T, U, U)
{
    std::cout<<"(T, T, U, U)"<<std::endl;
}

int main()
{
    int i=0;
    float f=0;
    double d=0;
    Test(i, i, f);
    Test(i, f, f);
    Test(i, f, d);

    Test(i, i, f, f);
    Test(i, i, f, d);
    Test(i, f, f, d);
    return 0;
}

Откомилировалось без единого warning'а
Вывод
(T, T, U)
(T, U, U)
(T, U, D)
(T, T, U, U)
(T, T, U, D)
(T, U, U, D)


ПК>Имхо, несколько конфликтует с (4).

Есть не много однако приятней написать так
int sum=0;
for_each(vec, sum+=_1);
//Чем так
for_each(vec, void(int i)
            {
                sum+=i;
            }
        );

Хотя при наличии анонимных методов lambda уже не так спасает.

ПК>Не пойму, почему это нельзя реализовать через public virtual наследование?

Оно вроде какбы медленней. К томуже с интерфейсами понятней и не забудишь про virtual.
... << RSDN@Home 1.0 beta 6a >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: C++ дополнения
От: Павел Кузнецов  
Дата: 10.06.03 12:19
Оценка:
Здравствуйте, WolfHound, Вы писали:

ПК>> Кроме того, в некоторых случаях количество перегруженных

ПК>> шаблонов растет нелинейно, и далеко не во всех случаях в принципе
ПК>> существует возможность предоставить подобные интерфейсы. Например:

W> Уверен?

W> А VC++7.1 с тобой не согласен <...>

Это не совсем то, что я написал Например, у тебя происходит копирование
контейнеров для вызова каждого алгоритма. Хотя, конфликтов, возможно, чуть
меньше, чем я указал, они, все же есть:

template<class T, class U>
void Test(T, T, const U&)
{
    std::cout<<"(T, T, U)"<<std::endl;
}
template<class T, class U>
void Test(const T&, U, U)
{
    std::cout<<"(T, U, U)"<<std::endl;
}
template<class T, class U, class D>
void Test(const T&, const U&, D)
{
    std::cout<<"(T, U, D)"<<std::endl;
}
template<class T, class U, class D>
void Test(const T&, U, U, D)
{
    std::cout<<"(T, U, U, D)"<<std::endl;
}
template<class T, class U, class D>
void Test(T, T, const U&, D)
{
    std::cout<<"(T, T, U, D)"<<std::endl;
}
template<class T, class U>
void Test(T, T, U, U)
{
    std::cout<<"(T, T, U, U)"<<std::endl;
}

int main()
{
    int i=0;
    float f=0;
    double d=0;
    Test(i, i, f);
    Test(i, f, f);
    Test(i, f, d);

    Test(i, i, f, f);
    Test(i, i, f, d);
    Test(i, f, f, d);
    return 0;
}


Comeau C/C++ 4.3.0.1 (Aug 21 2002 15:45:32) for MS_WINDOWS_x86
Copyright 1988-2002 Comeau Computing.  All rights reserved.
MODE:strict warnings C++

"test.cpp", line 39: error: more than one instance of overloaded function
          "Test" matches the argument list:
            function template "Test(T, T, const U &)"
            function template "Test(const T &, const U &, D)"
            argument types are: (int, int, float)
      Test(i, i, f);
      ^

"test.cpp", line 40: error: more than one instance of overloaded function
          "Test" matches the argument list:
            function template "Test(const T &, U, U)"
            function template "Test(const T &, const U &, D)"
            argument types are: (int, float, float)
      Test(i, f, f);
      ^

"test.cpp", line 43: error: more than one instance of overloaded function
          "Test" matches the argument list:
            function template "Test(T, T, const U &, D)"
            function template "Test(T, T, U, U)"
            argument types are: (int, int, float, float)
      Test(i, i, f, f);
      ^

3 errors detected in the compilation of "test.cpp".
Posted via RSDN NNTP Server 1.5 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[2]: C++ дополнения
От: Павел Кузнецов  
Дата: 10.06.03 12:19
Оценка:
Здравствуйте, skyline, Вы писали:

s> Мне например, больше всего нехватает хэщей.


Уже есть formal proposal.
Posted via RSDN NNTP Server 1.5 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[4]: C++ дополнения
От: WolfHound  
Дата: 10.06.03 16:24
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

W>> Уверен?

W>> А VC++7.1 с тобой не согласен <...>

ПК>Это не совсем то, что я написал Например, у тебя происходит копирование

ПК>контейнеров для вызова каждого алгоритма. Хотя, конфликтов, возможно, чуть
ПК>меньше, чем я указал, они, все же есть:

VC++7.1 и это нормально схавал
А ссылку на стандарт где говорится что это не должно компилиться можно?
... << RSDN@Home 1.0 beta 6a >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: C++ дополнения
От: Юнусов Булат Россия  
Дата: 10.06.03 17:53
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

А насчет select1st select2nd чего нибудь сказано? А то без оных асоц. контейнеры в алгоритмы через функтор (совершенно лишний) вставлять приходится.
Re: C++ дополнения
От: Кирпа В.А. Украина  
Дата: 11.06.03 07:08
Оценка:
Здравствуйте, WolfHound, Вы писали:

У меня добавка
Правда она касается не стандарта языка а кодогенератора в компиляторе

Поясню на примере


void func(double *d)
{
 memset(d, 0, 3 * sizeof(double));
}


Вот в что раскручивается вызов memset для этого случая
Как видите умный компилятор понял что длина блока памяти кратна длине DWORD
и достаточно одного цикла rep stosd

00000 57 push edi
00001 8b 7c 24 08 mov edi, DWORD PTR _d$[esp]
00005 b9 06 00 00 00 mov ecx, 6
0000a 33 c0 xor eax, eax
0000c f3 ab rep stosd
0000e 5f pop edi
0000f c3 ret 0



void func(double *d, int n)
{
 memset(d, 0, n * sizeof(double));
}

Ну а в этом случае компилятору уже не хватило сообразительности
что произведение n * sizeof(double) все равно кратно длине DWORD
и он по сути вставил в генерируемый код лишние инструкции

00000 8b 44 24 08 mov eax, DWORD PTR _n$[esp-4]
00004 57 push edi
00005 8b 7c 24 08 mov edi, DWORD PTR _d$[esp]
00009 8d 0c c5 00 00
00 00 lea ecx, DWORD PTR [eax*8]
00010 33 c0 xor eax, eax
00012 8b d1 mov edx, ecx
00014 c1 e9 02 shr ecx, 2
00017 f3 ab rep stosd
00019 8b ca mov ecx, edx //лишнее
0001b 83 e1 03 and ecx, 3 //лишнее
0001e f3 aa rep stosb //лишнее
00020 5f pop edi
00021 c3 ret 0

Та же фигня и при раскрутке вызова memcpy
!0xDEAD
Re[5]: C++ дополнения
От: Lorenzo_LAMAS  
Дата: 11.06.03 07:22
Оценка:
WH>А ссылку на стандарт где говорится что это не должно компилиться можно?

А мне так кажется, что ссылка на стандарт тут не обязательна — КОМО очень информативные сообщения об ошибках выдал

"test.cpp", line 39: error: more than one instance of overloaded function
"Test" matches the argument list:
function template "Test(T, T, const U &)"
function template "Test(const T &, const U &, D)"
argument types are: (int, int, float)
Test(i, i, f);

Ведь согласись, все очевидно.
Of course, the code must be complete enough to compile and link.
Re[6]: C++ дополнения
От: WolfHound  
Дата: 11.06.03 15:01
Оценка:
Здравствуйте, Lorenzo_LAMAS, Вы писали:

LL>А мне так кажется, что ссылка на стандарт тут не обязательна — КОМО очень информативные сообщения об ошибках выдал

хъ
LL>Ведь согласись, все очевидно.
Я читать умею. Но ты на 100% уверен что комо всегда прав? ИМХО это нельзя сказать ни об одном компиляторе.
... << RSDN@Home 1.0 beta 6a >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.