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