> 1. Написание программы на русском;
> целый Возраст ученика = 10;
Переменные с пробелами в именах — удачи с парсером (я не говорю что совсем нельзя, это будет или очень сложно или ограничит набор допустимых конструкций).
> 2. Абстрагирование от понятия unit / модуль / файл. Например для написания программы требуется класс КЛАСС.
Модули придуманы для того, чтобы собрать вместе реализацию и предоставить хороший API к ней. Если у вас не будет модулей, куда будете класть все вспомогательные функции и классы? Загрязнять глобальный неймспейс?
У вас по сути получилось 1 класс = 1 модуль.
> 2.1. Следствие из пункта 2. Компилировать нужно только те функции, которые менялись, т.е. уменьшение времени на компиляцию.
Так и запишем, inline в вашем языке запрещён на уровне стандарта.
Уменьшать время компиляции нужно не за счёт этого. В C++, например, время компиляции большое из-за огромных заголовков, которые парсятся и проверяются семантическим анализатором раз за разом при каждом включении.
> 3. Нормальный поиск.
Для C, C++, Objective C — сделано в clang. Идея простая: если язык достаточно сложный (а в случае C++ это так), то нужно интегрировать поиск и автодополнение в настоящий парсер и семантический анализатор, а не создавать отдельные инструменты. Если у вас будет язык специально спроектирован для лёгкого парсинга без обработки всех конструкций (например, можно легко пропускать тела функций), то только тогда отдельный инструмент будет давать полностью удовлетворительные результаты. (лично я считаю это глупостью — проектировать язык для удобного поиска ущербными инструментами)
> 4. Работа с классами должна быть похожа на работу с файлами, как в менеджерах TotalCommander, Far, т.е. удаление, перенос, переименование, создание должны выполняться одной клавишей;
Это работает пока ваша IDE видит весь код. Если в другом проекте есть ссылки на этот класс, то магия перестаёт работать.
> 5. Автоподстановка слов для имён переменных, классов, типов из словаря;
Или это к пункту 3 или я не понял суть вопроса.
> 6. Отладка отдельно взятой функции или куска кода;
А сейчас разве нет? Ставим breakpoint в функции и отлаживаем её.
> 8. Удобная работа с макросами отладки, кроссплатформенности. Т.е. если в проекте не объявлено #define DEBUG, то я не хочу видеть куски отладочного кода.
Не взлетит. Пусть был код:
a();
#ifdef DEBUG
b();
#endif
c();
Ваша IDE показывает его как:
a();
c();
Программист отредактировал:
a();
foo();
c();
Внимание, вопрос: какой телепатический метод позволит определить, нужно ли вставлять foo() до DEBUG-блока или после?
> Если я правильно помню еще отключается кеширование значения переменной и вынуждает каждый раз читать его.
Вот это (и аналогично про запись: нельзя заменить несколько последовательных записей на одну последнюю) единственное, что записано в стандарте. Про потоки там ни слова.
Вы ничего не сказали про потоки, поэтому скажу я. Для синхронизаций, критических участков и lock-free алгоритмов использовать volatile нельзя, потому что компилятор и ЭВМ могу переупорядочить (и переупорядочивают) записи/чтения volatile и не-volatile переменных. То есть, запись, которая стоит после точки синхронизации, сделанной на цикле из volatile, может переехать в точку до этого цикла.
Ещё раз, предупреждения появились потому что тут всё сворачиваемое выражение видно сразу на этапе обработки AST. Давайте я вам приведу простой пример. LLVM умеет сворачивать x*2/2 -> x. Но не потому что программисты это пишут в коде, а потому что в результате инлайнинга или вынесения общих подвыражений такое часто получается.
> Undefined Behaviour — это ситуация, когда поведение компилятора не определено. И нигде не сказано, что вся программа с UB не имеет смысла.
Программа не имеет смысла без всего этого контекста: определённый ЦП, конкретная версия тулчейна, конкретная версия ОС и может быть даже дата и время.
> Я вот не знаю, каким Вы транслятором транслировали код с этим примером на NULL pastebin.com/MpqKKpyU Вот полный код. gcc 4.6 -O2 убирает проверку на нулевой указатель. Это широко известный (в узких кругах) баг в ядре.
Так в чём суть вашего ответа? Вы спросили существует ли компилятор, который [...]. Да, существует. И какая разница, вопрос технологий или нет. Лучшего у нас нет. А то, что теоретически можно было бы и выдавать диагностику — к вопросу не относится.
A declaration of an identifier for an object that has file scope without an initializer, and without a storage-class specifier or with the storage-class specifier static, constitutes a tentative definition. If a translation unit contains one or more tentative definitions for an identifier, and the translation unit contains no external definition for that identifier, en the behavior is exactly as if the translation unit contains a file scope declaration of that identifier, with the composite type as of the end of the translation unit, with an initializer equal to 0.
int i1 = 1; // definition, external linkage
int i1; // valid tentative definition, refers to previous
Книгу давайте. Про алисинг нельзя гуглить если не знать что (1) он такой существует и (2) как он называется. Таким образом про алиасинг гуглят только те, кто уже в курсе. Если у джуниора код как-то не так себя ведёт, он может только у кого-то более опытного спросить и внезапно узнать про алисинг или прочитать в книге. Так что давайте книгу.
> а как связана проблема strict aliasing и собственно си?
Это неотъемлимая часть стандарта Си, собственно.
> Сначала увидели возможности оптимизации, заюзали ее, потом бац увидали косячок…
Не понял.
> примеры привести с не volatile флагом и циклом ожидания его в соседнем потоке
О, вижу ещё драконов. Можно по-подробнее, что там с volatile и какие гарантии, по вашему мнению, он даёт в многопоточных программах?
> целый Возраст ученика = 10;
Переменные с пробелами в именах — удачи с парсером (я не говорю что совсем нельзя, это будет или очень сложно или ограничит набор допустимых конструкций).
> 2. Абстрагирование от понятия unit / модуль / файл. Например для написания программы требуется класс КЛАСС.
Модули придуманы для того, чтобы собрать вместе реализацию и предоставить хороший API к ней. Если у вас не будет модулей, куда будете класть все вспомогательные функции и классы? Загрязнять глобальный неймспейс?
У вас по сути получилось 1 класс = 1 модуль.
> 2.1. Следствие из пункта 2. Компилировать нужно только те функции, которые менялись, т.е. уменьшение времени на компиляцию.
Так и запишем, inline в вашем языке запрещён на уровне стандарта.
Уменьшать время компиляции нужно не за счёт этого. В C++, например, время компиляции большое из-за огромных заголовков, которые парсятся и проверяются семантическим анализатором раз за разом при каждом включении.
> 3. Нормальный поиск.
Для C, C++, Objective C — сделано в clang. Идея простая: если язык достаточно сложный (а в случае C++ это так), то нужно интегрировать поиск и автодополнение в настоящий парсер и семантический анализатор, а не создавать отдельные инструменты. Если у вас будет язык специально спроектирован для лёгкого парсинга без обработки всех конструкций (например, можно легко пропускать тела функций), то только тогда отдельный инструмент будет давать полностью удовлетворительные результаты. (лично я считаю это глупостью — проектировать язык для удобного поиска ущербными инструментами)
> 4. Работа с классами должна быть похожа на работу с файлами, как в менеджерах TotalCommander, Far, т.е. удаление, перенос, переименование, создание должны выполняться одной клавишей;
Это работает пока ваша IDE видит весь код. Если в другом проекте есть ссылки на этот класс, то магия перестаёт работать.
> 5. Автоподстановка слов для имён переменных, классов, типов из словаря;
Или это к пункту 3 или я не понял суть вопроса.
> 6. Отладка отдельно взятой функции или куска кода;
А сейчас разве нет? Ставим breakpoint в функции и отлаживаем её.
> 8. Удобная работа с макросами отладки, кроссплатформенности. Т.е. если в проекте не объявлено #define DEBUG, то я не хочу видеть куски отладочного кода.
Не взлетит. Пусть был код:
Ваша IDE показывает его как:
Программист отредактировал:
Внимание, вопрос: какой телепатический метод позволит определить, нужно ли вставлять foo() до DEBUG-блока или после?
> поэтому они даже и не почешуться, чтобы выяснить пределы size_t на конкретной платформе и учесть их
Как раз наоборот, если использовать size_t для представления размеров, то не нужно ничего выяснять и учитывать.
Вот это (и аналогично про запись: нельзя заменить несколько последовательных записей на одну последнюю) единственное, что записано в стандарте. Про потоки там ни слова.
Вы ничего не сказали про потоки, поэтому скажу я. Для синхронизаций, критических участков и lock-free алгоритмов использовать volatile нельзя, потому что компилятор и ЭВМ могу переупорядочить (и переупорядочивают) записи/чтения volatile и не-volatile переменных. То есть, запись, которая стоит после точки синхронизации, сделанной на цикле из volatile, может переехать в точку до этого цикла.
Программа не имеет смысла без всего этого контекста: определённый ЦП, конкретная версия тулчейна, конкретная версия ОС и может быть даже дата и время.
> Я вот не знаю, каким Вы транслятором транслировали код с этим примером на NULL
pastebin.com/MpqKKpyU Вот полный код. gcc 4.6 -O2 убирает проверку на нулевой указатель. Это широко известный (в узких кругах) баг в ядре.
A declaration of an identifier for an object that has file scope without an initializer, and without a storage-class specifier or with the storage-class specifier static, constitutes a tentative definition. If a translation unit contains one or more tentative definitions for an identifier, and the translation unit contains no external definition for that identifier, en the behavior is exactly as if the translation unit contains a file scope declaration of that identifier, with the composite type as of the end of the translation unit, with an initializer equal to 0.
int i1 = 1; // definition, external linkage
int i1; // valid tentative definition, refers to previous
?! Нужно переслать матрицу. Зачем её бить на несколько посылок, чтобы скорость передачи уменьшить за счёт нескольких синхронизаций разве что.
> а как связана проблема strict aliasing и собственно си?
Это неотъемлимая часть стандарта Си, собственно.
> Сначала увидели возможности оптимизации, заюзали ее, потом бац увидали косячок…
Не понял.
> примеры привести с не volatile флагом и циклом ожидания его в соседнем потоке
О, вижу ещё драконов. Можно по-подробнее, что там с volatile и какие гарантии, по вашему мнению, он даёт в многопоточных программах?
int count. И эти интерфейсы разрабатывали не кто-то-там, а комитет, в который входят все именитые вендоры.