>Вот так оно и работает — приходится отключать вовсе
Ни в коем случае! Тогда уж лучше используй «#pragma warning (suppress: номер)» для однократного подавления предупреждений в одной строчке или «disable» в обрамлении «push» и «pop» (http://msdn.microsoft.com/en-us/library/2c8f766e(loband).aspx).
>Мне не нужно ломать отлаженную программу лишь из-за того, что компилятор стал более параноидальным.
Сам не сломаешь — кто-то другой сломает. Отлаженная — это как? Ты поручишься, что обошёл абсолютно все уязвимости printf'а?
>Перестаньте уже витать в розовых облаках революционного пыла.
Перестаньте верить в теории заговора и всемогущество «корпораций». «Корпорации» состоят в конечном счёте из обычных людей, которые в большинстве своём распиздяи частью своей души. Такова природа человека. Поэтому от обычных факапов и проёбов «корпорации» (ещё скажите с пафосом «мафия», ага) не застрахованы. Сегодня она «корпорация», а завтра продаётся с молотка за ящик пива.
>Почему кавычка — не кавычка, а апостроф — не апостроф?
По историческим причинам. Во времена телетайпов кодировки были маленькими, клавиатурные раскладки бедными. Один и тот же символ заменял открывающую английскую двойную кавычку, закрывающую английскую двойную кавычку, дюймы, etc. При переходе к Юникоду обратную совместимость не стали ломать, и клавиша рядом с Enter'ом по прежнему печатает этот «усреднённый» символ. А для правильных знаков введены самостоятельные code points. Популярность старого «искусственного» недосимвола вызвана тем, что он есть на клавиатурной раскладке, а правильных знаков — нет. Поэтому в быту (в аське, в постах, в SMS) используется «программистская кавычка». Но серьёзная типографика должна учитывать различия этих знаков — как разницу в семантике, так и во внешнем виде.
Например, в гарнитуре Times New Roman эти символы имеют совершенно разное начертание:
открывающая английская двойная кавычка: «две-шестёрки-вверху»
закрывающая английская двойная кавычка: «две-девятки-вверху»
дюймы: два наклонных штриха в виде клина (не закорючки)
«программистская кавычка»: два прямых клина, утолщённых сверху.
Что касается статьи — в целом здравая, вполне согласуется с моим опытом (верстал книжки в LaTeX'е для одной типографии).
Модули и сборки не при чём. Вопрос в неоднозначности выбора варианта перегрузки и в неоднозначности выбора перегруженная-функция/каррированная-функция.
Предположим, есть две перегрузки некоторой функции:
SomeFunc: (int) → SomeClass
SomeFunc: (string → int) → SomeClass
let i = test «Hello» // Тип int или string → int, если был бы «вывод типов шиворот навыворот».
let j = SomeFunc i // Какая перегрузка должна вызваться?
Обычно в современных языках тип выражения слева от «=» определяется по типу выражения справа от «=». Ты же предлагаешь наоборот — значение типа справа от «=» выбирать по будущему типу выражения слева от «=».
Не противоречит, если статический тип выражения выводится на основе типов входящих в него подвыражений. Но противоречит, если тип должен определяться контекстом будущего использования.
>… если обязать программиста фиксировать тип интерфейса глобальных публичных объектов.
Это противоречит твоему желанию «[определить тип] по дальнейшему использованию=)»
>Если дальше в коде написано let j = i + 5, то тип i — int, а если написано let j = i «qwerty», то string → int.
Дальнейшее использование может быть слишком «дальнейшим». Например, использование может быть в клиентском коде, т. е. в момент компиляции test «Hello» ничего не известно о том, как результат такого вызова будет использоваться. Грубо говоря, библиотечная функция, возвращающая test «Hello» может быть в одной dll'ке, а твой let j = i + 5 — в другой. Первая dll'ка ничего не должна знать о второй.
>можно было бы использовать вывод типов для разруливания таких проблем.
Как?
let i = test «Hello»
Как определить, i должно иметь тип int или string → int?
>Кажется, что «Размеченное объединение» принято называть алгебраическим типом данных.
Алг. типы данных — более общее понятие. Можно сказать так: алг. типы данных в F# реализованы в терминах размеченных объединений (discriminated unions).
Бросается в глаза чётность букв в каждом слове. Генерируй лучше не парами букв, а выбирай слоги из словаря, это позволит избежать невозможных комбинаций типа «жы».
А почему тогда не использовать более безопасные аналоги sprintf'а с указанием этих размеров? Компилятор ругаться перестанет.
А то и вовсе можно использовать стандартные строковые стримы, Boost.Format, Boost.LexicalCast.
Ни в коем случае! Тогда уж лучше используй «#pragma warning (suppress: номер)» для однократного подавления предупреждений в одной строчке или «disable» в обрамлении «push» и «pop» (http://msdn.microsoft.com/en-us/library/2c8f766e(loband).aspx).
>Мне не нужно ломать отлаженную программу лишь из-за того, что компилятор стал более параноидальным.
Сам не сломаешь — кто-то другой сломает. Отлаженная — это как? Ты поручишься, что обошёл абсолютно все уязвимости printf'а?
Стандарта можешь ты не знать, но книжки Саттера чтить обязан.
И правильно делают. См. хотя бы «Защищённый код».
Перестаньте верить в теории заговора и всемогущество «корпораций». «Корпорации» состоят в конечном счёте из обычных людей, которые в большинстве своём распиздяи частью своей души. Такова природа человека. Поэтому от обычных факапов и проёбов «корпорации» (ещё скажите с пафосом «мафия», ага) не застрахованы. Сегодня она «корпорация», а завтра продаётся с молотка за ящик пива.
По историческим причинам. Во времена телетайпов кодировки были маленькими, клавиатурные раскладки бедными. Один и тот же символ заменял открывающую английскую двойную кавычку, закрывающую английскую двойную кавычку, дюймы, etc. При переходе к Юникоду обратную совместимость не стали ломать, и клавиша рядом с Enter'ом по прежнему печатает этот «усреднённый» символ. А для правильных знаков введены самостоятельные code points. Популярность старого «искусственного» недосимвола вызвана тем, что он есть на клавиатурной раскладке, а правильных знаков — нет. Поэтому в быту (в аське, в постах, в SMS) используется «программистская кавычка». Но серьёзная типографика должна учитывать различия этих знаков — как разницу в семантике, так и во внешнем виде.
Например, в гарнитуре Times New Roman эти символы имеют совершенно разное начертание:
открывающая английская двойная кавычка: «две-шестёрки-вверху»
закрывающая английская двойная кавычка: «две-девятки-вверху»
дюймы: два наклонных штриха в виде клина (не закорючки)
«программистская кавычка»: два прямых клина, утолщённых сверху.
Что касается статьи — в целом здравая, вполне согласуется с моим опытом (верстал книжки в LaTeX'е для одной типографии).
Есть GAC.
Предположим, есть две перегрузки некоторой функции:
SomeFunc: (int) → SomeClass
SomeFunc: (string → int) → SomeClass
let i = test «Hello» // Тип int или string → int, если был бы «вывод типов шиворот навыворот».
let j = SomeFunc i // Какая перегрузка должна вызваться?
Обычно в современных языках тип выражения слева от «=» определяется по типу выражения справа от «=». Ты же предлагаешь наоборот — значение типа справа от «=» выбирать по будущему типу выражения слева от «=».
Не противоречит, если статический тип выражения выводится на основе типов входящих в него подвыражений. Но противоречит, если тип должен определяться контекстом будущего использования.
>… если обязать программиста фиксировать тип интерфейса глобальных публичных объектов.
Это противоречит твоему желанию «[определить тип] по дальнейшему использованию=)»
F# строго типизированный язык.
>Если дальше в коде написано let j = i + 5, то тип i — int, а если написано let j = i «qwerty», то string → int.
Дальнейшее использование может быть слишком «дальнейшим». Например, использование может быть в клиентском коде, т. е. в момент компиляции test «Hello» ничего не известно о том, как результат такого вызова будет использоваться. Грубо говоря, библиотечная функция, возвращающая test «Hello» может быть в одной dll'ке, а твой let j = i + 5 — в другой. Первая dll'ка ничего не должна знать о второй.
Как?
let i = test «Hello»
Как определить, i должно иметь тип int или string → int?
>Кажется, что «Размеченное объединение» принято называть алгебраическим типом данных.
Алг. типы данных — более общее понятие. Можно сказать так: алг. типы данных в F# реализованы в терминах размеченных объединений (discriminated unions).
Смотреть видеоролики не так напряжно, как идти чего-то ресерчить. Начни с презентации на PDC 2008, 300 Мб: channel9.msdn.com/pdc2008/TL11/
>А теперь у нас есть F# и решить эту задачу можно вот так-то.
В этом докладе есть подобные наглядные примеры.
Впрочем, в моём ЖЖ тоже пара слов о сабже есть: bik-top.livejournal.com/31134.html
Это он на «КРИ 2008» очень здорово жёг про MMORPG?
Проверка: должен быть на той же высоте и той же ширины, что и плюс.