В форуме С++ в одном топике возникла мысль, которую я сейчас думаю.
С++, вслед за С имеет массу неявных преобразований. При создании нового класса мы можем неявные преобразования с новым типом запретить. Но со встроенными типами мы такое следать не можем — только написав классы-оболочки.
Попадался ли вам язык, в котором был бы реализован не запрет (чего в языках практически нет), а наоборот — разрешение? То есть по умолчанию нет НИКАКИХ неявных преобразований, ВСЕ надо писать явно. Но если мы хотим сократить запись, мы можем прописать что-то вроде using
using static_cast<signeg int, unsigned int>
Ну, как префикс namespace разрешаем не писать, используя using
ИМХО, это существенно повысило бы надежность ПО.
Ы???????
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
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 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
А что тут такого? Нужен лишь строго типизированный язык, использующий другую модель работы с памятью нежели С++. В той или иной степени — это например C#
Здравствуйте, 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>В обоих случаях даже явные преобрзования контролируются и не мокут привести к серьезным проблемам.
Здравствуйте, Шахтер, Вы писали:
Ш>У кого баги? У меня их нет.
Вот именно у тех у кого их нет, обычно в релизе... уже у заказчика... вылезают очень неприятные бяки. А они говорят, да это ламеры напортачили. Я тут не причем.
Ш> А насчет сплошь и рядом, специально для такого случая во всех современных компиляторах есть соответсвующий варнинг на конструкцию 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++ просто не было.
Здравствуйте, Шахтер, Вы писали:
Ш>Я бы посоветовал отвечать не за других, а за себя.
Посоветуй.
Кому, кстати?
И еще ему посоветуй не оверквоить так сильно.
Ш>C/С++ менее дуракоустойчивы чем C#. Поэтому требуют более серьёзного к себе отношения.
Это называется типобезопасный. Но, это по научному вам не понять. (с) Райкин.
Ш>Ещё раз повторяю, нет в этом месте в C++ никаких неявных преобразований типа. Исторически, типа bool в C и раннем C++ просто не было.
Это называется астигматизм. Но это тоже по научному.
Если же серьезно, то в С++ и шаблонов небыло и много еще чего другого. А тип bool появился, но что он есть что его нет. Разницы никаой нет.
Ну, как по научному это называется, ты уж сам придумай.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ш>>> автоматическое преобразование типов тут не причем. В данной конструкции оно не выполняется.
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
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен