На святое покушаются - C/C++

Обратной совместимости бой!

1.
int x;              // always zero-initialized
int x = void;       // never zero-initialized

2.
std::list::erase();

3.
обязательный override

http://scottmeyers.blogspot.com/2015/11/breaking-all-eggs-in-c.html

Неужели это когда-нибудь случится? Вроде как план неплох

1. лучше бы так:
int x; // error
int x(0); // always zero-initialized
int x(noinit); // never zero-initialized

3. для себя я уже считаю отсутствие override ошибкой

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

VTT>3. для себя я уже считаю отсутствие override ошибкой

Аналогично, но мне интересно как с шаблонами его magic wand/предложение будет работать. Кто-то привёл пример в комментариях:

For the override proposal, a I don't think a magic wand is possible. With templates, you can have code that would be invalid with override and (under proposed rules) invalid without it. Here's an example: http://melpon.org/wandbox/permlink/9DMqAwWXlrpUKBrQ

Код по ссылке

#include <iostream>                                                              
                                                                                 
struct Base1 {                                                                   
};                                                                               
                                                                                 
struct Base2 {                                                                   
  virtual void f() { std::cout << "v1\n"; }                                      
};                                                                               
                                                                                 
template <class Base>                                                            
struct A : Base {                                                                
  void f() { std::cout << "v2\n"; }                                              
};                                                                               
                                                                                 
int main() {                                                                     
  // would be invalid if f was marked override                                   
  A<Base1> a1;                                                                   
  a1.f();                                                                        
                                                                                 
  // under proposed rules would be invalid if f wasn't marked override                
  A<Base2> a2;                                                                   
  a2.f();                                                                        
  return 0;                                                                      
}

Start
v2
v2
0
Finish

С override вообще не согласен. Нет ничего плохого в том, чтобы расширить класс через, скажем, адаптор. Даже если автор оригинального класса это не предусмотрел.

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

E>Неужели это когда-нибудь случится? Вроде как план неплох

Что-то я не фанат этого, особенно magic wands. Просветите — может зря? И он сам, и комментарии уже высказались по поводу макросов и специфичных для разных компиляторов конструкциях на которых предложенную им magic wand заест:

Standard compliance could be a big problem with the wand tool though, and I speak as from experience with MSVC. Correct and compilable that is accepted by MSVC is often not Standard compliant, so I assume Clang would reject it. Equally, MSVC cannot compile many Standard constructs, so a re-written source from Clang may not compile in MSVC. I imagine the latter would be less of an issue if Clang only made very localised changes relevant to the deprecations.

Не MSVC единым же, да и нестандартные препроцессоры на которых любой инструмент заест, приходят на ум. Придётся строить цепочку препроцессор -> magic wand -> компилятор чтобы руками всё в исходнике не править.

Может, я зря это говорю — auto_ptr же выбрасывают, а там никаких magic wands, всё руками править.

И опять же — исключение для шаблонов делать для override?

У меня на счет magic wand сомнений нет, это то самое "внешне слишком заманчивое явление".
Рефакторинг кода после предлагаемых изменений все равно придется делать вручную, или, как минимум, проверять все измененные места.

Такой шаблонный класс мне кажется скорее проблемным местом, которое помогут выявить новый правила.
Например можно нечаянно наплодить ненужных vtable. Или наоборот, если экземпляр такого класса, унаследованный от базового класса с виртуальным методом планируется хранить в гетерогенном контейнере через указатель на базовый, то наверное стоит сделать в нем private деструктор и сам виртуальный метод.

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

VTT>У меня на счет magic wand сомнений нет, это то самое "внешне слишком заманчивое явление".
VTT>Рефакторинг кода после предлагаемых изменений все равно придется делать вручную, или, как минимум, проверять все измененные места.
Угу, не представляю себе автоматические изменения с шаблонами, макросами, расширениями и т.п. Предпочёл бы новый синтаксис и новые guidelines заместо изменения семантики старого. Заодно и const-по-умолчанию повесили бы...

