Предлагаю в этой ветке собрать все что по вашему мнению нужно добавить в стандарт. После чего послать запрос комитетчикам.
1)template typedef
2)Атрибут на функцию обязательна к определению во ВСЕХ потомках
3)Статические конструкторы/деструкторы. Должны быть созданы для ВСЕХ полных инстационирований шаблона.
4)Анонимные методы те
Создается функтор который имеет доступ к локальным переменным
int sum=0;
for_each(v.begin(), v.end(),
void(int i)
{
sum+=i;
}
);
Тоже но еще может достучатся до не статических челенов класса
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>А что мешает сделать так
ТОРМОЗА!
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, lboss, Вы писали:
L>1. Вложенные классы — это те, что могут быть только членами других классов и имееют указатель на этот класс... (так проще делать вложенные объекты — например контролы в диалоге)...
Хм. Полезно. L>2. Статические конструкторы
Я уже предложил. L>3. Если будет мета программинг — тоже классно.
Расшифруй пожалуйста. Что именно ты под этим понимаешь. L>4. Замена трем точкам (функциям с переменным числом параметров) — вариантов много...
А по конкретней можно?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
1. интерфейсы пора уже ввести — виртуальное наследование не очень прикольно...
2. Утилитные классы — это те что добавляют в класс функциональность не меняя его (но имеющие доступ к приватным полям)- например утилиты для работы с именем файла...
Зачем это надо? Для ослабления зависимостей. Иногда ради одного такого определения приходится включать целый файл, содержащий кучу других ненужных в данном случае объявлений.
Здравствуйте, NightWind, Вы писали:
NW>2) Часто реализуемые разработчиками компиляторов расширения языка, проблема то что они реализуются везде по разному. Такие как property и closure и д.р.
Полностью поддерживаю
Правда, до конца не уверен, в том что у того же BCB с __property нет никаких проблем — в том смысле что нельзя делать логические ляпы.
Например, насколько я помню (проверить лень), компилятор из BCB3 разрешает передачу свойства в качестве не константного ссылочного аргумента функции, хотя, что естественно, изменения-то не сохраняются. В прочем, возможно, в последнем BCB это уже запрещено.
А __closure - это да, нирвана
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
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. Утилитные классы — это те что добавляют в класс функциональность не меняя его (но имеющие доступ к приватным полям)- например утилиты для работы с именем файла...
Совершенное излишество. Есть, например, классы-примеси.
Здравствуйте, Аноним, Вы писали:
А>property — всего лишь синтаксическое приукрашивание. С ним есть определенные вопросы. Например, если p — свойство, в BC++B запрещена конструкция x = p = y. И вправду, каков должен быть ее смысл: ( set_p(y), x = get_p() ) или ( set_p(y), x = y ) — ?
Скорее всего — первый вариант. Вот что я нашел в своих исходниках
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, lboss, Вы писали:
L>>1. интерфейсы пора уже ввести — виртуальное наследование не очень прикольно...
А>Что-то ты напутал кислое с пресным.
Аргументы? Или просто наезд?
L>>2. Утилитные классы — это те что добавляют в класс функциональность не меняя его (но имеющие доступ к приватным полям)- например утилиты для работы с именем файла...
А>Совершенное излишество. Есть, например, классы-примеси.
Угу — а попробуй в std::string getbuffer сделать...
А> // 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
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Андрей, Вы писали:
А> Ну ведь в классическом случае оно как-то работает
"Классический" — это в котором пишут "class A;"? Там все работает по той простой
причине, что для декорирования имен вся нужная информация уже присутствует: известно,
что это класс, известно из какого namespace и т.п. В случае "typedef A;" совершенно
неясно, что на самом деле A следует декорировать так же, как и std::vector<B>.
А> Жаль...
Та да...
Posted via RSDN NNTP Server 1.5 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Аноним, Вы писали:
NW>>1) Сссылку на ссылку А>Нет, это полная бессмыслица. Ссылка может быть только на объект (и только тогда она осмыслена), а сама ссылка объектом не является.
Дело не в осмысленности, а в "затычке" для принципиального упрощения реализации некоторых темплейтов, например std::bind2nd. Разрешить ссылку на ссылку — значит всего лишь рассматривать ее как ссылку на изначальный нессылочный тип. Противоречий в этом не больше чем в операции & для массивов.
Как все запущенно...
Re[4]: C++ дополнения
От:
Аноним
Дата:
09.06.03 11:56
Оценка:
Здравствуйте, Владик, Вы писали:
NW>>>1) Сссылку на ссылку А>>Нет, это полная бессмыслица. Ссылка может быть только на объект (и только тогда она осмыслена), а сама ссылка объектом не является.
В>Дело не в осмысленности, а в "затычке" для принципиального упрощения реализации некоторых темплейтов, например std::bind2nd. Разрешить ссылку на ссылку — значит всего лишь рассматривать ее как ссылку на изначальный нессылочный тип. Противоречий в этом не больше чем в операции & для массивов.
Здравствуйте, Аноним, Вы писали:
А>Стандарт уже содержит все, что нужно.
Что именно ты имеешь ввиду? То, что указанную проблему можно обойти — я знаю. Вопрос только в удобстве и практике. А практика такая, что современные популярные компиляторы с идущими вместе с ними STL имеют вполне реальные проблемы с этим самым bind2nd и т.п.
Как все запущенно...
Re[6]: C++ дополнения
От:
Аноним
Дата:
09.06.03 12:16
Оценка:
Здравствуйте, Владик, Вы писали:
В>... современные популярные компиляторы с идущими вместе с ними STL имеют вполне реальные проблемы с этим самым bind2nd и т.п.
Значит, надо улучшать степень соответствия существующих компиляторов стандарту, а не изменять стандарт.
Здравствуйте, Аноним, Вы писали:
А>Значит, надо улучшать степень соответствия существующих компиляторов стандарту, а не изменять стандарт.
Видишь ли, разработчиков STL тоже можно понять — писать в 2 раза больше (если не в 5) никому не хочется, когда и так "как-то" работает. Тоже самое, кстати, касается и return void — конструкция бредовая, зато "дешево, надежно и практично".
Здравствуйте, 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 и компанию
W> //Не могут быть определены конструкторы/деструктор
W> //но пустые protected виртуальный деструктор, конструктор по умолчанию,
W> //копирующий конструктор, копирующие присваивание создюется автоматически
W> //Может быть наследован только от интерфейса(ов)
W> //Не может содержать данные
W>
Не пойму, почему это нельзя реализовать через public virtual наследование?
W> Что забыл?
Posted via RSDN NNTP Server 1.5 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, WolfHound
WH>Что забыл?
Мне например, больше всего нехватает хэщей.
А из тог, что ты перечислил, по моему, самое полезное — boost::lambda.
If the milk turns out to be sour,
I ain't the kind of pussy to drink it
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Это не так просто, как кажется. Насколько я знаю, у многих есть твердое желание иметь ПК>подобную функциональность в языке, но есть серьезные вопросы, на которые нет однозначных ПК>ответов: можно ли возвращать полученные подобным образом объекты из функций,
Нет ибо эти обьекты имею доступ к контексту функции. Болие того они становятся не валидными при выходе из облости видимости те
void(*fnPtr)(int);
{
int i=0;
fnPtr=void(int x)//Создается не видимый, автоматический (не временный) обьект
{
i+=x;
};
//Тут валидно
{
//Тут валидно
}
//Тут валидно
}
//Тут невалидно
//И вобще он уже разрушился
ПК>если да, то как будет освобождаться память этого объекта, как гарантировать невозможность доступа ПК>к контексту закончившей выполнение функции и т.п.
ИМХО из серии
Some& Fumc()
{
Some some;
return some;
}
Наступил — сам дурак.
ПК>Большой вопрос, стоит ли усложнять интерфейс библиотеки без добавления новой ПК>функциональности.
Ну сокращение клиентского кода ИМХО вещь не маловажная.
ПК>Кроме того, в некоторых случаях количество перегруженных ПК>шаблонов растет нелинейно, и далеко не во всех случаях в принципе существует ПК>возможность предоставить подобные интерфейсы. Например:
Уверен?
А 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) А. Эйнштейн
Здравствуйте, 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
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
W>> Уверен? W>> А VC++7.1 с тобой не согласен <...>
ПК>Это не совсем то, что я написал Например, у тебя происходит копирование ПК>контейнеров для вызова каждого алгоритма. Хотя, конфликтов, возможно, чуть ПК>меньше, чем я указал, они, все же есть:
VC++7.1 и это нормально схавал
А ссылку на стандарт где говорится что это не должно компилиться можно?
... << RSDN@Home 1.0 beta 6a >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Вот в что раскручивается вызов 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
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.
Здравствуйте, Lorenzo_LAMAS, Вы писали:
LL>А мне так кажется, что ссылка на стандарт тут не обязательна — КОМО очень информативные сообщения об ошибках выдал
хъ LL>Ведь согласись, все очевидно.
Я читать умею. Но ты на 100% уверен что комо всегда прав? ИМХО это нельзя сказать ни об одном компиляторе.
... << RSDN@Home 1.0 beta 6a >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн