Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, dimgel, Вы писали:
DR>>>Ты забываешь о шаблонах С++.
D>>разворачиваются без контроля типизатора.
J>Это что тут имеется в виду?
Что такое шаблон? Фактически, шаблон — это программа, которая генерит код. Так вот, эта программа — динамически типизирована. так же как например программа на питоне, руби и тд. То есть ошибки типизации в ней проявятся в момент ВЫПОЛНЕНИЯ этой программы.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, Wolverrum, Вы писали:
VD>>>По ржал до слез. Спасибо, от души. W>>Эдгар?! 0>Шутка не хуже самого видео
ага, я тоже по ржала до слез.
Здравствуйте, Jack128, Вы писали:
DR>>>>Ты забываешь о шаблонах С++.
D>>>разворачиваются без контроля типизатора.
J>>Это что тут имеется в виду?
J>Что такое шаблон? Фактически, шаблон — это программа, которая генерит код. Так вот, эта программа — динамически типизирована. так же как например программа на питоне, руби и тд. То есть ошибки типизации в ней проявятся в момент ВЫПОЛНЕНИЯ этой программы.
сорри, выполнения _какой_ программы? Вроде как компилятора как раз, не? И типизатора внутри него, что бы под ним ни подразумевалось
Здравствуйте, мыщъх, Вы писали:
М>вы неправильно пробовали. возьмите в руки шелл. хоть ff, хоть от хрома. а еще можно покурить ECMAScripting. покажите мне место стандарта по которому должно быть иначе -- я тогда сильно удивлюсь, поскольку, реализацию js движка писал сам и угадал правильные ответы во всех случаях, т.к. оно очевидно. если интересно могу объяснить почему, но это ж тривиально. подумайте головой и все станет ясно.
О, мне теперь ясно! Такая фигня в джаваскрипте, потому что его движки пишут такие укурки!
Указатели к слабой типизации ИМХО отношения не имеют. От того, что я возьму строку и стану рассматривать её как последовательность байт, в памяти эта строка не изменится. А где там неявное приведение типов?
M>>C/C++. В них есть неявное приведение типов и указатели (http://en.wikipedia.org/wiki/Weak_and_Strong_typing)
D>Указатели к слабой типизации ИМХО отношения не имеют. От того, что я возьму строку и стану рассматривать её как последовательность байт, в памяти эта строка не изменится. А где там неявное приведение типов?
Есть как неявное (int -> float) так и явное, что тоже плохо с точки зрения строгости типизации. То есть (AnotherObject*)((void*)Object) прокатит и в С и в С++ на ура безо всякого контроля со стороны компилятора или рантайма.
Указатели позволяют прямую манипуляцию памятью, невзирая на тип объекта.
Здравствуйте, Mamut, Вы писали:
D>>Указатели к слабой типизации ИМХО отношения не имеют. От того, что я возьму строку и стану рассматривать её как последовательность байт, в памяти эта строка не изменится. А где там неявное приведение типов?
M>Есть как неявное (int -> float) так и явное, что тоже плохо с точки зрения строгости типизации.
Точно там неявное int -> float, или имеются в виду лишь правила вывода типа результата арифметических операций (int * float = float)? Последнее имеется чуть менее чем у всех и к слабости типизации операндов не имеет никакого отношения: типы исходных операндов не меняются.
M>То есть (AnotherObject*)((void*)Object) прокатит и в С и в С++ на ура безо всякого контроля со стороны компилятора или рантайма.
Это также ИМХО не катит: на java/scala я могу написать точно такой же левый каст, они от этого не станут слабыми. А то, что этот каст вылетит (точнее, может вылететь) в рантайме — дык это уже динамика, а не статика. А я спрашиваю про слабую статику. Техническая возможность беспредельничать разнообразными способами, форсированно обходя контроль системы типов, не означает отсутствие этого контроля. Грубо говоря, если я получу адрес объекта и тупо забью его мусором через memset(), это как бы к системе типов отношения не имеет.
M>Указатели позволяют прямую манипуляцию памятью, невзирая на тип объекта.
А битовые операции позволяют манипулировать целыми числами как наборами битовых флагов. Не знаю, насколько это формально корректно, может быть я собственную терминологию выдумываю, но если "объект — это область памяти" (с) Буч, то преобразование типов предполагает изменение структуры/содержимого области памяти. В твоих примерах этого нет, есть только семантически-некорректное обращение к неизменной существующей области.
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, Mamut, Вы писали:
M>>То есть (AnotherObject*)((void*)Object) прокатит и в С и в С++ на ура безо всякого контроля со стороны компилятора или рантайма.
D>Это также ИМХО не катит: на java/scala я могу написать точно такой же левый каст, они от этого не станут слабыми. А то, что этот каст вылетит (точнее, может вылететь) в рантайме — дык это уже динамика, а не статика. А я спрашиваю про слабую статику. Техническая возможность беспредельничать разнообразными способами, форсированно обходя контроль системы типов, не означает отсутствие этого контроля. Грубо говоря, если я получу адрес объекта и тупо забью его мусором через memset(), это как бы к системе типов отношения не имеет.
С чего это не имеет? Если ты берёшь строку, а работаешь в итоге как с числом, то это как раз и есть дыра в типизации -> слабая типизация.
Ещё явной дырой являются сишные объединения (по ср. с ADT из более внятных языков).
Здравствуйте, Курилка, Вы писали:
К>С чего это не имеет? Если ты берёшь строку, а работаешь в итоге как с числом, то это как раз и есть дыра в типизации -> слабая типизация. К>Ещё явной дырой являются сишные объединения (по ср. с ADT из более внятных языков).
Ну с unions вопросов нет. А на счёт взять строку и работать с ней как с числом — таки объясните мне, почему динамический по своей сути рантайм считается частью статически-типизированного языка? Формулировка вопроса именно такова, потому что я могу на любом (известном мне статически-типизированном) языке написать левый каст, и до момента выполнения не узнать о его некорректности; поэтому я рассматриваю такие касты не как часть системы типов, а как хак для её обхода. А то по-вашему выходит, что все языки, где есть операторы приведения типов, слабые.
Здравствуйте, dimgel, Вы писали:
D>Ну с unions вопросов нет.
Хотя в общем тоже не факт. Этот пример из той же серии, что и битовые операции над целым числом: работа с одной и той же областью памяти несколькими альтернативными, но валидными способами. Т.е. если я юзаю union с умом, никакая это не дыра. Ну а если без ума, дык на C++ отстрелить себе ногу можно гораздо проще и безо всяких систем типов — тупо ошибившись на +-1 при проходе по ASCIIZ-строке.
Здравствуйте, dimgel, Вы писали:
D>Ну с unions вопросов нет. А на счёт взять строку и работать с ней как с числом — таки объясните мне, почему динамический по своей сути рантайм считается частью статически-типизированного языка? Формулировка вопроса именно такова, потому что я могу на любом (известном мне статически-типизированном) языке написать левый каст, и до момента выполнения не узнать о его некорректности; поэтому я рассматриваю такие касты не как часть системы типов, а как хак для её обхода. А то по-вашему выходит, что все языки, где есть операторы приведения типов, слабые.
В статически и сильно типизированном языке во время компиляции можно гарантировать, что работа будет вестить только с правильным типом, а в слабо типизированном — нет.
Здравствуйте, Don Reba, Вы писали:
DR>В статически и сильно типизированном языке во время компиляции можно гарантировать, что работа будет вестить только с правильным типом, а в слабо типизированном — нет.
Java и scala — статически и сильно типизированные?
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, dimgel, Вы писали:
D>>Ну с unions вопросов нет.
D>Хотя в общем тоже не факт. Этот пример из той же серии, что и битовые операции над целым числом: работа с одной и той же областью памяти несколькими альтернативными, но валидными способами. Т.е. если я юзаю union с умом, никакая это не дыра. Ну а если без ума, дык на C++ отстрелить себе ногу можно гораздо проще и безо всяких систем типов — тупо ошибившись на +-1 при проходе по ASCIIZ-строке.
Строгий язык тебе в принципе не позволит что-то заюзать "не с умом".
Например, в строгом языке вот такая фигня будет:
double pow(double);
pow(0.0); // OK
pow(0); // won't compile - 0 is int
что несколько неудобно. Так что у нестрогости есть свои преимущества.
PS никто не мешает пользоваться только строгим подмножеством нестрогого в целом языка, или даже сотворить его своими руками.
Например, вышеприведенную pow можно сделать строгой и в С++:
template<class T>
enable_if< is_same<T, double>, double >
pow( T );