VTT>Например можно нечаянно наплодить ненужных vtable. Или наоборот, если экземпляр такого класса, унаследованный от базового класса с виртуальным методом планируется хранить в гетерогенном контейнере через указатель на базовый, то наверное стоит сделать в нем private деструктор и сам виртуальный метод.
Об этом трюке — делать метод виртуальным в зависимости от подставленной стратегии — я слышал очень давно. Опасаюсь как бы у людей не навернулся переиспользуемый код от таких изменений (если, конечно, кто-то подобным пользовался).

Ну а list::erase/remove у меня особых эмоций не вызывает.

Здравствуйте, enji, Вы писали:
E>Обратной совместимости бой!
Какая-то дичь. Неужели у языка нет больших проблем, нежели вышеуказанные?

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

VTT>1. лучше бы так:
VTT>int x; // error

И весь ранее написанный код на C++ перестает компилироваться.

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

E>3.
E>обязательный override
E>[/c]

вроде мелькало такое предложение

struct X
{
   virtual void f(); // здесь опциональны override
};

explicit struct Y
{
   virtual void f(); // здесь обязательны override
};

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

Что ж поделать. Так вот тоже не будет работать.
AF>[cut=Код по ссылке]
AF>[q]
AF>

AF>#include <iostream>                                                              
                                                                                 
AF>struct Base1 {                                                                   
AF>};                                                                               
                                                                                 
AF>struct Base2 {                                                                   
AF>  virtual void f() { std::cout << "v1\n"; }                                      
AF>};                                                                               
                                                                                 
AF>template <class Base>                                                            
AF>struct A : Base {                                                                
AF>  void f() { std::cout << "v2\n";
Base::f();
AF>   }                                              
AF>};                                                                               
                                                                                 
AF>int main() {                                                                     
AF>  // would be invalid if f was marked override                                   
AF>  A<Base1> a1;                                                                   
AF>  a1.f();                                                                        
                                                                                 
AF>  // under proposed rules would be invalid if f wasn't marked override                
AF>  A<Base2> a2;                                                                   
AF>  a2.f();                                                                        
AF>  return 0;                                                                      
AF>}
AF>

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

VTT>>1. лучше бы так:
VTT>>int x; // error

PD>И весь ранее написанный код на C++ перестает компилироваться.

я всегда переменные при заведении инициирую

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

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

PD>>И весь ранее написанный код на C++ перестает компилироваться.

CEM>я всегда переменные при заведении инициирую

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

Это очень хорошо с твоей стороны

, но не все это делают, да и не всегда это имеет смысл. Просто присвоить 0 — не лучшее решение, а присвоить что-то осмысленное — придется отложить описание до момента, когда это осмысленное можно будет присвоить


int s,r; // и что тут присвоить r ?
scanf("%d\n", &r);
// описание s сюда перенести ? это не всегда хорошо
s = r * r;

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

PD>// и что тут присвоить r ?
0, если scanf навернётся, в s будут чудеса. Это в этом "хорошем" случае ничего страшного, да, но в общем всё может быть плохо. Например, при использовании MS Common Controls, структуры для работы с итемами, LVITEM, TVITEM, если не обнулить, может быть плохо, причём под дебагом будет совершенно другое поведение(более "хорошее"), что ещё больше усложняет отлов ошибки, когда релиз вышел.

PD>scanf("%d\n", &r);
PD>// описание s сюда перенести ? это не всегда хорошо
PD>s = r * r;
иногда и не получится, но в зависимости от использования, если скоп узкий, то да, сюда.

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

CEM>0, если scanf навернётся, в s будут чудеса.

Тебе не кажется, что речь немного не об этом ? Или я должен был написать полный пример корректного ввода с клавиатуры , в конце которого стоит присваивание этой переменной, а без него моя мысль непонятна ?

