Re[8]: MSVC2010 + C99 - C/C++

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

P>ну вот поверьте точно также конструктор копирования

КК какого объекта?

В случае интерфейсов объект явно заявляет, что он это может, и у всех таких объектов можно проверить,что интерфейс реализован верно...

E>>Во-первых, ошибка хорошо локализуется, во-вторых, хорошо делится ответственность...
E>>А в случе шаблонов фиг чего и где потребуешь, а если и потребуешь, то это бует всё равно на втой страх и риск и только. Формально среда разработки тебе не поможет...

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

1>Если вы знаете, что токае ассемблерный листинг, то уж должны то понимать, почему на С++ нельзя писать код более быстрый, чем на С. Равный да. Медленней да. Быстрей нет.

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

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

P>>ну вот поверьте точно также конструктор копирования

E>КК какого объекта?

который копируете

E>В случае интерфейсов объект явно заявляет, что он это может, и у всех таких объектов можно проверить,что интерфейс реализован верно...

в случае с KK, объект явно заявляет что у него есть KK, и у всех таких объектов можно проверить этот КК

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

P>который копируете

Ну и как формально получить список всех объектов у которых надо проверить это свойство?

Когда я в коде просто требую поддержки интерфейса, а там, где этот интерфейс поддержал, я и проверяю, что поддержал его удачно, то такая схема хорошо работает. А с шаблонами не понятно как всё это устроить.

не понятно как полчуить исчерпывающий список шаблонов, которые это свойство требует, и как получить исчерпывающий список типов, от которых это свойство требуют...

P>в случае с KK, объект явно заявляет что у него есть KK, и у всех таких объектов можно проверить этот КК

Я очень боюсь тебя расстроить, но в С++ КК есть вообще У ВСЕХ структур и классов. Просто у некоторых из них он таков, что программа сожержащая реальный вызов такого КК illformed...

Но, тем не менее, формально он есть у всех объектов...

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

P>>который копируете

E>Ну и как формально получить список всех объектов у которых надо проверить это свойство?

E>Когда я в коде просто требую поддержки интерфейса, а там, где этот интерфейс поддержал, я и проверяю, что поддержал его удачно, то такая схема хорошо работает. А с шаблонами не понятно как всё это устроить.
E>не понятно как полчуить исчерпывающий список шаблонов, которые это свойство требует,

все шаблонны, которые копируют объекты

E>и как получить исчерпывающий список типов, от которых это свойство требуют...

все те типы, которые хоть где-то копируют

научить?

P>>в случае с KK, объект явно заявляет что у него есть KK, и у всех таких объектов можно проверить этот КК

E>Я очень боюсь тебя расстроить, но в С++ КК есть вообще У ВСЕХ структур и классов. Просто у некоторых из них он таков, что программа сожержащая реальный вызов такого КК illformed...

E>Но, тем не менее, формально он есть у всех объектов...

опять лезешь в бутылку.
проверяем все типы, которые not illformed на копирование

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

E>>и как получить исчерпывающий список типов, от которых это свойство требуют...

P>все те типы, которые хоть где-то копируют

P>научить?

Ну научи, только оно не должно ругаться на валидные случаи использования std::auto_ptr

P>проверяем все типы, которые not illformed на копирование

И получаем, что std::auto_ptr не валиден. Грустно плачем и несём С++/STL на помоечку?

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

E>>>и как получить исчерпывающий список типов, от которых это свойство требуют...

P>>все те типы, которые хоть где-то копируют

P>>научить?

E>Ну научи, только оно не должно ругаться на валидные случаи использования std::auto_ptr

например таким подходом:

Finder.addMatcher(
      ConstructorCall(
          HasDeclaration(Method(HasName(StringConstructor))),
          ArgumentCountIs(2),
          // The first argument must have the form x.c_str() or p->c_str()
          // where the method is string::c_str().  We can use the copy
          // constructor of string instead (or the compiler might share
          // the string object).
          HasArgument(
              0,
              Id("call", Call(
                  Callee(Id("member", MemberExpression())),
                  Callee(Method(HasName(StringCStrMethod))),
                  On(Id("arg", Expression()))))),
          // The second argument is the alloc object which must not be
          // present explicitly.
          HasArgument(
              1,
              DefaultArgument())),
      &Callback);

http://llvm.org/svn/llvm-project/cfe/branches/tooling/tools/remove-cstr-calls/RemoveCStrCalls.cpp

P>>проверяем все типы, которые not illformed на копирование

E>И получаем, что std::auto_ptr не валиден. Грустно плачем и несём С++/STL на помоечку?

нет, хотя бы потому, что std::auto_ptr это не STL

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

P>например таким подходом:

P>

P>Finder.addMatcher(
P>      ConstructorCall(
P>          HasDeclaration(Method(HasName(StringConstructor))),
P>          ArgumentCountIs(2),
P>          // The first argument must have the form x.c_str() or p->c_str()
P>          // where the method is string::c_str().  We can use the copy
P>          // constructor of string instead (or the compiler might share
P>          // the string object).
P>          HasArgument(
P>              0,
P>              Id("call", Call(
P>                  Callee(Id("member", MemberExpression())),
P>                  Callee(Method(HasName(StringCStrMethod))),
P>                  On(Id("arg", Expression()))))),
P>          // The second argument is the alloc object which must not be
P>          // present explicitly.
P>          HasArgument(
P>              1,
P>              DefaultArgument())),
P>      &Callback);
P>

P>http://llvm.org/svn/llvm-project/cfe/branches/tooling/tools/remove-cstr-calls/RemoveCStrCalls.cpp
Ничего не понял...

Вот у меня есть программа. На С++, доступны исходники. Что я делаю, что бы проверить?

P>нет, хотя бы потому, что std::auto_ptr это не STL

1) Standard Template Library описана во второй половине стандарта С++, и std::auto_ptr вроде как там был...

2) Суть вопроса-то была в другом. У меня может быть МОЙ класс, со свойствами, как у auto_ptr, мало того, у меня может быть МОЙ контейнер, который корректно работает с auto_ptr...

Как твои формальный проверки шаблонов это всё прожуют?

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

P>>например таким подходом:
E>Ничего не понял...

E>Вот у меня есть программа. На С++, доступны исходники. Что я делаю, что бы проверить?

запускаете эту тулзу такого рода — она всё ищет. если нужно ещё и исправит.

P>>нет, хотя бы потому, что std::auto_ptr это не STL

E>1) Standard Template Library описана во второй половине стандарта С++, и std::auto_ptr вроде как там был...

В STL — нет auto_ptr. http://en.wikipedia.org/wiki/Standard_Template_Library
я наверное сейчас ещё больше шокирую, но в STL ещё и строк нет, и об этом даже сам Степанов говорил, лично.

E>2) Суть вопроса-то была в другом. У меня может быть МОЙ класс, со свойствами, как у auto_ptr, мало того, у меня может быть МОЙ контейнер, который корректно работает с auto_ptr...
E>Как твои формальный проверки шаблонов это всё прожуют?

сначала нужно определится дефектен auto_ptr с точки зрения проекта, или нет.

это точно также как определится, легально ли объекту с интерфейсом Copybale форматировать жёсткий диск или нет.

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

P>запускаете эту тулзу такого рода — она всё ищет. если нужно ещё и исправит.
Так как она "исправит" std::auto_ptr?..

И где гарантии, что она не налажает, кстати?

P>>>нет, хотя бы потому, что std::auto_ptr это не STL

E>>1) Standard Template Library описана во второй половине стандарта С++, и std::auto_ptr вроде как там был...

P>В STL — нет auto_ptr. http://en.wikipedia.org/wiki/Standard_Template_Library
P>я наверное сейчас ещё больше шокирую, но в STL ещё и строк нет, и об этом даже сам Степанов говорил, лично.

Что говорил там Степанов, или что в вики кто пишет -- это всё интересно в смысле биографии этих персон. Но у С++ есть стандарт, как бы...

E>>2) Суть вопроса-то была в другом. У меня может быть МОЙ класс, со свойствами, как у auto_ptr, мало того, у меня может быть МОЙ контейнер, который корректно работает с auto_ptr...
E>>Как твои формальный проверки шаблонов это всё прожуют?

P>сначала нужно определится дефектен auto_ptr с точки зрения проекта, или нет.

Нет, не дефектен. У него есть вполне логичная и понятная парадигма использования. Положим, что в проекте её придерживаются...

P>это точно также как определится, легально ли объекту с интерфейсом Copybale форматировать жёсткий диск или нет.
Очеивдно, что не валидно, в смысле через интерфейс копирования, не валидно, а через какой-то иной, может и валидно....

