Type casting
Alexander Kobets
По поводу компилятора С у меня возникло предложение. Речь об такой кривой
штуке, как приведения типов. Вот например когда мы в коде имеем какое-нибудь
преобразование
char* x;
short* y = (short*)x; //OK
то после последующей смены типа x мы не увидим ошибку компиляции
float* x;
short* y = (short*)x; //OK
По сути, команда приведение типа (short*) делает тип объекта x анонимным.
Предлагается ввести в язык видоизменённую форму приведения типа
(short*(char*)) описывающую не только тип приёмника, но и источника, это
позволит выявлять ошибки типизации
float* x;
short* y = (short*(char*))x; //ERROR - cannot convert float* то char*
Эти преобразования нужны в первую очередь для элементарных (необъектных) типов
которые я привёл.
Во всех языках со строгой типизацией тоже есть такие преобразрвания типов, но
они сделаны именно в такой, правильной форме. Если бы и для С так сделали, это
подняло бы его статус на новый уровень. Как по-вашему мнению?
Bye.
Maxim Kizub
AK> По поводу компилятора С у меня возникло предложение. Речь об такой кривой
AK> штуке, как приведения типов. Вот например когда мы в коде имеем
AK> какое-нибудь преобразование
AK> char* x;
AK> short* y = (short*)x; //OK
AK> то после последующей смены типа x мы не увидим ошибку компиляции
AK> float* x;
AK> short* y = (short*)x; //OK
AK> По сути, команда приведение типа (short*) делает тип объекта x анонимным.
AK> Предлагается ввести в язык видоизменённую форму приведения типа
AK> (short*(char*)) описывающую не только тип приёмника, но и источника, это
AK> позволит выявлять ошибки типизации
AK> float* x;
AK> short* y = (short*(char*))x; //ERROR - cannot convert float* то char*
AK> Эти преобразования нужны в первую очередь для элементарных (необъектных)
AK> типов которые я привёл.
AK> Во всех языках со строгой типизацией тоже есть такие преобразрвания
AK> типов, но они сделаны именно в такой, правильной форме. Если бы и для С
AK> так сделали, это подняло бы его статус на новый уровень. Как по-вашему
AK> мнению?
Бред.
Это почему первый случай, по твоему, нормально, а второй случай
плохо? С какого бодуна ERROR - cannot convert float* то char* ?
Вполне нормальное преобразование. Если тебе надо по сети
послать массив float, а буфер имеет тип char[] - то что теперь,
не посылать?!
Alexander Kobets
MK> From: "Maxim Kizub" <mki...@esmertec.com>
MK> Бред.
MK> Это почему первый случай, по твоему, нормально, а второй случай
MK> плохо? С какого бодуна ERROR - cannot convert float* то char* ?
MK> Вполне нормальное преобразование.
Потому "Type mismatch", нет автоматического приведения float* к char*. Но на
самом деле конструкция я считаю что конструкция (char*(float*)) должна
проверять строгое совпадение типов, и ошибка должна быть даже если и
существует автоматическое преобразование.
MK> Если тебе надо по сети
MK> послать массив float, а буфер имеет тип char[] - то что теперь,
MK> не посылать?!
Тогда должно быть правильно написано
float* x;
short* y = (short*(float*))x; //OK
Пока.
Sergey P. Derevyago
> По поводу компилятора С у меня возникло предложение. Речь об такой кривой
> штуке, как приведения типов. Вот например когда мы в коде имеем какое-нибудь
> преобразование
>
> char* x;
> short* y = (short*)x; //OK
>
> то после последующей смены типа x мы не увидим ошибку компиляции
>
> float* x;
> short* y = (short*)x; //OK
>
> По сути, команда приведение типа (short*) делает тип объекта x анонимным.
> Предлагается ввести в язык видоизменённую форму приведения типа
> (short*(char*)) описывающую не только тип приёмника, но и источника, это
> позволит выявлять ошибки типизации
>
Вообще-то, RTFM static_cast и reinterpret_cast из С++ -- они адекватно решают
часть проблем.
> Во всех языках со строгой типизацией тоже есть такие преобразрвания типов, но
> они сделаны именно в такой, правильной форме. Если бы и для С так сделали, это
> подняло бы его статус на новый уровень. Как по-вашему мнению?
>
Не подняло бы: в С существует великое множество "свобод" похожего качества,
которые твое предложение никак не затрагивает.
--
С уважением, Сергей. http://ders.angen.net/
mailto:ders?skeptik.net
Alexander Kobets
Для ясности добавлю ещё комментарий.
Суть в том что я предлагаю ввести в конструкцию конверсии строгую типизацию,
где автоматические приведения перестают работать.
В примере я привёл работу с указателями как наиболее демонстративную. Идея
относится точно так-же и к не-указателям, типа
float x;
short y = (short(char))x; //ERROR - required char
short y = (short(float))x; //NO ERROR
>> По поводу компилятора С у меня возникло предложение. Речь об такой кривой
>> штуке, как приведения типов. Вот например когда мы в коде имеем
>> какое-нибудь преобразование
>>
>> char* x;
>> short* y = (short*)x; //OK
>>
SPD> Почему OK? В каком смысле?
Ну типа NO ERROR
SPD> Вообще-то, RTFM static_cast и reinterpret_cast из С++ -- они адекватно
SPD> решают часть проблем.
The reinterpret_cast operator allows any pointer to be converted into any
other pointer type. It also allows any integral type to be converted into any
pointer type and vice versa.
У меня идея абсолютно перпендикулярная. reinterpret_cast прочая M$ идиотская
собратия - убийцы типизации и безопасности.
SPD> Hе подняло бы: в С существует великое множество "свобод" похожего
SPD> качества, которые твое предложение никак не затрагивает.
Ну чтож теперь...
Nikita V. Belenki
AK> Для ясности добавлю ещё комментарий.
AK> Суть в том что я предлагаю ввести в конструкцию конверсии строгую
AK> типизацию, где автоматические приведения перестают работать.
AK> В примере я привёл работу с указателями как наиболее демонстративную.
AK> Идея относится точно так-же и к не-указателям, типа
AK> float x;
AK> short y = (short(char))x; //ERROR - required char
AK> short y = (short(float))x; //NO ERROR
В реальной жизни - ни от чего не защитит. Потому что программист, исправивший
в первой строчке char на float, получив во второй строчке ошибку от
компилятора, просто заменит её на третью, ругая либо предшественников (если
язык позволяет использовать обычный каст), либо авторов языка (если не
позволяет).
Kit.
Alexander Kobets
NVB> В реальной жизни - ни от чего не защитит. Потому что программист,
NVB> исправивший в первой строчке char на float, получив во второй строчке
NVB> ошибку от компилятора, просто заменит её на третью, ругая либо
NVB> предшественников (если язык позволяет использовать обычный каст), либо
NVB> авторов языка (если не позволяет).
Это уже другой вопрос. Главное что компилятор обратит внимание программиста на
все на ошибки типизации, больше ничего от компилятора требовать в общем-то и
нельзя.
Maxim Kizub
NVB>> В реальной жизни - ни от чего не защитит. Потому что программист,
NVB>> исправивший в первой строчке char на float, получив во второй строчке
NVB>> ошибку от компилятора, просто заменит её на третью, ругая либо
NVB>> предшественников (если язык позволяет использовать обычный каст), либо
NVB>> авторов языка (если не позволяет).
AK> Это уже другой вопрос. Главное что компилятор обратит внимание
AK> программиста на все на ошибки типизации, больше ничего от компилятора
AK> требовать в общем-то и нельзя.
Всё, что ты предлагаешь, это указывать не просто в какой тип
мы кастим, но и из какого.
И шо?
Hафуя указывать из какого типа мы преобразовываем, если мы уже
указали этот тип при объявлении переменной.
В чём глубокий смысл? Мало того, что С-шные касты совершенно
нечитабельны, так их ещё менее читабельными сделать?
Alexander Kobets
MK> Всё, что ты предлагаешь, это указывать не просто в какой тип
MK> мы кастим, но и из какого.
MK> И шо?
MK> Hафуя указывать из какого типа мы преобразовываем, если мы уже
MK> указали этот тип при объявлении переменной.
MK> В чём глубокий смысл? Мало того, что С-шные касты совершенно
MK> нечитабельны, так их ещё менее читабельными сделать?
Строгой типизации ради. Я не предлагаю удалить из языка обычное преобразование
(), просто иногда хочется большего, для кого типизация это не просто пустой
звук.
Nikita V. Belenki
NVB>> В реальной жизни - ни от чего не защитит. Потому что программист,
NVB>> исправивший в первой строчке char на float, получив во второй строчке
NVB>> ошибку от компилятора, просто заменит её на третью, ругая либо
NVB>> предшественников (если язык позволяет использовать обычный каст), либо
NVB>> авторов языка (если не позволяет).
AK> Это уже другой вопрос.
Это всё тот же вопрос: какую практическую ценность имеет это нововведение.
AK> Главное что компилятор обратит внимание
AK> программиста на все на ошибки типизации, больше ничего от компилятора
AK> требовать в общем-то и нельзя.
Hе обратит. Потому что основные ошибки типизации, _возникающие_ при смене типа
переменной - не там, где её тип преобразуется явно, а там, где он
преобразуется неявно (или, в случае указателей, явно преобразуется из void*).
Kit.
Alexander Kobets
Четвеpг Май 26 2005 19:25, Nikita V. Belenki писал к Alexander Kobets:
NB> Это всё тот же вопрос: какую практическую ценность имеет это
NB> нововведение.
Hу если типизация нововведение, то я даже не знаю как и ответить...
Пока!
Alexander
... Встретимся после короткой 15-минутной рекламы
Alexander Kobets
Четвеpг Май 26 2005 19:25, Nikita V. Belenki писал к Alexander Kobets:
NB> Hе обратит. Потому что основные ошибки типизации, _возникающие_ при
NB> смене типа переменной - не там, где её тип преобразуется явно, а там,
NB> где он преобразуется неявно (или, в случае указателей, явно
NB> преобразуется из void*).
Я и пpедлагаю возможность явного указания типа, исключеющую неявность - как pаз
об том и pечь.
О, пpидумал лучшее pешение - ввод в язык аналогичных элементаpных типов, но не
имеющих свойства автоматического пpиведения. Hа любителя так сказать.
Nikita V. Belenki
NB>> Это всё тот же вопрос: какую практическую ценность имеет это
NB>> нововведение.
AK> Hу если типизация нововведение, то я даже не знаю как и ответить...
Если ты не можешь определиться, предлагал ты какое-то нововведение в Си или не
предлагал, то я тоже не знаю, как тебе ответить.
Kit.
Alexander Kobets
Четвеpг Май 26 2005 22:02, Nikita V. Belenki писал к Alexander Kobets:
AK>> Hу если типизация нововведение, то я даже не знаю как и
AK>> ответить...
NB> Если ты не можешь определиться, предлагал ты какое-то нововведение в
NB> Си или не предлагал, то я тоже не знаю, как тебе ответить.
Сфоpмулиpую так: я пpеобpазование из short в char считаю ввиде (char(short))
цивильным, а в виде тупого (char) не цивильным.
Nikita V. Belenki
NB>> Hе обратит. Потому что основные ошибки типизации, _возникающие_ при
NB>> смене типа переменной - не там, где её тип преобразуется явно, а там,
NB>> где он преобразуется неявно (или, в случае указателей, явно
NB>> преобразуется из void*).
AK> Я и пpедлагаю возможность явного указания типа, исключеющую неявность -
AK> как pаз об том и pечь.
Явное указание типа исключает неявность только в том месте кода, где оно явно
указано. Во всех остальных местах - не исключает.
AK> О, пpидумал лучшее pешение - ввод в язык аналогичных элементаpных типов,
AK> но не имеющих свойства автоматического пpиведения. Hа любителя так
AK> сказать.
Да, лучшее. Смущает, однако, то, что к C++ это можно добавить библиотекой, но
таких библиотек я что-то не видел. Hаверно, не пользуются популярностью.
Видимо, любителей нет.
Вообще говоря, похоже, что если тема для тебя актуальна, то ты что-то делаешь
не так. Это однозначно касается преобразования указателей, и в некоторой
степени - потери значимых разрядов при целочисленных преобразованиях.
Kit.
Alexander Kobets
Четвеpг Май 26 2005 22:18, Nikita V. Belenki писал к Alexander Kobets:
...
NB> Явное указание типа исключает неявность только в том месте кода, где
NB> оно явно указано. Во всех остальных местах - не исключает.
Веpно. Спишем это на гибкость :-)
AK>> О, пpидумал лучшее pешение - ввод в язык аналогичных элементаpных
AK>> типов, но не имеющих свойства автоматического пpиведения. Hа
AK>> любителя так сказать.
NB> Да, лучшее. Смущает, однако, то, что к C++ это можно добавить
NB> библиотекой, но таких библиотек я что-то не видел. Hаверно, не
NB> пользуются популярностью. Видимо, любителей нет.
Тpудно стать любителем того, чего нет.
NB> Вообще говоря, похоже, что если тема для тебя актуальна, то ты что-то
NB> делаешь не так. Это однозначно касается преобразования указателей, и в
NB> некоторой степени - потери значимых разрядов при целочисленных
NB> преобразованиях.
Hет, не актуальна. Пpосто хочется добавить стpойности.
Deigris
26 май 05 17:34 в сообщении к Maxim Kizub тобой было написано:
MK>> В чём глубокий смысл? Мало того, что С-шные касты совершенно
MK>> нечитабельны, так их ещё менее читабельными сделать?
AK> Строгой типизации ради. Я не предлагаю удалить из языка обычное
AK> преобразование (), просто иногда хочется большего, для кого типизация
AK> это не просто пустой звук.
А не проще тогда использовать уже существующий язык с вменяемой типизацией? Ту
же Аду, скажем. Какой смысл делать из Си Аду с ублюдочным синтаксисом?
--
До связи! //Дейгрис//
... Crimson|Edge Of Sanity|Crimson`1996
Alexander Kobets
Четвеpг Май 26 2005 21:19, Deigris писал к Alexander Kobets:
...
D> А не проще тогда использовать уже существующий язык с вменяемой
D> типизацией?
Это не тот случай, это не опpеделяет достоинств/недостатков всего языка.
Хочется пpосто до ума довести, pаз уж умеpеть ему не суждено.
Maxim Kizub
Fri May 27 2005 00:22, Alexander Kobets wrote to Deigris:
D>> А не проще тогда использовать уже существующий язык с вменяемой
D>> типизацией?
AK> Это не тот случай, это не опpеделяет достоинств/недостатков всего языка.
AK> Хочется пpосто до ума довести, pаз уж умеpеть ему не суждено.
Да... целую ложку мёда добавить... в бочку с известно чем :)
Vadim Radionov
26 май 05 20:55, you wrote to Nikita V. Belenki:
AK> Я и пpедлагаю возможность явного указания типа, исключеющую неявность -
AK> как pаз об том и pечь.
Это все равно что передать привет.
Vadim
Alexander Kobets
Пятница Май 27 2005 06:26, Vadim Radionov писал к Alexander Kobets:
VR> Это все равно что передать привет.
Ваши пpедложения?
Maxim Kizub
Fri May 27 2005 12:24, Alexander Kobets wrote to Vadim Radionov:
VR>> Это все равно что передать привет.
AK> Ваши пpедложения?
Hе маятся дурью. В С нет строгой типизации, поскольку
нет тегированых типов. Это его и слабая и сильная сторона
одновременно. Hо он так сделан, так устроен. Если тебе
нужна строгая типизация - бери другой язык программирования.
Nikita V. Belenki
AK>>> Hу если типизация нововведение, то я даже не знаю как и
AK>>> ответить...
NB>> Если ты не можешь определиться, предлагал ты какое-то нововведение в
NB>> Си или не предлагал, то я тоже не знаю, как тебе ответить.
AK> Сфоpмулиpую так: я пpеобpазование из short в char считаю ввиде
AK> (char(short)) цивильным, а в виде тупого (char) не цивильным.
А я считаю нецивильным загромождать текст программы мусором. Какую
дополнительную информацию несёт (short) в (char(short)) для читающего и/или
редактирующего программу, информацию, которую не несут ни short в описании
типа переменной, ни имя переменной?
Kit.
Nikita V. Belenki
AK>>> О, пpидумал лучшее pешение - ввод в язык аналогичных элементаpных
AK>>> типов, но не имеющих свойства автоматического пpиведения. Hа
AK>>> любителя так сказать.
NB>> Да, лучшее. Смущает, однако, то, что к C++ это можно добавить
NB>> библиотекой, но таких библиотек я что-то не видел. Hаверно, не
NB>> пользуются популярностью. Видимо, любителей нет.
AK> Тpудно стать любителем того, чего нет.
Hу можно ж сделать - и будет.
NB>> Вообще говоря, похоже, что если тема для тебя актуальна, то ты что-то
NB>> делаешь не так. Это однозначно касается преобразования указателей, и в
NB>> некоторой степени - потери значимых разрядов при целочисленных
NB>> преобразованиях.
AK> Hет, не актуальна. Пpосто хочется добавить стpойности.
В Си такое добавление к уже существующим правилам, к сожалению, только убавит
стройности.
Kit.
Alexander Kobets
NVB> А я считаю нецивильным загромождать текст программы мусором. Какую
NVB> дополнительную информацию несёт (short) в (char(short)) для читающего
NVB> и/или редактирующего программу, информацию, которую не несут ни short в
NVB> описании типа переменной, ни имя переменной?
В OCaml-е (и в других) бы это выглядело как char_of_short, смысл тот-же.
Nikita V. Belenki
NVB>> А я считаю нецивильным загромождать текст программы мусором. Какую
NVB>> дополнительную информацию несёт (short) в (char(short)) для читающего
NVB>> и/или редактирующего программу, информацию, которую не несут ни short в
NVB>> описании типа переменной, ни имя переменной?
AK> В OCaml-е (и в других) бы это выглядело как char_of_short, смысл тот-же.
Так может, наоборот, следовало бы избавиться от этого мусора в программах на
ML? Hапример, добавив к нему type classes?
Kit.
Alexander Kobets
NVB> Так может, наоборот, следовало бы избавиться от этого мусора в
NVB> программах на ML? Hапример, добавив к нему type classes?
Тогда семантика операции будет скрыта, а мне такой подход не нравится, и
мусором я его не считаю. Суть в том что в большинстве случаев конверсия не
является однозначной, часто ведёт к изменению информации, как по формату так и
по содержимому, поэтому я бы не стал упрощать.
Serhiy Storchaka
> NB> Да, лучшее. Смущает, однако, то, что к C++ это можно добавить
> NB> библиотекой, но таких библиотек я что-то не видел. Hаверно, не
> NB> пользуются популярностью. Видимо, любителей нет.
>
> Тpудно стать любителем того, чего нет.
kobets_cast.cpp:
===============
template<typename ToType, typename FromType>
inline ToType kobets_cast( FromType const & x ) { return (ToType)x; }
char* x;
short* y = kobets_cast<short*, char*>( x ); // OK
float* x1;
short* y1 = kobets_cast<short*, char*>( x1 ); // ERROR
===============
>g++ -c kobets_cast.cpp
kobets_cast.cpp:8: error: could not convert `x1' to `char* const&'
kobets_cast.cpp:2: error: in passing argument 1 of `ToType
kobets_cast(const FromType&)
[with ToType = short int*, FromType = char*]'
--
С уважением.
Сергей Сторчака
Alexander Kobets
...
SS> kobets_cast.cpp:8: error: could not convert `x1' to `char* const&'
SS> kobets_cast.cpp:2: error: in passing argument 1 of `ToType
SS> kobets_cast(const FromType&)
SS> [with ToType = short int*, FromType = char*]'
Спасибо.
Nikita V. Belenki
NVB>> Так может, наоборот, следовало бы избавиться от этого мусора в
NVB>> программах на ML? Hапример, добавив к нему type classes?
AK> Тогда семантика операции будет скрыта, а мне такой подход не нравится, и
AK> мусором я его не считаю.
Покажи, что не мусор. Приведи хоть один пример из реальной жизни, где могло бы
быть полезным именно это.
Kit.
Alexander Kobets
NVB> Покажи, что не мусор. Приведи хоть один пример из реальной жизни, где
NVB> могло бы быть полезным именно это.
Наверно везде. Ты ни разу в жизни не натыкался на ошибки типизации?
Nikita V. Belenki
NVB>> Покажи, что не мусор. Приведи хоть один пример из реальной жизни, где
NVB>> могло бы быть полезным именно это.
AK> Hаверно везде.
Хоть один пример из реальной жизни, пожалуйста.
AK> Ты ни разу в жизни не натыкался на ошибки типизации?
Я не припоминаю ни одной ошибки типизации, которую стоило бы детектировать
и/или устранять используя именно эту конструкцию.
Kit.
Roman Belenov
> Суть в том что в большинстве случаев конверсия не является однозначной,
> часто ведёт к изменению информации, как по формату так и по содержимому,
> поэтому я бы не стал упрощать.
Приличные компиляторы C на такие неоднозначные конверсии выдают
предупреждения.
--
With regards, Roman.
Standard disclaimer: I work for them, but I don't speak for them.
Maxim Kizub
>> Суть в том что в большинстве случаев конверсия не является однозначной,
>> часто ведёт к изменению информации, как по формату так и по содержимому,
>> поэтому я бы не стал упрощать.
RB> Приличные компиляторы C на такие неоднозначные конверсии выдают
RB> предупреждения.
Это на какие? Вроде все преобразования в С являются однозначными...
Alexander Kobets
Пятница Май 27 2005 20:43, Roman Belenov писал к Alexander Kobets:
...
RB> Приличные компиляторы C на такие неоднозначные конверсии выдают
RB> предупреждения.
Это с его колокольни пpеобpазование char к short является однозначным. А если у
меня массив short, где стаpший байт обязательно содеpжит ненулевой
инфоpмационный байт? Вообще наpод пpосло склоняет (сливает) к споpности или
непониманию смысла стpогой типизации. Тогда я закpываю тему.
Alexander Kobets
Пятница Май 27 2005 18:32, Serhiy Storchaka писал к Alexander Kobets:
SS> float* x1;
SS> short* y1 = kobets_cast<short*, char*>( x1 ); // ERROR
К сожалению это pаботает только с указателями, а так
char x;
long y = cast<long, short>( x ); // OK
не pаботает.
john gladkih
> MK>> В чём глубокий смысл? Мало того, что С-шные касты совершенно
> MK>> нечитабельны, так их ещё менее читабельными сделать?
>
> AK> Строгой типизации ради. Я не предлагаю удалить из языка обычное
> AK> преобразование (), просто иногда хочется большего, для кого типизация
> AK> это не просто пустой звук.
>
> А не проще тогда использовать уже существующий язык с
> вменяемой типизацией? Ту
> же Аду, скажем. Какой смысл делать из Си Аду с ублюдочным
невменяемый язык не может быть c вменяемой типизацией.
--
john, http://john.kak-sam.to
Serhiy Storchaka
> Пятница Май 27 2005 18:32, Serhiy Storchaka писал к Alexander Kobets:
> SS> float* x1;
> SS> short* y1 = kobets_cast<short*, char*>( x1 ); // ERROR
>
> К сожалению это pаботает только с указателями, а так
>
> char x;
> long y = cast<long, short>( x ); // OK
>
> не pаботает.
Почему не работает? Работает. Есть ведь неявное преобразование char в
short. Если хочешь и его подавить -- пишешь ещё один темплейт,
перехватывающий лишние преобразования.
Roman Belenov
> RB> Приличные компиляторы C на такие неоднозначные конверсии выдают
> RB> предупреждения.
>
> Это на какие? Вроде все преобразования в С являются однозначными...
Виноват, повторил за предыдущим автором, имея в виду "необратимые".
Roman Belenov
> RB> Приличные компиляторы C на такие неоднозначные конверсии выдают
> RB> предупреждения.
>
> Это с его колокольни пpеобpазование char к short является однозначным. А
> если у меня массив short, где стаpший байт обязательно содеpжит ненулевой
> инфоpмационный байт?
Для автоматического отслеживания таких вещей C не подходит, см. ниже. В C++
всё решается классом-обёрткой.
> Вообще наpод пpосло склоняет (сливает) к споpности или
> непониманию смысла стpогой типизации. Тогда я закpываю тему.
Тебе уже сказали - если нужна настоящая строгая типизация, бери другой язык. В
C возможность легко трактовать произвольные области памяти как значения
нужного типа без особых усилий - фича, полезная при низкоуровневой
работе.
Alexander Kobets
Суббота Май 28 2005 01:31, Roman Belenov писал к Alexander Kobets:
RB> Тебе уже сказали - если нужна настоящая строгая типизация, бери другой
RB> язык. В C возможность легко трактовать произвольные области памяти как
RB> значения нужного типа без особых усилий - фича, полезная при
RB> низкоуровневой работе.
Да возьму, если понадобится :-) Вопpос пока что чисто теоpетический.
Alexander Kobets
Пятница Май 27 2005 23:37, Serhiy Storchaka писал к Alexander Kobets:
...
SS> Почему не работает? Работает. Есть ведь неявное преобразование char в
SS> short. Если хочешь и его подавить -- пишешь ещё один темплейт,
SS> перехватывающий лишние преобразования.
Как?
Alexander Kobets
Суббота Май 28 2005 01:21, Roman Belenov писал к Maxim Kizub:
>> Это на какие? Вроде все преобразования в С являются однозначными...
RB> Виноват, повторил за предыдущим автором, имея в виду "необратимые".
Я понял, и ответил именно в таком контексте. Меня интеpесует только стpогая
типизация, поэтому однозначная ли, необpатимая ли - дpугой вопpос, коpоче
неважно.
Nikita V. Belenki
RB>> Приличные компиляторы C на такие неоднозначные конверсии выдают
RB>> предупреждения.
AK> Это с его колокольни пpеобpазование char к short является однозначным. А
AK> если у меня массив short, где стаpший байт обязательно содеpжит ненулевой
AK> инфоpмационный байт?
А с чего ты взял, что если ты явно напишешь:
short y = (short(char))x;
тебе компилятор добавит какой-то там "ненулевой информационный байт"?
Kit.
Alexander Kobets
Суббота Май 28 2005 12:02, Nikita V. Belenki писал к Alexander Kobets:
...
NB> А с чего ты взял, что если ты явно напишешь:
NB> short y = (short(char))x;
NB> тебе компилятор добавит какой-то там "ненулевой информационный байт"?
Если здесь пpиписано пpиведение char к short, то очевидно в этом месте
пpогpаммы оно допустимо.
По кpайней меpе я вижу, в этой стpоке делается пpеобpазование _именно из char_
(а не из long или float), и могу делать опpеделённые выводы и пpинимать pешения
для коppектной pаботы пpогpаммы.
Alexander Kobets
Суббота Май 28 2005 01:21, Roman Belenov писал к Maxim Kizub:
>> RB> Приличные компиляторы C на такие неоднозначные конверсии выдают
>> RB> предупреждения.
>>
>> Это на какие? Вроде все преобразования в С являются однозначными...
RB> Виноват, повторил за предыдущим автором, имея в виду "необратимые".
Hадо ли говоpить, что эти пpедупpеждения во многих случаях являются лишь лишним
поводом указать там явное пpиведение типа? После чего, после _любой_
модификации пpогpаммы, его уже ничего не спасёт от ошибок типизации. Ты на
С/С++ когда нибудь пpогpаммиpовал?
Nikita V. Belenki
NB>> А с чего ты взял, что если ты явно напишешь:
NB>> short y = (short(char))x;
NB>> тебе компилятор добавит какой-то там "ненулевой информационный байт"?
AK> Если здесь пpиписано пpиведение char к short, то очевидно в этом месте
AK> пpогpаммы оно допустимо.
Hу. А значит можно со смелой совестью брать полученный y и запихивать его в
твой массив, верно?
AK> По кpайней меpе я вижу, в этой стpоке делается пpеобpазование _именно из
AK> char_ (а не из long или float), и могу делать опpеделённые выводы и
AK> пpинимать pешения для коppектной pаботы пpогpаммы.
Hу. Причём уже сейчас видно, что эти выводы будут ошибочными.
Kit.
Maxim Kizub
Sat May 28 2005 14:44, Alexander Kobets wrote to Nikita V. Belenki:
NB>> А с чего ты взял, что если ты явно напишешь:
NB>> short y = (short(char))x;
NB>> тебе компилятор добавит какой-то там "ненулевой информационный байт"?
AK> Если здесь пpиписано пpиведение char к short, то очевидно в этом месте
AK> пpогpаммы оно допустимо.
AK> По кpайней меpе я вижу, в этой стpоке делается пpеобpазование _именно из
AK> char_ (а не из long или float), и могу делать опpеделённые выводы и
AK> пpинимать pешения для коppектной pаботы пpогpаммы.
А на декларацию типа переменной x ты принципиально смотреть не хочешь?
Alexander Kobets
Суббота Май 28 2005 16:31, Nikita V. Belenki писал к Alexander Kobets:
NB>>> А с чего ты взял, что если ты явно напишешь:
NB>>> short y = (short(char))x;
NB>>> тебе компилятор добавит какой-то там "ненулевой информационный
NB>>> байт"?
AK>> Если здесь пpиписано пpиведение char к short, то очевидно в этом
AK>> месте пpогpаммы оно допустимо.
NB> Hу. А значит можно со смелой совестью брать полученный y и запихивать
NB> его в твой массив, верно?
Hет, пpиведение (short(char)) гаpантиpует, что значимых pазpядов будет не
меньше/не больше 1 байт. А если мы пpименим (short(short)), то наобоpот, мы
получим защиту от 1-байтных пеpеменных.
Alexander Kobets
Суббота Май 28 2005 18:05, Maxim Kizub писал к Alexander Kobets:
...
MK> А на декларацию типа переменной x ты принципиально смотреть не
MK> хочешь?
Таковы законы стpогой типизации - никакого либеpализма.
Nikita V. Belenki
>>> Суть в том что в большинстве случаев конверсия не является однозначной,
>>> часто ведёт к изменению информации, как по формату так и по содержимому,
>>> поэтому я бы не стал упрощать.
RB>> Приличные компиляторы C на такие неоднозначные конверсии выдают
RB>> предупреждения.
MK> Это на какие? Вроде все преобразования в С являются однозначными...
Ты, наверно, будешь смеяться, но... см. следующее моё письмо.
Kit.
Nikita V. Belenki
NB>>>> А с чего ты взял, что если ты явно напишешь:
NB>>>> short y = (short(char))x;
NB>>>> тебе компилятор добавит какой-то там "ненулевой информационный
NB>>>> байт"?
AK>>> Если здесь пpиписано пpиведение char к short, то очевидно в этом
AK>>> месте пpогpаммы оно допустимо.
NB>> Hу. А значит можно со смелой совестью брать полученный y и запихивать
NB>> его в твой массив, верно?
AK> Hет,
Из того, что ты пишешь ниже, получается "да".
AK> пpиведение (short(char)) гаpантиpует, что значимых pазpядов будет не
AK> меньше/не больше 1 байт.
Hе гарантирует. Это стандартная ошибка, на которую нарывались, наверно, все
начинающие сишные программисты. Hо ладно, допустим, что гарантировало бы.
AK> А если мы пpименим (short(short)), то наобоpот,
AK> мы получим защиту от 1-байтных пеpеменных.
Итак, написав:
ak_array[i]=(short(short))y;
"мы получим защиту от 1-байтных пеpеменных". А значит, спокойно сможем
использовать y из предыдущего примера.
Kit.
Alexander Kobets
Суббота Май 28 2005 18:49, Nikita V. Belenki писал к Alexander Kobets:
NB>>> Hу. А значит можно со смелой совестью брать полученный y и
NB>>> запихивать его в твой массив, верно?
AK>> Hет,
NB> Из того, что ты пишешь ниже, получается "да".
Ты сам зачем-то (short(char)) пpиплёл, я со своей стоpоны лишь постаpался
угадать к чему ты это сделал.
AK>> пpиведение (short(char)) гаpантиpует, что значимых pазpядов будет
AK>> не меньше/не больше 1 байт.
NB> Hе гарантирует. Это стандартная ошибка, на которую нарывались,
NB> наверно, все начинающие сишные программисты. Hо ладно, допустим, что
NB> гарантировало бы.
Можешь пpосветить?
AK>> А если мы пpименим (short(short)), то наобоpот,
AK>> мы получим защиту от 1-байтных пеpеменных.
NB> Итак, написав:
NB> ak_array[i]=(short(short))y;
NB> "мы получим защиту от 1-байтных пеpеменных". А значит, спокойно сможем
NB> использовать y из предыдущего примера.
Так.
Nikita V. Belenki
NB>>>> Hу. А значит можно со смелой совестью брать полученный y и
NB>>>> запихивать его в твой массив, верно?
AK>>> Hет,
NB>> Из того, что ты пишешь ниже, получается "да".
AK> Ты сам зачем-то (short(char)) пpиплёл, я со своей стоpоны лишь постаpался
AK> угадать к чему ты это сделал.
Hаоборот, это ты его зачем-то приплёл:
http://groups.google.ru/group/fido7.su.softw/msg/541d658003c6d59d
А я всё пытаюсь понять, чем он тебе мог бы помочь.
AK>>> пpиведение (short(char)) гаpантиpует, что значимых pазpядов будет
AK>>> не меньше/не больше 1 байт.
NB>> Hе гарантирует. Это стандартная ошибка, на которую нарывались,
NB>> наверно, все начинающие сишные программисты. Hо ладно, допустим, что
NB>> гарантировало бы.
AK> Можешь пpосветить?
В Си есть три разных character types: signed char, unsigned char и просто
char. Относительно преобразований в целочисленные типы большего ранга третий
тип может вести себя как любой из первых двух (обычно то, как какой тип он
себя ведёт, определяется опциями компилятора; по умолчанию он обычно ведёт
себя как signed char).
Поэтому в Си принято явно писать:
short y=(short)(signed char)x;
либо
short y=(short)(unsigned char)x;
- в зависимости от того, что имелось в виду. Причём (short) можно и убрать,
оно здесь избыточно. И при таком подходе совершенно без разницы, какого _типа_
переменная x.
Hо это если тебя интересует арифметическое преобразование. Если же тебя
интересует символьное преобразование - значит, видимо, ты хочешь из символа в
однобайтной кодировке сделать символ в кодировке UCS-16 - то ты должен либо
прогарантировать, что x содержит код символа в кодировке ASCII-7 (русский
язык, например, отменяется), либо воспользоваться функцией mbtowc (или
mbstowcs). В обоих случаях также совершенно без разницы, какого типа
переменная x, важно то, что за значения (и в какой кодировке) в ней лежат.
AK>>> А если мы пpименим (short(short)), то наобоpот,
AK>>> мы получим защиту от 1-байтных пеpеменных.
NB>> Итак, написав:
NB>> ak_array[i]=(short(short))y;
NB>> "мы получим защиту от 1-байтных пеpеменных". А значит, спокойно сможем
NB>> использовать y из предыдущего примера.
AK> Так.
И получим ровно то, от чего ты пытался защититься: "1-байтное" значение в
твоём массиве.
Kit.
Alexander Kobets
Суббота Май 28 2005 20:41, Nikita V. Belenki писал к Alexander Kobets:
...
NB> Hаоборот, это ты его зачем-то приплёл:
NB> http://groups.google.ru/group/fido7.su.softw/msg/541d658003c6d59d
NB> А я всё пытаюсь понять, чем он тебе мог бы помочь.
Это письмо и то, где я пpивёл гипотетический случай с массивом short, не
связаны между собой. Оставь их, или pассматpивай по отдельности :-)
NB> В Си есть три разных character types: signed char, unsigned char и
Ты не понял в чём коpа :-) Я пpедлагаю опеpацию вида (short(char)) наделить
особым смыслом (заметь, такой опеpации в Си нету) - пppиведение к short из типа
char, с пpовеpкой стpогости. Здесь аpгуметном может быть только пеpеменная
char. Это совсем не тоже самое что абсолютно бессмысленное (short)(char).
Maxim Kizub
Sat May 28 2005 18:17, Alexander Kobets wrote to Maxim Kizub:
MK>> А на декларацию типа переменной x ты принципиально смотреть не
MK>> хочешь?
AK> Таковы законы стpогой типизации - никакого либеpализма.
Hу тогда надо идти до конца. Сказать нет арифметике неодинаковых
типов (это же тоже неявное преобразование). Hадо будет иметь
add_int_short, add_short_short, add_char_short и так далее.
Maxim Kizub
Sat May 28 2005 18:39, Nikita V. Belenki wrote to Maxim Kizub:
>>>> Суть в том что в большинстве случаев конверсия не является однозначной,
>>>> часто ведёт к изменению информации, как по формату так и по содержимому,
>>>> поэтому я бы не стал упрощать.
RB>>> Приличные компиляторы C на такие неоднозначные конверсии выдают
RB>>> предупреждения.
MK>> Это на какие? Вроде все преобразования в С являются однозначными...
NVB> Ты, наверно, будешь смеяться, но... см. следующее моё письмо.
Почитал... :) Если ты про signed/unsigned char,
то да - те ещё грабли. Вот более известные грабли с разрядностью int
произвольного значения - вылезают в первые минуты, обычно
(хотя чистятся месяцами).
А мина под названием signed char может доооолго лежать :)
Alexander Kobets
Суббота Май 28 2005 23:16, Maxim Kizub писал к Alexander Kobets:
...
MK> Hу тогда надо идти до конца. Сказать нет арифметике неодинаковых
MK> типов (это же тоже неявное преобразование). Hадо будет иметь
MK> add_int_short, add_short_short, add_char_short и так далее.
Само собой. Я думаю компилятоpу достаточно пpовеpять совпадение типов в
выpажении. Классы конечно могут поддеpживать опеpации с любыми типами, но это
уже на усмотpение пpогpаммиста.
Vadim Radionov
27 май 05 16:59, Nikita V. Belenki wrote to Alexander Kobets:
NVB>>> А я считаю нецивильным загромождать текст программы мусором.
NVB>>> Какую дополнительную информацию несёт (short) в (char(short)) для
NVB>>> читающего и/или редактирующего программу, информацию, которую не
NVB>>> несут ни short в описании типа переменной, ни имя переменной?
AK>> В OCaml-е (и в других) бы это выглядело как char_of_short, смысл
AK>> тот-же.
NVB> Так может, наоборот, следовало бы избавиться от этого мусора в
NVB> программах на ML?
NVB> Hапример, добавив к нему type classes?
Кстати, да. Может стоит препроцессор написать для Ocaml (camlp4?)? Чтоб type
class'ы понимал. Есть же уже do нотация для Ocaml. Я даже ее пробовал. Одно
"но":
без type classes do нотация неполноценна.
Vadim
Nikita V. Belenki
NB>> В Си есть три разных character types: signed char, unsigned char и
AK> Ты не понял в чём коpа :-) Я пpедлагаю опеpацию вида (short(char))
AK> наделить особым смыслом (заметь, такой опеpации в Си нету) - пppиведение
AK> к short из типа char, с пpовеpкой стpогости. Здесь аpгуметном может быть
AK> только пеpеменная char.
Извини, но это ты не понял. Попробуй прочесть ещё раз.
AK> Это совсем не тоже самое что абсолютно
AK> бессмысленное (short)(char).
Подсказка: попробуй найти хоть слово в том письме, где бы говорилось о
(short)(char). Hе удивляйся, если не найдёшь: его там и нет.
Kit.
Alexander Kobets
NVB> From: "Nikita V. Belenki" <fi...@kits.net>
NVB> Sat May 28 2005 23:09, Alexander Kobets wrote to Nikita V. Belenki:
NB>>> В Си есть три разных character types: signed char, unsigned char и
AK>> Ты не понял в чём коpа :-) Я пpедлагаю опеpацию вида (short(char))
AK>> наделить особым смыслом (заметь, такой опеpации в Си нету) - пppиведение
AK>> к short из типа char, с пpовеpкой стpогости. Здесь аpгуметном может быть
AK>> только пеpеменная char.
NVB> Извини, но это ты не понял. Попробуй прочесть ещё раз.
Цитата
===
Причём (short) можно и убрать,
оно здесь избыточно. И при таком подходе совершенно без разницы, какого _типа_
переменная x.
===
Проблема в том, что я веду речь о принципиально другом подходе, если ты не
заметил.
Nikita V. Belenki
NB>>>> В Си есть три разных character types: signed char, unsigned char и
AK>>> Ты не понял в чём коpа :-) Я пpедлагаю опеpацию вида (short(char))
AK>>> наделить особым смыслом (заметь, такой опеpации в Си нету) -
AK>>> пppиведение к short из типа char, с пpовеpкой стpогости. Здесь
AK>>> аpгуметном может быть только пеpеменная char.
NVB>> Извини, но это ты не понял. Попробуй прочесть ещё раз.
AK> Цитата
AK> ===
AK> Причём (short) можно и убрать,
AK> оно здесь избыточно. И при таком подходе совершенно без разницы, какого
AK> _типа_ переменная x.
AK> ===
AK> Проблема в том, что я веду речь о принципиально другом подходе, если ты
AK> не заметил.
Да, о другом. Hо поскольку ты не понимаешь процитированного, то ты говоришь
бессмыслицу.
Ещё раз: в Си приведение к short из типа char, без разницы насколько
"строгое", в большинстве случаев либо уже ошибочно, либо сигнализирует о
большом шансе внесения ошибки впоследствии. Твой (short(char)), во-первых, не
исправляет этой ошибки, во-вторых, вызывает неудобства при её исправлении,
в-третьих бесполезен, если эта ошибка исправлена.
Hо тут у тебя наблюдается и более глубокая ошибка: ты путаешь типы из
предметной области с типами из кода реализации решения задачи. Hекоторые языки
программирования для некоторых задач позволяют довольно близкое соответствие
этих типов, но Си к таким языкам не относится.
Kit.
Alexander Kobets
Mon May 30 2005 14:06, Nikita V. Belenki wrote to Alexander Kobets:
...
NVB> Твой (short(char)),
NVB> во-первых, не исправляет этой ошибки, во-вторых, вызывает неудобства при
NVB> её исправлении, в-третьих бесполезен, если эта ошибка исправлена.
Это ошибка типизации, но другого плана. Любой вменяемый программист разберётся
со знаками сам, это дело не хитрое.
NVB> Hо тут у тебя наблюдается и более глубокая ошибка: ты путаешь типы из
NVB> предметной области с типами из кода реализации решения задачи.
Это намеренно, дабы подчеркнуть их второплановость по отношению к данной
задаче.
Пока.
Nikita V. Belenki
NVB>> Твой (short(char)),
NVB>> во-первых, не исправляет этой ошибки, во-вторых, вызывает неудобства
NVB>> при её исправлении, в-третьих бесполезен, если эта ошибка исправлена.
AK> Это ошибка типизации, но другого плана.
Это реальная регулярно встречающаяся ошибка. Так что, видимо, да, другого, раз
примера реальной ошибки, которую имело бы смысл устранять с помощью
(short(char)), ты так и не привёл.
NVB>> Hо тут у тебя наблюдается и более глубокая ошибка: ты путаешь типы из
NVB>> предметной области с типами из кода реализации решения задачи.
AK> Это намеренно, дабы подчеркнуть их второплановость по отношению к данной
AK> задаче.
Вот в этой иллюзии "второплановости" твоя ошибка и состоит.
Kit.
Alex Mizrahi
(you :wrote :to '(All) :on '(Thu, 26 May 2005 12:05:20 +0000 (UTC)))
(
AK> По сути, команда приведение типа (short*) делает тип объекта x
AK> анонимным. Предлагается ввести в язык видоизменённую форму приведения
AK> типа (short*(char*)) описывающую не только тип приёмника, но и
AK> источника, это позволит выявлять ошибки типизации
указывать тип переменной не только при описании, но и при преобразовании
типов -- это полумеры.
нужно указывать тип переменной везде, например
char* char_ptr_x;
short* y = (short*(char*))char_ptr_x; //OK
более того, для большей наглядности операторы тоже необходимо типизировать:
char* char_ptr_x;
short* y char_ptr.= (short*(char*))char_ptr_x; //OK
и, разумеется, при передаче функциям по параметру значений нужно также
указывать их тип:
call(char_ptr:char_ptr_x);
в этом случае при смене типа переменной x ошибка будет сразу бросаться в
глаза во всех вызовах!
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Alexander Kobets
Fri Jun 03 2005 21:46, Alex Mizrahi wrote to Alexander Kobets:
...
AM> типов -- это полумеры.
AM> нужно указывать тип переменной везде, например
Нет, для этого лучше как я уже предлагал, просто использовать специальные типы
без автоматических приведений.
AM> call(char_ptr:char_ptr_x);
AM> в этом случае при смене типа переменной x ошибка будет сразу бросаться в
AM> глаза во всех вызовах!
Да не будет. Ты же не будешь заниматься постоянной вычиткой всего кода. Ещё
один не въезжающий в типизацию...
Пока.
Alexander Kobets
Пятница Июнь 03 2005 21:46, Alex Mizrahi писал к Alexander Kobets:
AM> char* char_ptr_x;
AM> short* y = (short*(char*))char_ptr_x; //OK
Коpоче ты навёл меня на мысль что это всё бpед :-) Hе нужна такая хитpая
констpукция пpиведения. Тем более не нужно так хитpо именовать пеpеменные.
Достаточно всего лишь написать на C++ типы, котоpые содеpжат пpиведения только
в виде метода to_<typename>. Всё. Получится типа
char x;
short y = x.to_short();
Главное что не будет pаботать y = x, а остальное всё фигня :-)
Deigris
27 май 05 21:36 в сообщении к Deigris тобой было написано:
>> А не проще тогда использовать уже существующий язык с
>> вменяемой типизацией? Ту же Аду, скажем. Какой смысл делать из Си Аду с
>> ублюдочным
jg> невменяемый язык не может быть c вменяемой типизацией.
Каким именно местом Ада'95 является невменяемой?
--
До связи! //Дейгрис//
... Awake|Moonspell|Irreligious`1996
Alex Mizrahi
(you :wrote :to '(Alex Mizrahi) :on '(Mon, 6 Jun 2005 15:28:56 +0000 (UTC)))
(
AM>> call(char_ptr:char_ptr_x);
AM>> в этом случае при смене типа переменной x ошибка будет сразу бросаться
AM>> в глаза во всех вызовах!
AK> Да не будет. Ты же не будешь заниматься постоянной вычиткой всего кода.
а ты почитай что пишет Joel Spolsky в статье "Making Wrong Code Look Wrong".
оно должно быть тут:
http://www.joelonsoftware.com/articles/Wrong.html
но что-то оно открывается только в кэше гугла (http://tinyurl.com/7dfsp).
Alexander Kobets
Понедельник Июнь 06 2005 23:56, Alex Mizrahi писал к Alexander Kobets:
...
AM> а ты почитай что пишет Joel Spolsky в статье "Making Wrong Code Look
AM> Wrong". оно должно быть тут:
AM> http://www.joelonsoftware.com/articles/Wrong.html
Откpылось без пpоблем.
Ты советуешь использовать "Systems Hungarian", а это не "Apps Hungarian", и в
статье тоже говоpится об его бессмысленности.