>Это в этом "хорошем" случае ничего страшного, да, но в общем всё может быть плохо. Например, при использовании MS Common Controls, структуры для работы с итемами, LVITEM, TVITEM, если не обнулить, может быть плохо

Ну если уж на то пошло, не будет с ними плохо, и совсем не обязательно их обнулять, так как нужные поля перечисляются по маске. Обнуление стоит делать только если там много используемых полей, которые и впрямь должны быть равны 0, иначе в этом смысла нет.

https://msdn.microsoft.com/ru-ru/library/windows/desktop/bb774760(v=vs.85).aspx

mask
Type: UINT
Set of flags that specify which members of this structure contain data to be set or which members are being requested. This member can have one or more of the following flags set:

и далее флаги, определяющие , имеют ли смысл те или иные поля. Поля, для которых флаг не установлен, не используются и могут содержать что угодно

CEM>иногда и не получится, но в зависимости от использования, если скоп узкий, то да, сюда.

Вот именно — иногда.

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

CEM>>0, если scanf навернётся, в s будут чудеса.

PD>Тебе не кажется, что речь немного не об этом ? Или я должен был написать полный пример корректного ввода с клавиатуры , в конце которого стоит присваивание этой переменной, а без него моя мысль непонятна ?

Да, получается, непонятна. Я думал, что мысль: зачем интить переменную тут, если её потом скормят функции, и та её в любом случае проинитит, или: переменная будет проиничена в другом месте? В любом случае, в жизни может быть всё

сегодня такой код, а завтра кто-то гипотетический scanf убрал, а между декларацией и инициализацией — 100 строк кода, не посмотрел, что там вверху, и всё...
В общем, raii — это хорошо

и для первой и для второй переменной, в данном случае

>>Это в этом "хорошем" случае ничего страшного, да, но в общем всё может быть плохо. Например, при использовании MS Common Controls, структуры для работы с итемами, LVITEM, TVITEM, если не обнулить, может быть плохо

PD>Ну если уж на то пошло, не будет с ними плохо, и совсем не обязательно их обнулять, так как нужные поля перечисляются по маске. Обнуление стоит делать только если там много используемых полей, которые и впрямь должны быть равны 0, иначе в этом смысла нет.

да, я знаю, но вот "своими глазами видел", как человек не занулил её(структуру) при декларации, и у него релиз не заработал. хр зн как так биты из стека легли

но зануление помогло

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

PD>>Ну если уж на то пошло, не будет с ними плохо, и совсем не обязательно их обнулять, так как нужные поля перечисляются по маске. Обнуление стоит делать только если там много используемых полей, которые и впрямь должны быть равны 0, иначе в этом смысла нет.

CEM>да, я знаю, но вот "своими глазами видел", как человек не занулил её(структуру) при декларации, и у него релиз не заработал. хр зн как так биты из стека легли

но зануление помогло

Очень плохо, что зануление помогло. Это означает, что ошибка так и оказалась невыявленной. Я очень не люблю, когда ошибка исчезает при том, что я не убедился в том, что я ее нашел и исправил. Потенциально такая ситуация означает, что она, возможно, так и не была найдена и исправлена, а решение ad hoc только скрыло ее.

	От:	enji
	Дата:	14.11.15 17:09
	Оценка:	4 (1)

От:	VTT	http://vtt.to
Дата:	14.11.15 17:49
Оценка:	1 (1) +2 -1

	От:	Alexey F
	Дата:	14.11.15 17:59
	Оценка:

	От:	Vamp
	Дата:	14.11.15 18:11
	Оценка:

	От:	Alexey F
	Дата:	14.11.15 18:23
	Оценка:

	От:	Pavel Dvorkin
	Дата:	16.11.15 09:22
	Оценка:	-2

	От:	Alexander G
	Дата:	15.11.15 06:44
	Оценка:

	От:	yatagarasu
	Дата:	15.11.15 13:15
	Оценка:

	От:	CEMb
	Дата:	17.11.15 05:36
	Оценка: