Убрать бессмысленное предупреждение компилятора

Новый комментарий
 
  • 21% (16)
  • 79% (61)
Всего проголосовало: 77
 
Скажите, вам это предупреждение кажется нужным или доставляет лишь головную боль? Я считаю его назойливым и абсолютно бесполезным. Стоит отметить, что "взрослые" компиляторы не ругаются по этому поводу (ну может какой-нибудь флаг для параноиков имеется, но в -Wall он не попадает).

class Q {
   int a;
public:
   void f(int a) {}  // declaration of 'a' hides member declaration
};


Вроде мелочь, но очень раздражает, заставляет "украшать" подчёркиваниями аргументы (добавлять m_ к членам, кому как нравится). Не верю в успешность просьб о введении уровней предупреждений, поэтому предлагаю убрать данное по результатам голосования.

ЗЫ: если кто не в курсе - доступ к обеим переменным возможен внутри функции: 
void f(int a) {this.a = a;}
 
pavlick_:
  • Убрать предупреждение
    17% (1)
  • Оставить как есть
    83% (5)
да убрать. Это выбешивает и заставляет использовать уродливые префиксы m_ g_ , то есть принуждает к плохому.
 
pavlick_:
Скажите, вам это предупреждение кажется нужным или доставляет лишь головную боль? Я считаю его назойливым и абсолютно бесполезным. Стоит отметить, что "взрослые" компиляторы не ругаются по этому поводу (ну может какой-нибудь флаг для параноиков имеется, но в -Wall он не попадает).

А по-моему, это очень нужное и правильное предупреждение, какое не должно появляться в правильно написанной программе.

Люди-титаны запоминания вроде Петера Конова, конечно, могут помнить, какие у них и где переменные объявлены. А те, у кого память похуже - будут только благодарны за подобное предупреждение, и переименуют идентификаторы так, чтобы коллизии быть не могло.

И насчет "подчеркивания аргументами" - считаю это обязательным признаком хорошего тона, плюс начало каждой переменной должно указывать на ее тип. Следование данным принципам - не раз позволяло мне избегать хитрых ошибок.

 

Georgiy Merts:

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

По-моему, это всё давно неактуально (как кодировать имена пользовательских типов - структуры, классы). Да и современное программирование происходит не в блокноте и всякие clang based инструменты (как и интел сенс) с легкостью подскажут тип и место объявления.

 

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Баг компилятора: 'operator=' - structure have objects and cannot be copied

Alexey Navoykov, 2018.09.10 08:43

Если структуры и классы предназначены для локального одноразового применения, то удобней их размещать непосредственно по месту использования, чем размазывать код и захламлять пространство имён.

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Баг компилятора: 'operator=' - structure have objects and cannot be copied

Alexey Navoykov, 2018.09.10 09:39

С названиями классов приходилось выкручиваться через дефайны, а оказывается ещё и с локальными переменными надо помучаться )   И вот как в таком хаосе работать...

Я уже неоднократно предлагал разработчикам ввести наконец namespace, но там всё глухо как в танке.

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Баг компилятора: 'operator=' - structure have objects and cannot be copied

Alexey Navoykov, 2018.09.10 09:58

Когда всё свалено в одну кучу, то крах неизбежен )  Захотите подключить чью-то библиотеку, а тут окажется что её автор пишет так же "примитивно" как и вы, используя такие же имена классов и функций.
 
pavlick_:

По-моему, это всё давно неактуально (как кодировать имена пользовательских типов - структуры, классы). Да и современное программирование происходит не в блокноте и всякие clang based инструменты (как и интел сенс) с легкостью подскажут тип и место объявления.

Да ?

Какие инструменты тебе позволят найти ошибку в данном коде ? 

for (i = 0; i<j; ++i)
   {
   Print("Небольшой цикл");
   };

А вот если этот код будет выглядеть вот так:

char cI = NULL;
uint uiJ = 500;

// Много строк пропущено.

for (сI = 0; cI < uiJ; ++cI)
   {
   Print("Небольшой цикл");
   };

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

 
Georgiy Merts:

Да ?

Какие инструменты тебе позволят найти ошибку в данном коде ?

А вот если этот код будет выглядеть вот так:

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

Вы поймите - всё это очень круто в случае простого Си, без перегрузок, без сложных пользовательских типов. Этот пример может выглядеть так:

uchar f(uint);
uint f(uchar);

for (сI = 0; cI < f(uiJ); ++cI)
   {
   Print("Небольшой цикл");
   };

// или
class Q{
  operator int();
};

теперь что, к каждом экземпляру Q присобачивать i_? А какой префикс для f()? Вся эта венгерская нотация даёт сбои в чём-то сложнее Си, значит в помойку, на мой взгляд. Надо трезвым код писать, в момент написаня, вообще нет представления о том, что с чем сравниваете?

ЗЫ:

И да, симпатичные портянки будут

class Very_complex_class_name{
};
Very_complex_class_name Very_complex_class_name_fn();
 
Всё должно быть, как в С. Там есть это предупреждение. Но можно ввести #pragma warning(disable: xxxx) по аналогии с вижаком.
 
Предупреждение оставить, сторонникам отмены поотрубать руки, дабы неповадно было.
 
pavlick_:

Вы поймите - всё это очень круто в случае простого Си, без перегрузок, без сложных пользовательских типов. Этот пример может выглядеть так:

теперь что, к каждом экземпляру Q присобачивать i_? А какой префикс для f()? Вся эта венгерская нотация даёт сбои в чём-то сложнее Си, значит в помойку, на мой взгляд. Надо трезвым код писать, в момент написаня, вообще нет представления о том, что с чем сравниваете?

ЗЫ:

И да, симпатичные портянки будут

У меня - много сложных пользовательских типов, а уж перегрузку я использую сплошь и рядом - очень широко использую виртуализацию. И никаких проблем с венгерской нотацией у меня не было. Все переменные у меня начинаются с маленькой буквы, с названия типа, и дальше - название переменных в "CamelCase" стиле. Для переменных-членов класса - начало с префикса m_. Для функций - названия в "CamelCase" стиле с большой буквы, причем, для глобальных функций - название начинается с символа подчеркивания.

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

"Портянки" - да, иногда у меня получаются очень длинные. Но, с другой стороны - это цена понятности кода. Собственно, я периодически выкладываю свои коды - можно видеть, как они организованы.  

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

12
Новый комментарий