ОБЧНО ИНТЕРФЕЙС СПЕЦИФИЦИРУЕТ ПОВЕДЕНИЕ!!!

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

P>>запускаете эту тулзу такого рода — она всё ищет. если нужно ещё и исправит.
E>Так как она "исправит" std::auto_ptr?..

"если нужно" это вообще, а не конкретно про auto_ptr.
но если нужно например заменить auto_ptr на unique_ptr — она справится без проблем.

E>И где гарантии, что она не налажает, кстати?

в каком именно месте слажает? при поиске или исправлении?

какие у тебя гарантии что тест интерфейсов не слажает?

P>>>>нет, хотя бы потому, что std::auto_ptr это не STL

E>>>1) Standard Template Library описана во второй половине стандарта С++, и std::auto_ptr вроде как там был...

P>>В STL — нет auto_ptr. http://en.wikipedia.org/wiki/Standard_Template_Library
P>>я наверное сейчас ещё больше шокирую, но в STL ещё и строк нет, и об этом даже сам Степанов говорил, лично.
E>Что говорил там Степанов, или что в вики кто пишет -- это всё интересно в смысле биографии этих персон. Но у С++ есть стандарт, как бы...

ну а где в стандарте написано что autp_ptr относится к STL ???

P>>это точно также как определится, легально ли объекту с интерфейсом Copybale форматировать жёсткий диск или нет.
E>Очеивдно, что не валидно, в смысле через интерфейс копирования, не валидно, а через какой-то иной, может и валидно....

E>ОБЧНО ИНТЕРФЕЙС СПЕЦИФИЦИРУЕТ ПОВЕДЕНИЕ!!!

ну и? у auto_ptr интерфейс тоже специфицирует поведение

template<class Y>
  auto_ptr (auto_ptr<Y>& a) throw();

const тут нет

нужен похожий класс, но без модифицирующего копирования используйте unique_ptr или scoped_ptr

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

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

P>>>запускаете эту тулзу такого рода — она всё ищет. если нужно ещё и исправит.
E>>Так как она "исправит" std::auto_ptr?..

P>"если нужно" это вообще, а не конкретно про auto_ptr.
P>но если нужно например заменить auto_ptr на unique_ptr — она справится без проблем.

auto_ptr<my_struct>foo();
void bar( auto_ptr<my_struct> data_4_take_in_ounership );
void xxx()
{
    bar( foo() );
}

на что исправит?

P>в каком именно месте слажает? при поиске или исправлении?
При поиске в обоих смыслах и при исправлении?

P>какие у тебя гарантии что тест интерфейсов не слажает?
Ну найти всех наследников чего-то -- относительно простая задача, в отличии от полного парсинга С++ всех версий...

Кроме того, я ещё раз повторюсь, что интерфейс поддерживают ЯВНО, тогда же программист может регистрировать класс, поддерживающий интерфейс, в юнит-тестилке...

P>ну а где в стандарте написано что autp_ptr относится к STL ???

К стандартной библиотеке шаблонов? Ну во второй части. Точный раздел на память не помню...
Я тут подозреваю, что ты считаешь, что STL -- это только некоторое наследие кода Степанова. Это вроде бы довольно произвольно определимое множество. Ну да фиг бы с ним.

P>ну и? у auto_ptr интерфейс тоже специфицирует поведение

P>template<class Y>
P>  auto_ptr (auto_ptr<Y>& a) throw();
P>

P>const тут нет

P>нужен похожий класс, но без модифицирующего копирования используйте unique_ptr или scoped_ptr

Не понятно, как формально потребовать от класса именно вот копируемости, а не чего-то ещё.
И это ещё простой расклад. А свойств у параметра шаблона может быть туча...
Например, скоуп, в которой определён параметр, операторы и внешние функции с ним, и т. д...

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

P>>>>запускаете эту тулзу такого рода — она всё ищет. если нужно ещё и исправит.
E>>>Так как она "исправит" std::auto_ptr?..

P>>"если нужно" это вообще, а не конкретно про auto_ptr.
P>>но если нужно например заменить auto_ptr на unique_ptr — она справится без проблем.
E>

E>auto_ptr<my_struct>foo();
E>void bar( auto_ptr<my_struct> data_4_take_in_ounership );
E>void xxx()
E>{
E>    bar( foo() );
E>}

