Проблема в Си в том, что A[N][M] это может быть как массив указателей на одномерные массивы, так и двухмерный массив. А причина этого в глупом (именно так) решении о том, что имя массива эквивалентно указателю на первый элемент массива. Написать символ взятия адреса для получения этого самого указателя не так уж и сложно. А теперь в результате этой «синтаксической оптимизации» мы получили то что массивы не являются «объектами первого класса». Их нельзя передавать в функции именно как массивы; нельзя возвращать из функций именно как массивы.
Простите, это как? После стольких лет развития компиляторов они не могут распарсить длинное (да не такое уж и длинное) выражение??? Почему аналогичное выражение на С/С++ (да и на любом другом языке) парсится без каких-либо проблем?
Кто там у них компиляторы пишет?
Я хочу чтобы в мейнстриме появился нормальный компилируемый язык со статической типизацией для веб-разработки. Да, конечно что-то есть, можно хоть на си писать сайты… но это не распространено. А распространены именно динамически типизированные языки php, python, ruby и js. Интересно почему?
Об уровне — это чистая правда. Я не веб-разработчик, но когда в старые времена для каких-то целей нужно было создать сайтик (по сути простой веб-интерфейс для доступа к БД в локалке), я это сделал на «php4» вообще не задумываясь — настолько все было просто.
Что там творится теперь — мне непонятно. Уровень абстракции очень сильно вырос, количество абстрактных прослоек выросло, и это привело к тому что я «не чувствую» ни сложности алгоритмов, ни низкоуровневой структуры программы. То есть современные фреймворки работают, но их работа превратилась в некую магию, для полного понимания которой нужно, вероятно, глубоко изучить внутреннюю структуру фреймворков на самом низком уровне. Все ли к этому готовы?
Все руководства по фреймвокам сводятся к написанию «hello-world» сайтов практически без объяснения внутренней работы самого фреймворка. Я после безуспешных поисков такого глубокого руководства пытаюсь сам разобраться понемногу в свободное время, может статью напишу:)
Простите, а в каких реальных компиляторах применяется это маркирование?
Я смотрел исходники реальных компиляторов, и писал их сам, и нигде такие сложности не требовались. Обычно на входе лексера поток символов из файла, внутри машина состояний, на выходе поток токенов-лексем. Все ситуации с кавычками внутри комментариев и комментариями внутри кавычек разруливаются автоматически, мне даже не приходило в голову что это может представлять какую-то сложность и тем более предмет для спора.
Ну так лексер как раз и делает то что нужно. Машина состояний же — если встретили кавычку, переходим в режим «строка» и ждем закрывающую кавычку (возможно с учетом экранирующих символов). Встретили начало комментария — переходим в режим «ожидание конца комментария» и т.д.
Лексический анализ ведет к упрощению архитектуры компилятора. Дело тут не в древних временах, а именно в архитектуре. Лексер выделяет ключевые слова, идентификаторы, операторы, строковые и числовые литералы, выкидывает комментарии и пробельные символы, превращая хаос текстового ввода в упорядоченную структуру однотипных объектов-токенов. Это очень сильно упрощает работу парсера именно архитектурно.
Интересно насколько глубоко он сможет погрузиться в атмосферу Сатурна прежде чем потеряет возможность передавать данные.
А вообще конечно напрашивается мысль о необходимости создания постоянных ретрансляторов на орбитах всех планет, чтобы исследовательские аппараты могли передавать больше информации.
И еще интересно, можно ли разработать «твердотельный» зонд, который мог бы передавать информацию (и в частности видео) при погружении в планеты-гиганты максимально долго.
У них расширения в том числе и для режима компиляции C90 (многие расширения в этом списке именно такие). И кроме того я хотел упомянуть про десигнаторы потому, что они не включены в расширения С++, а хотелось бы :)
Изменить форму ведра и посмотреть что получится — это в общем несложно и недорого. А полученная информация вполне может натолкнуть ученых на правильный путь построения точной модели…
Отличная статья! Хотя и переведено полуавтоматически, и фигня откровенная в некоторых пунктах, но в целом это можно использовать как краткий справочник по особенностям языков программирования. Мне как человеку увлекающемуся языками программирования как таковыми очень пригодится.
Антропный принцип тут не при чем. Даже если бы никаких людей не было бы, константы были бы все равно одинаковые везде. И это само по себе очень интересно.
Есть что-то, что обеспечивает например единый заряд электрона для всех электронов Вселенной. Это можно интерпретировать как статическую переменную, где этот заряд хранится. До сих пор наука изучает законы физики в read-only режиме, но никто не задавался вопросом (да, это все «очень теоретически» но все-же) — а возможно ли что-то поменять? Возможно ли во Вселенной изменение каких-то факторов, изнутри или извне, при которых фундаментальные константы или функции изменятся?
В которых нет универсальности на все случаи жизни, но есть лишь строго самое необходимое?
Кто там у них компиляторы пишет?
Об уровне — это чистая правда. Я не веб-разработчик, но когда в старые времена для каких-то целей нужно было создать сайтик (по сути простой веб-интерфейс для доступа к БД в локалке), я это сделал на «php4» вообще не задумываясь — настолько все было просто.
Что там творится теперь — мне непонятно. Уровень абстракции очень сильно вырос, количество абстрактных прослоек выросло, и это привело к тому что я «не чувствую» ни сложности алгоритмов, ни низкоуровневой структуры программы. То есть современные фреймворки работают, но их работа превратилась в некую магию, для полного понимания которой нужно, вероятно, глубоко изучить внутреннюю структуру фреймворков на самом низком уровне. Все ли к этому готовы?
Все руководства по фреймвокам сводятся к написанию «hello-world» сайтов практически без объяснения внутренней работы самого фреймворка. Я после безуспешных поисков такого глубокого руководства пытаюсь сам разобраться понемногу в свободное время, может статью напишу:)
Я смотрел исходники реальных компиляторов, и писал их сам, и нигде такие сложности не требовались. Обычно на входе лексера поток символов из файла, внутри машина состояний, на выходе поток токенов-лексем. Все ситуации с кавычками внутри комментариев и комментариями внутри кавычек разруливаются автоматически, мне даже не приходило в голову что это может представлять какую-то сложность и тем более предмет для спора.
А вообще конечно напрашивается мысль о необходимости создания постоянных ретрансляторов на орбитах всех планет, чтобы исследовательские аппараты могли передавать больше информации.
И еще интересно, можно ли разработать «твердотельный» зонд, который мог бы передавать информацию (и в частности видео) при погружении в планеты-гиганты максимально долго.
Интересны не конкретные значения констант, а их константность как таковая.
Есть что-то, что обеспечивает например единый заряд электрона для всех электронов Вселенной. Это можно интерпретировать как статическую переменную, где этот заряд хранится. До сих пор наука изучает законы физики в read-only режиме, но никто не задавался вопросом (да, это все «очень теоретически» но все-же) — а возможно ли что-то поменять? Возможно ли во Вселенной изменение каких-то факторов, изнутри или извне, при которых фундаментальные константы или функции изменятся?