Ш>>> автоматическое преобразование типов тут не причем. В данной конструкции оно не выполняется.
VD>> это и есть неявное приведение типов. Делается оно компилятором, но дела это не меняет.
> Ещё раз повторяю, нет в этом месте в C++ никаких неявных преобразований типа. Исторически, типа bool в C и раннем C++ просто не было.
"Шахтер мне друг, но истина дороже"
Спецификация C++ требует в данном случае преобразования к bool:
6.4/4 The value of a condition that is an initialized declaration in a statement other than a switch statement is the value of the declared variable implicitly converted to type bool. If that conversion is ill-formed, the program is ill-formed.
Posted via RSDN NNTP Server 1.8
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
В форуме С++ в одном топике возникла мысль, которую я сейчас думаю.
С++, вслед за С имеет массу неявных преобразований. При создании нового класса мы можем неявные преобразования с новым типом запретить. Но со встроенными типами мы такое следать не можем — только написав классы-оболочки.
Попадался ли вам язык, в котором был бы реализован не запрет (чего в языках практически нет), а наоборот — разрешение? То есть по умолчанию нет НИКАКИХ неявных преобразований, ВСЕ надо писать явно. Но если мы хотим сократить запись, мы можем прописать что-то вроде using
using static_cast<signeg int, unsigned int>
Ну, как префикс namespace разрешаем не писать, используя using
ИМХО, это существенно повысило бы надежность ПО.
Ы???????
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
А что тут такого? Нужен лишь строго типизированный язык, использующий другую модель работы с памятью нежели С++. В той или иной степени — это например C#
Здравствуйте, Шахтер, Вы писали:
Ш>У кого баги? У меня их нет.
Вот именно у тех у кого их нет, обычно в релизе... уже у заказчика... вылезают очень неприятные бяки. А они говорят, да это ламеры напортачили. Я тут не причем.
Ш> А насчет сплошь и рядом, специально для такого случая во всех современных компиляторах есть соответсвующий варнинг на конструкцию if( a=b ).
Это самый простой случай. Бываю и менее явные.
Ш>Но правда, отморозки вроде меня, этот ворнинг сразу прибивают, чтобы не мешал работать.
Потому как считают себя круче паравоза. А потом сидят и орут: "Бот, блин, глюкадром а не компилятор! Руки у них там в [далее следует название компилятора] кривые!..."
Ш>И, кстати говоря, автоматическое преобразование типов тут не причем. В данной конструкции оно не выполняется. В шарпе, в отличии от C++, if( ) принимает только bool аргумент, а в C++ можно засунуть любое целое или указатель.
Ага. Не применяестя. if это не логическая инструкция. Ему конкретная цифра требуется.
Близ, это и есть неявное приведение типов. Делается оно компилятором, но дела это не меняет.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
Ш>>У кого баги? У меня их нет.
VD>Вот именно у тех у кого их нет, обычно в релизе... уже у заказчика... вылезают очень неприятные бяки. А они говорят, да это ламеры напортачили. Я тут не причем.
Ш>> А насчет сплошь и рядом, специально для такого случая во всех современных компиляторах есть соответсвующий варнинг на конструкцию if( a=b ).
VD>Это самый простой случай. Бываю и менее явные.
Ш>>Но правда, отморозки вроде меня, этот ворнинг сразу прибивают, чтобы не мешал работать.
VD>Потому как считают себя круче паравоза. А потом сидят и орут: "Бот, блин, глюкадром а не компилятор! Руки у них там в [далее следует название компилятора] кривые!..."
Я бы посоветовал отвечать не за других, а за себя.
C/С++ менее дуракоустойчивы чем C#. Поэтому требуют более серьёзного к себе отношения.
Ш>>И, кстати говоря, автоматическое преобразование типов тут не причем. В данной конструкции оно не выполняется. В шарпе, в отличии от C++, if( ) принимает только bool аргумент, а в C++ можно засунуть любое целое или указатель.
VD>Ага. Не применяестя. if это не логическая инструкция. Ему конкретная цифра требуется.
VD>Близ, это и есть неявное приведение типов. Делается оно компилятором, но дела это не меняет.
Ещё раз повторяю, нет в этом месте в C++ никаких неявных преобразований типа. Исторически, типа bool в C и раннем C++ просто не было.
Hello, LaptevVV!
You wrote on Fri, 26 Mar 2004 15:51:34 GMT:
L> В форуме С++ в одном топике возникла мысль, которую я сейчас думаю. L> С++, вслед за С имеет массу неявных преобразований. При создании нового L> класса мы можем неявные преобразования с новым типом запретить. Но со L> встроенными типами мы такое следать не можем — только написав L> классы-оболочки. Попадался ли вам язык, в котором был бы реализован не L> запрет (чего в языках практически нет), а наоборот — разрешение? То есть L> по умолчанию нет НИКАКИХ неявных преобразований, ВСЕ надо писать явно. L> Но если мы хотим сократить запись, мы можем прописать что-то вроде using
L>
L> using static_cast<signeg int, unsigned int>
L>
L> Ну, как префикс namespace разрешаем не писать, используя using L> ИМХО, это существенно повысило бы надежность ПО.
А если б еще вместо explicit приходилось писать implicit, наличие любого указателя в классе приводило бы к запрету генерации дефолтного конструктора копирования и оператора присваивания, это ж вообще рулез был бы немерянный
Best regards,
Sergey.
Posted via RSDN NNTP Server 1.8 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, LaptevVV, Вы писали:
LVV>В форуме С++ в одном топике возникла мысль, которую я сейчас думаю. LVV>С++, вслед за С имеет массу неявных преобразований. При создании нового класса мы можем неявные преобразования с новым типом запретить. Но со встроенными типами мы такое следать не можем — только написав классы-оболочки. LVV>Попадался ли вам язык, в котором был бы реализован не запрет (чего в языках практически нет), а наоборот — разрешение? То есть по умолчанию нет НИКАКИХ неявных преобразований, ВСЕ надо писать явно. Но если мы хотим сократить запись, мы можем прописать что-то вроде using
LVV>
LVV>Ну, как префикс namespace разрешаем не писать, используя using LVV>ИМХО, это существенно повысило бы надежность ПО.
LVV>Ы???????
Наоборот. Типично запретительная логика. Она не работает. В жизни будет так. Поскольку конверсии между фундаментальными типами приходится делать довольно часто, и по делу, все эти разрешения будут писаться автоматически, без обдумывания последствий. Со всеми вытекающими. Или как вариант -- разрешат програмистам в проекте использовать только int, например, опять же со всеми вытекающими.
Здравствуйте, LaptevVV, Вы писали:
LVV>ИМХО, это существенно повысило бы надежность ПО.
LVV>Ы???????
объемы кода это бы точно повысило. Больше ничего.
Когда пишешь что-нить с WinAPI, так там надо целую кучу явных преобразований писать. И что, это кому-то помогало?
Приравняв явные и неявные преобразования, ты не сделаешь безопаснее вторые. Вместо этого ты сделаешь еще опаснее первые.
Ибо привыкнув приводить вручную, большинство будет не раздумывая приводить всё подряд ко всему подряд.
A>signed char c;
A>int b = c; // Никаких причин требовать явного преобразования
A>long a = b; // Никаких причин требовать явного преобразования
A>
Пардон, не совсем то имел ввиду. Мое правило звучит так:
Простые с виду операции не должны долго выполняться. К примеру, на интуитивном уровне операция присваивания выглядит, как простая. (выполняется за пару тактов.) Но в случае сложных объектов это не так. Короче,
В вашем примере я бы написал так же, как и вы.
Но в таком примере:
Здравствуйте, LaptevVV, Вы писали:
LVV>В форуме С++ в одном топике возникла мысль, которую я сейчас думаю. LVV>С++, вслед за С имеет массу неявных преобразований. При создании нового класса мы можем неявные преобразования с новым типом запретить. Но со встроенными типами мы такое следать не можем — только написав классы-оболочки. LVV>Попадался ли вам язык, в котором был бы реализован не запрет (чего в языках практически нет), а наоборот — разрешение? То есть по умолчанию нет НИКАКИХ неявных преобразований, ВСЕ надо писать явно. Но если мы хотим сократить запись, мы можем прописать что-то вроде using
LVV>
LVV>Ну, как префикс namespace разрешаем не писать, используя using LVV>ИМХО, это существенно повысило бы надежность ПО.
LVV>Ы???????
Это надо будет создавать большой файл в котором будут рассмотрены все неявные преобразования возможные в программе.
1 — преобразование указателя в int.
int* ptr;
if(ptr) ...
как это описывать ?
using static_cast<int*,bool>
или
using static_cast<int*,int>
а для всех указателей :
template<typename T> using static_cast<T*,bool>
?
2 — разные программы.
Возможна будет ситуация, когда одна программа не скомпилируется из-за того , что использовалась библиотека от другой , где преобразование не разрешено было.
Вывод — нужно просто более типизированный язык , как было сказано выше, для этого просто в стандарт С/С++ внести соответствующие поправки, правда после этого это уже не будет С/С++ какой был задуман...
__>Это надо будет создавать большой файл в котором будут рассмотрены все неявные преобразования возможные в программе.
__>1 — преобразование указателя в int.
Гы. Если речь идет о безопасности программирования, то указатели нуно запрещать в первую очередь.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
Ш>Наоборот. Типично запретительная логика. Она не работает. В жизни будет так. Поскольку конверсии между фундаментальными типами приходится делать довольно часто, и по делу, все эти разрешения будут писаться автоматически, без обдумывания последствий. Со всеми вытекающими. Или как вариант -- разрешат програмистам в проекте использовать только int, например, опять же со всеми вытекающими.
А ничего, что из-за автоматического преобразования bool <-> int в С++ сплош и рядом баги вроде этого:
if (a = b)
a--;
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
Ш>>Наоборот. Типично запретительная логика. Она не работает. В жизни будет так. Поскольку конверсии между фундаментальными типами приходится делать довольно часто, и по делу, все эти разрешения будут писаться автоматически, без обдумывания последствий. Со всеми вытекающими. Или как вариант -- разрешат програмистам в проекте использовать только int, например, опять же со всеми вытекающими.
VD>А ничего, что из-за автоматического преобразования bool <-> int в С++ сплош и рядом баги вроде этого[/b]: VD>
VD>if (a = b)
VD> a--;
VD>
У кого баги? У меня их нет. А насчет сплошь и рядом, специально для такого случая во всех современных компиляторах есть соответсвующий варнинг на конструкцию if( a=b ).
Но правда, отморозки вроде меня, этот ворнинг сразу прибивают, чтобы не мешал работать.
И, кстати говоря, автоматическое преобразование типов тут не причем. В данной конструкции оно не выполняется. В шарпе, в отличии от C++, if( ) принимает только bool аргумент, а в C++ можно засунуть любое целое или указатель.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, LaptevVV, Вы писали:
VD>В Шарпе разрешены только безопасные преобразования и ест возможность реализовать собственные преоборазования.
VD>В Васике.Нэт вообще есть опция запрещающая все неявные преобразования.
VD>В обоих случаях даже явные преобрзования контролируются и не мокут привести к серьезным проблемам.
Здравствуйте, Шахтер, Вы писали:
Ш>Я бы посоветовал отвечать не за других, а за себя.
Посоветуй.
Кому, кстати?
И еще ему посоветуй не оверквоить так сильно.
Ш>C/С++ менее дуракоустойчивы чем C#. Поэтому требуют более серьёзного к себе отношения.
Это называется типобезопасный. Но, это по научному вам не понять. (с) Райкин.
Ш>Ещё раз повторяю, нет в этом месте в C++ никаких неявных преобразований типа. Исторически, типа bool в C и раннем C++ просто не было.
Это называется астигматизм. Но это тоже по научному.
Если же серьезно, то в С++ и шаблонов небыло и много еще чего другого. А тип bool появился, но что он есть что его нет. Разницы никаой нет.
Ну, как по научному это называется, ты уж сам придумай.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.