на что исправит?

что конкретно нужно исправить?
заменить все копирования auto_ptr на move unique_ptr ?

P>>в каком именно месте слажает? при поиске или исправлении?
E>При поиске в обоих смыслах и при исправлении?

а почему она должна слажать — то же самое AST используется при компиляции

P>>какие у тебя гарантии что тест интерфейсов не слажает?
E>Ну найти всех наследников чего-то -- относительно простая задача, в отличии от полного парсинга С++ всех версий...

не спорю

E>Кроме того, я ещё раз повторюсь, что интерфейс поддерживают ЯВНО, тогда же программист может регистрировать класс, поддерживающий интерфейс, в юнит-тестилке...

а тулза такого рода, может сама регистрировать классы которые можно копировать

P>>ну а где в стандарте написано что autp_ptr относится к STL ???

E>К стандартной библиотеке шаблонов? Ну во второй части. Точный раздел на память не помню...
E>Я тут подозреваю, что ты считаешь, что STL -- это только некоторое наследие кода Степанова. Это вроде бы довольно произвольно определимое множество. Ну да фиг бы с ним.

есть STL. А есть C++ Standard Library

E>Не понятно, как формально потребовать от класса именно вот копируемости, а не чего-то ещё.

потребовать или проверить?

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

P>ну и? у auto_ptr интерфейс тоже специфицирует поведение

P>template<class Y>
P>  auto_ptr (auto_ptr<Y>& a) throw();
P>

P>const тут нет

Не хочу тебя расстраивать в очередной раз, но это не КК, так как КК в С++ не может быть шаблонным методом...

P>нужен похожий класс, но без модифицирующего копирования используйте unique_ptr или scoped_ptr

Нет, задача совсем другая, нам нужно
1) При разработке std::vector как-то заметить, что std::auto_ptr нам не подходит.
2) Как-то потребовать в std::vector копируемости, а не так, как у std::auto_ptr...

и то и то шаблоны, как минимум "не помогают" сделать. В этом их беда.

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

P>что конкретно нужно исправить?
P>заменить все копирования auto_ptr на move unique_ptr ?

Тут конкретно, ничего менять не надо. Это валидный код.
Но если у меня есть шаблон karusel<T>, который таки ждёт от T нормальной копируемости, но программист этого явно не выразил, так как не знал как выразить и не имел никакого инструмента заметить, чо ему это свойство надо, так вот, надо выявит, что karusel<auto_ptr<ZZZ>> -- ошибка...

P>есть STL. А есть C++ Standard Library
Это какая-то лингвистическая магия. Типа "Стандартная Библиотека Шаблонов" или "Стандартный библиотечный шаблон"...

P>потребовать или проверить?
Ну вот я написал шаблон какой-то.
Теперь мне хорошо бы как-то получить список свойств, которые я от своего аргумента требую + как-то проверить все используемые аргументы, на наличие этих свойств.
Ещё бы не кисло было бы заявить требования этих свойств явно, что бы программист сразу же и не пытался бы...

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

P>>ну и? у auto_ptr интерфейс тоже специфицирует поведение

P>>

P>>template<class Y>
P>>  auto_ptr (auto_ptr<Y>& a) throw();
P>>

P>>const тут нет

E>Не хочу тебя расстраивать в очередной раз, но это не КК, так как КК в С++ не может быть шаблонным методом...

знаю я, не то скопировал:

auto_ptr (auto_ptr& a) throw();

P>>нужен похожий класс, но без модифицирующего копирования используйте unique_ptr или scoped_ptr

E>Нет, задача совсем другая, нам нужно
E>1) При разработке std::vector как-то заметить, что std::auto_ptr нам не подходит.
E>2) Как-то потребовать в std::vector копируемости, а не так, как у std::auto_ptr...

очень просто: сделать функцию/метод которая принимает const auto_ptr& и внутри пытается скопировать. runtime overhead = 0
или опять не то?

E>и то и то шаблоны, как минимум "не помогают" сделать. В этом их беда.

помогают.
когда будут концепции — будет ещё лучше..

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

P>>>нужен похожий класс, но без модифицирующего копирования используйте unique_ptr или scoped_ptr

E>>Нет, задача совсем другая, нам нужно
E>>1) При разработке std::vector как-то заметить, что std::auto_ptr нам не подходит.
E>>2) Как-то потребовать в std::vector копируемости, а не так, как у std::auto_ptr...

