: "В статически и сильно типизированном языке во время компиляции можно гарантировать, что работа будет вестить только с правильным типом". Тем не менее, оно не выполняется. Следующую конструкцию компилятор схавает:
M>Указатели позволяют прямую манипуляцию памятью, невзирая на тип объекта.
Угу.
((void(*)(void))0)();
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, Don Reba, Вы писали:
DR>>В статически и сильно типизированном языке во время компиляции можно гарантировать, что работа будет вестить только с правильным типом, а в слабо типизированном — нет.
D>Java и scala — статически и сильно типизированные?
M>>То есть (AnotherObject*)((void*)Object) прокатит и в С и в С++ на ура безо всякого контроля со стороны компилятора или рантайма.
D>Это также ИМХО не катит: на java/scala я могу написать точно такой же левый каст, они от этого не станут слабыми. А то, что этот каст вылетит (точнее, может вылететь) в рантайме — дык это уже динамика, а не статика. А я спрашиваю про слабую статику. Техническая возможность беспредельничать разнообразными способами, форсированно обходя контроль системы типов, не означает отсутствие этого контроля. Грубо говоря, если я получу адрес объекта и тупо забью его мусором через memset(), это как бы к системе типов отношения не имеет.
Ага, тока в жабе компилер не пропустит. И даже если ручками в байткоде написать — виртуалка не пропустит, обложили, демоны. А мемсета нету.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, jazzer, Вы писали:
J>Строгий язык тебе в принципе не позволит что-то заюзать "не с умом". J>Например, в строгом языке вот такая фигня будет: J>
J>double pow(double);
J>pow(0.0); // OK
J>pow(0); // won't compile - 0 is int
J>
J>что несколько неудобно. Так что у нестрогости есть свои преимущества.
: "В статически и сильно типизированном языке во время компиляции можно гарантировать, что работа будет вестить только с правильным типом". Тем не менее, оно не выполняется. Следующую конструкцию компилятор схавает: D>
D>var s = "hello"
D>var i = s.asInstanceOf[Int]
D>
Несмотря на приведение типа, у компилятора остаётся гарантия, что если типы не совместимы, то во время исполнения будет выброшено исключение. В С++ подобной гарантии нет; в любом месте пользователь может написать *(*double)2501 = PI. Поэтому, в С++ более слабая типизация.
Здравствуйте, Eugeny__, Вы писали:
E__>Ага, тока в жабе компилер не пропустит.
Пропустит. Может, не буквально это, но фигню посложнее, подобную очччень часто встречающуюся вот такому безобразию, пропустит на ура (пишу в псевдокоде, ближе к scala, т.к. оно короче):
[coode]
class A
class B extends A
class C extends A { def c() { ... } }
def f(a: A, ...) {
if (мы ну просто абсолютно твёрдо уверены, что a всегда типа B)
a.asInstanceOf[C].c()
}
[/code]
E__>И даже если ручками в байткоде написать — виртуалка не пропустит, обложили, демоны. А мемсета нету.
А виртуалка к статике никакого отношения не имеет. Повторяюсь: мой исходный вопрос — примеры слабой статики.
: "В статически и сильно типизированном языке во время компиляции можно гарантировать, что работа будет вестить только с правильным типом". Тем не менее, оно не выполняется. Следующую конструкцию компилятор схавает: D>>
D>>var s = "hello"
D>>var i = s.asInstanceOf[Int]
D>>
DR>Несмотря на приведение типа, у компилятора остаётся гарантия, что если типы не совместимы, то во время исполнения будет выброшено исключение.
Гы. "Однако, даже не знаю, что ответить, — говорит песец." (с) Ну например, так: у компилятора нет гарантий даже того, что скомпилированный код будет вообще хоть раз запущен. Какое отношение имеет компилятор к рантайму? Откуда ему знать, какая имплементация рантайма будет выполнять сгенерированный им код? В общем, какое отношение рантайм имеет ко времени компиляции?
Здравствуйте, Курилка, Вы писали:
DR>>>В статически и сильно типизированном языке во время компиляции можно гарантировать, что работа будет вестить только с правильным типом, а в слабо типизированном — нет.
D>>Java и scala — статически и сильно типизированные?
К>Лучше чем плюсы, но всё равно нет.
Хм. А что мешает? Ну generics на java кривые. Ещё этот typecast и рефлексия всю малину портят. Про JNI вот Don Reba упомянул. Если это всё убрать, они станут таковыми? Что ещё? А бывают вообще статические сильно типизированные языки?
E__>>Ага, тока в жабе компилер не пропустит.
D>Пропустит. Может, не буквально это, но фигню посложнее, подобную очччень часто встречающуюся вот такому безобразию, пропустит на ура (пишу в псевдокоде, ближе к scala, т.к. оно короче):
D>[coode] D>class A D>class B extends A D>class C extends A { def c() { ... } } D>def f(a: A, ...) { D> if (мы ну просто абсолютно твёрдо уверены, что a всегда типа B) D> a.asInstanceOf[C].c() D>} D>[/code]
E__>>И даже если ручками в байткоде написать — виртуалка не пропустит, обложили, демоны. А мемсета нету.
D>А виртуалка к статике никакого отношения не имеет. Повторяюсь: мой исходный вопрос — примеры слабой статики.
Приведенный выше пример только показывает, что в Жаве типизация строже, раз такие извороты надо делать
Здравствуйте, dimgel, Вы писали:
D>Гы. "Однако, даже не знаю, что ответить, — говорит песец." (с) Ну например, так: у компилятора нет гарантий даже того, что скомпилированный код будет вообще хоть раз запущен. Какое отношение имеет компилятор к рантайму? Откуда ему знать, какая имплементация рантайма будет выполнять сгенерированный им код? В общем, какое отношение рантайм имеет ко времени компиляции?
Виртуальная машина гарантирует строгую типизацию, компилятор — статическую. Всё просто, по-моему.
DR>>>>В статически и сильно типизированном языке во время компиляции можно гарантировать, что работа будет вестить только с правильным типом, а в слабо типизированном — нет.
D>>>Java и scala — статически и сильно типизированные?
К>>Лучше чем плюсы, но всё равно нет.
D>Хм. А что мешает? Ну generics на java кривые. Ещё этот typecast и рефлексия всю малину портят. Про JNI вот Don Reba упомянул. Если это всё убрать, они станут таковыми? Что ещё? А бывают вообще статические сильно типизированные языки?
Haskell, по идее.
Естественно, 100% строгой типизации никто не даст, потому что иначе программировать станет очень затруднительно, но к этому можно стремиться и не позволять что-нибудь типа (int)((void*)SomeObject)/1.0 для обхода системы типов.
Здравствуйте, Mamut, Вы писали:
D>>Хм. А что мешает? Ну generics на java кривые. Ещё этот typecast и рефлексия всю малину портят. Про JNI вот Don Reba упомянул. Если это всё убрать, они станут таковыми? Что ещё? А бывают вообще статические сильно типизированные языки?
M>Haskell, по идее.
M>>Естественно, 100% строгой типизации никто не даст, потому что иначе программировать станет очень затруднительно,
D>А хорошо, что я забыл добавить "И кому они нужны?" Это замечание собственно больше к предыдущей строке относится.
Здравствуйте, Mamut, Вы писали:
DR>>>>>В статически и сильно типизированном языке во время компиляции можно гарантировать, что работа будет вестить только с правильным типом, а в слабо типизированном — нет.
D>>>>Java и scala — статически и сильно типизированные?
К>>>Лучше чем плюсы, но всё равно нет.
D>>Хм. А что мешает? Ну generics на java кривые. Ещё этот typecast и рефлексия всю малину портят. Про JNI вот Don Reba упомянул. Если это всё убрать, они станут таковыми? Что ещё? А бывают вообще статические сильно типизированные языки?
M>Haskell, по идее.
Ну с требованием полной статической гарантии он не справится — к примеру, может сфейлиться ПМ, ну и unsafe тоже никуда не девается. Возможно требуемым критериям мог бы удовлетворять язык дающий total functional programming, только вроде таких так и не сделали толком.
Т.е. получается, что в любом случае часть проверок строгости переводится в рантайм (вплоть до почти полной динамики для динамических языков).
Здравствуйте, antonio_banderas, Вы писали:
_>Я хочу про С++. _>(руби и яваскрипт я всё равно не знаю)
Плюсую! Но по другой причине: тут как надо статику обосрать, туже на C++ кивают. Не язык, а терпила в натуре, за всю статику отдувается. Так что просьба закономерна и логична.
Здравствуйте, Mamut, Вы писали:
E__>>>Ага, тока в жабе компилер не пропустит.
D>>Пропустит. Может, не буквально это, но фигню посложнее, подобную очччень часто встречающуюся вот такому безобразию, пропустит на ура (пишу в псевдокоде, ближе к scala, т.к. оно короче):
D>>[coode] D>>class A D>>class B extends A D>>class C extends A { def c() { ... } } D>>def f(a: A, ...) { D>> if (мы ну просто абсолютно твёрдо уверены, что a всегда типа B) D>> a.asInstanceOf[C].c() D>>} D>>[/code]
E__>>>И даже если ручками в байткоде написать — виртуалка не пропустит, обложили, демоны. А мемсета нету.
D>>А виртуалка к статике никакого отношения не имеет. Повторяюсь: мой исходный вопрос — примеры слабой статики.
M>Приведенный выше пример только показывает, что в Жаве типизация строже, раз такие извороты надо делать
И то, это не джава — это скала. В джаве так не извратиться — компилер сходу завернет это дело.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
См. рядышком, я тут пытаюсь додавить оппонентов на тему кастов.
Это замечание собственно больше к предыдущей строке относится. 
Так что просьба закономерна и логична.