P>очень просто: сделать функцию/метод которая принимает const auto_ptr& и внутри пытается скопировать. runtime overhead = 0
P>или опять не то?

1) Если эта функция не используется, то С++ её не обязан компилировать.
2) Это всё очень неявно и непонятно.
3) Ну и "При разработке std::vector как-то заметить, что std::auto_ptr нам не подходит" никак не поддержано тоже...

P>когда будут концепции — будет ещё лучше..

Да не будет лучше. Будет больше иллюзий

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

P>>что конкретно нужно исправить?
P>>заменить все копирования auto_ptr на move unique_ptr ?
E>Тут конкретно, ничего менять не надо. Это валидный код.
E>Но если у меня есть шаблон karusel<T>, который таки ждёт от T нормальной копируемости, но программист этого явно не выразил, так как не знал как выразить и не имел никакого инструмента заметить, чо ему это свойство надо, так вот, надо выявит, что karusel<auto_ptr<ZZZ>> -- ошибка...

заменяешь auto_ptr на unique_ptr — и смотришь что поломалось

P>>есть STL. А есть C++ Standard Library
E>Это какая-то лингвистическая магия. Типа "Стандартная Библиотека Шаблонов" или "Стандартный библиотечный шаблон"...

нет

P>>потребовать или проверить?
E>Ну вот я написал шаблон какой-то.
E>Теперь мне хорошо бы как-то получить список свойств, которые я от своего аргумента требую + как-то проверить все используемые аргументы, на наличие этих свойств.
E>Ещё бы не кисло было бы заявить требования этих свойств явно, что бы программист сразу же и не пытался бы...

http://www2.research.att.com/~bs/bs_faq2.html#constraints

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

P>>>>нужен похожий класс, но без модифицирующего копирования используйте unique_ptr или scoped_ptr

E>>>Нет, задача совсем другая, нам нужно
E>>>1) При разработке std::vector как-то заметить, что std::auto_ptr нам не подходит.
E>>>2) Как-то потребовать в std::vector копируемости, а не так, как у std::auto_ptr...

P>>очень просто: сделать функцию/метод которая принимает const auto_ptr& и внутри пытается скопировать. runtime overhead = 0
P>>или опять не то?

E>1) Если эта функция не используется, то С++ её не обязан компилировать.

всё используется http://www2.research.att.com/~bs/bs_faq2.html#constraints .
в крайнем случае перед одним из копированний ставите const и всё.

E>2) Это всё очень неявно и непонятно.

как раз таки явно

E>3) Ну и "При разработке std::vector как-то заметить, что std::auto_ptr нам не подходит" никак не поддержано тоже...
P>>когда будут концепции — будет ещё лучше..
E>Да не будет лучше. Будет больше иллюзий

ну хз.. точно также можно сказать про интерфейсы — одни илюзии

ЗP>>>>>нет, хотя бы потому, что std::auto_ptr это не STL

P>>>В STL — нет auto_ptr. http://en.wikipedia.org/wiki/Standard_Template_Library
E>>Что говорил там Степанов, или что в вики кто пишет -- это всё интересно в смысле биографии этих персон. Но у С++ есть стандарт, как бы...

ИМХО, что там Cтепанов говорил, сугубо ортогонально всем тем кто пишет на реальном C++, а не на словах Степанова. В референс реализации HP/SGI, которую все в том или ином виде передрали — auto_ptr есть.

P>ну а где в стандарте написано что autp_ptr относится к STL ???

В стандарте ISO/IEC 14882 в разделе 20.4.5 Class template auto_ptr. STL же в стандарте вообще нигде не упоминается. Собственно STL к С++ имеет ровно то же отношение что и MFC. Однако для простоты STL ака Standard Template Library приравнивается к стандартной библиотеке C++. Что как бы очевидно.

	От:	Erop
	Дата:	23.06.12 19:05
	Оценка:

	От:	Erop
	Дата:	23.06.12 19:55
	Оценка:	3 (1) +1

	От:	Piko
	Дата:	23.06.12 19:55
	Оценка:

	От:	Erop
	Дата:	23.06.12 20:00
	Оценка:

	От:	Piko
	Дата:	23.06.12 20:04
	Оценка:

	От:	Alexéy Sudachén
	Дата:	24.06.12 04:01
	Оценка:	+1