Здравствуйте, BulatZiganshin, Вы писали:
VD>>Звучит все складно, как в пвсевдо-научных статьях, но с практиков не коррелирует.
BZ>ты внимательно прочёл?
Вполне.
BZ>я сказал, что 1) нужна проверка типов. которой нет в шаблонах, а не Немерле.
Твоя цитата:
у тебя в шаблонах/макросах не появлялось многоэтажных сообщений об ошибках, нужна типизация
?
BZ>2) что помимо проверки типов нужно много других вещей, которые опять же нужно программировать. к примеру поддержка номеров строк для отладчика
При программировании вообще нужно много программировать, но это же не причина не заниматься программированием?
Если серьезно, то конечно проблемы есть и создание макросов далеко не самое простое занятие. Но дела обстаят не так печально как тебе кажется. Те же номера строк (точнее местоположения) автоматом расставляются для кусков кода которые передаются в качестве параметров макросов, так что вручную их устанавливать приходится крайне редко.
Главное же, что макры (особенно если они хорошо спроектированы и реализованы) позволяют частенько воистину творить чудеса. Так что сложности при разработке макросов с лихвой окупаются тем что они позволяют делать.
Ну, а разговоры о сложности отладки кода использующего макросы — это не более чем досужие домыслы. Отлаженный макрос ничем не отличается от отлаженных фич языка. Да по сути макрос — это и есть часть языка. Разница только в том, что это не обязательная часть языка (ее можно не использовать), и в том, что ты сам можешь написать эту часть.
В общем, те кто провали на практике в 100% случаев расставались с пессимизмом по этому вопросу. Поверь на слово, или проверь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Aleх, Вы писали:
A>Ну вот в Clang (компилятор С++ под виртульную машину LLVM) вроде бы в отношении сообщений об ошибках много что сделано.
Я не утверждаю что сделать ничего нельзя. Я утверждаю, что а) это сложн, и б) во многих случаях просто недостаточно информации (например, при компиляции шаблонов).
A>PS Я уже несколько дней думаю над тем, что же всё таки лучше — однозначный синтаксис или нет.
Еже понятно что чем однозначнее синтаксис тем лучше. Вопрос только в том, чтобы при этом язык удовлетворял потребностям пользователей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
K>>>А как совмещать продолжения и RAII?
VD>>GC
BZ>gc не заменяет raii, поскольку не гарантирует вызов деструктора в детерминированный момент времени
Он устраняет необходимость в использовании raii для контроля памяти, а это в С++ 99% случаев использования raii. Оставшиеся копейки легко автоматизируются. Не мне тебе рассказыать, что в языках со встроенным GC особых проблем с управлением ресурсов нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
BZ>>>>новое — это хорошо разрекламированное старое синтаксические макросы хорошо известны с 60-х, как и их недостатки
VD>>>Если не изменяет память, макросы в Лиспе
BZ>>http://en.wikipedia.org/wiki/General_purpose_macro_processor
VD>Ну, и причем тут текстовые макросы?
Здравствуйте, VladD2, Вы писали:
K>>>>А как совмещать продолжения и RAII?
VD>>>GC
BZ>>gc не заменяет raii, поскольку не гарантирует вызов деструктора в детерминированный момент времени
VD>Он устраняет необходимость в использовании raii для контроля памяти, а это в С++ 99% случаев использования raii. Оставшиеся копейки легко автоматизируются
Здравствуйте, VladD2, Вы писали:
VD>Твоя цитата: VD>
VD> у тебя в шаблонах/макросах не появлялось многоэтажных сообщений об ошибках, нужна типизация
VD>?
так ты и написал что в Немерле тип проверить можно
BZ>>2) что помимо проверки типов нужно много других вещей, которые опять же нужно программировать. к примеру поддержка номеров строк для отладчика
VD>При программировании вообще нужно много программировать, но это же не причина не заниматься программированием?
VD>Если серьезно, то конечно проблемы есть и создание макросов далеко не самое простое занятие. Но дела обстаят не так печально как тебе кажется. Те же номера строк (точнее местоположения) автоматом расставляются для кусков кода которые передаются в качестве параметров макросов, так что вручную их устанавливать приходится крайне редко.
VD>Главное же, что макры (особенно если они хорошо спроектированы и реализованы) позволяют частенько воистину творить чудеса. Так что сложности при разработке макросов с лихвой окупаются тем что они позволяют делать.
VD>Ну, а разговоры о сложности отладки кода использующего макросы — это не более чем досужие домыслы. Отлаженный макрос ничем не отличается от отлаженных фич языка. Да по сути макрос — это и есть часть языка. Разница только в том, что это не обязательная часть языка (ее можно не использовать), и в том, что ты сам можешь написать эту часть.
VD>В общем, те кто провали на практике в 100% случаев расставались с пессимизмом по этому вопросу. Поверь на слово, или проверь.
вот что мы имеем:
1. пробовали их ещё десятки лет назад. и тогда же было описано, что макросы — не панацея
2. с тех пор макросы не стали популярней, хотя реализация их по нынешним временам — пустяк
3. сложность компилятора значительно сложнее сложности макропроцессора, а ведь это ещё не единственный компонент, требующий поддержки каждой новой фичи языка
4. на другой чаше весов мы имеем мнение фанатика Немерле
ps: тебе самому отсутствие опыта работы в хаскеле никогда не мешало хаять его фичи, причём даже не на основании чтения умных книг, а "революционного чутья". теперь же наличие опыта работы превратилось в главный критерий, позволяющий судить о вещи. один этот факт говорит о том, что дискутировать с тобой бесполезно
Здравствуйте, BulatZiganshin, Вы писали:
BZ>>>>>новое — это хорошо разрекламированное старое синтаксические макросы хорошо известны с 60-х, как и их недостатки
VD>>>>Если не изменяет память, макросы в Лиспе
BZ>>>http://en.wikipedia.org/wiki/General_purpose_macro_processor
VD>>Ну, и причем тут текстовые макросы?
BZ>текстовые макросы = синтаксические макросы
вот тут я ошибся. синтаксические макросы — это более развитый вариант текстовой подстановки и GPM — одна из систем синтаксических макросов
Здравствуйте, Aleх, Вы писали:
A>compile-time потому что подстановки шаблонов выполняются во время компиляции. A>dynamic typing потому что эти подстановки шаблонов не типизированы.
Тут путаница получается. Dynamic typing — это означает, что типы проверяются на этапе выполнения. Да и они типизированы — утиным способом. И статически.
A>То есть получается вычисление типов, где типы не имеют статически определенных типов (чтобы не было повторов слов, можно сказать супертипов или классов типов)
Они статически определены, просто в виде контракта не записываются — что, конечно, минус. Концепты вообще, по моему мнению, самое полезное из планировавшихся нововведений в C++.
template<class A, class B>
^
|
не указано, что представляет собой тип, какими свойствами и методами он обладает.
Он обладает теми методами, которые используются ниже. Да, типизация утиная, но статическая. Никакой динамики тут нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Mazay, Вы писали:
M>Функции этапа компиляции могут применяться для того, чтобы управлять генерацией машинного кода и курочить AST. С их помощью можно научить компилятор новым синтаксическим конструкциям, навешать любую метаинформацию, ввести атрибуты для всего, что только можно — полей, методов, классов, блоков кода, переменных и функций и т. д.
Это уже макросы. Тут-то явно другой случай. Ф-я, которая вычисляет в компайл-тайм значение времени компиляции из значения времени компиляции. Никакой сложной работы в АСТ тут нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, dilettante, Вы писали:
D>А зачем совмещать продолжения и RAII? Если же речь о вызове деструкторов — то так же, как сейчас — при выходе из блока.
При котором выходе из блока? Продолжения позволят выходить из блока сколько угодно раз. И не дают никакой возможности узнать какой выход будет последним в общем случае.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Ну ладно, отказались мы от детерминированного освобождения памяти. Тут я не против. Ну а как быть с детерминированным освобождением остальных ресурсов? Продолжения делают любое детерминированное освобождение невозможным — т.е. любой аналог using тоже работать не будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
VD>>В общем, не стоит обсуждать то что не пробовал на практике.
K>Вообще — он автор туториалов по Template Haskell.
Влад имеет в виду Немерле, который имеет свои особенности
>Я, собственно, потому и удивился, что он как-то невнятно изъясняется.
Здравствуйте, Caracrist, Вы писали:
C>Мне не так уж и много надо.
C>1. break [what]; continue [what]; C>возможность делать break(и continue) из любого скоупа, а не только цикла. Плюс параметризировать. C>число говорит сколько скоупов оборвать, а назавание цыкла говорит какой первый встречающийся цикл оборвать. Через запятую перечисление последовательных обрывов.
лишние связи в программе. Добавить новый скоуп будет просто нельзя без тотальной проверки внутренностей на предмет таких вот "счетчиков".
C>например если написанно: C>
C>{
C> while(true)
C> {
C> break 2; // это ведет
C> }
C>} // сюда
C>
добавим один if: C>
C>{
C> if (....)
C> {
C> while(true)
C> {
C> break 2; // это ведет
C> }
C> } // сюда
C> }
C>
совсем не то, что ожидалось, не так ли? А если еще и скобок внутри if не поставить — вообще сказка, не так ли?
C>
C>while (true)
C>{
C> {
C> break while; // это ведет
C> }
C>} // сюда
C>
а если так: C>
C>while (true)
C>{
C> while (....)
C> {
C> break while; // это ведет -
C> }// сюда
C>}
C>
то как попасть на метку "сюда?" (выход из двух одинаковых циклов)
и как безболезненно сменить тип цикла while на for без полного пересмотра и правки кода внутри?
C>3. goto case; как в C#
не надо
Здравствуйте, Klapaucius, Вы писали:
D>>А зачем совмещать продолжения и RAII?
K>При котором выходе из блока? Продолжения позволят выходить из блока сколько угодно раз. И не дают никакой возможности узнать какой выход будет последним в общем случае.
Ну так выход — не использовать локальные объекты, подлежащие уничтожению, в таких блоках. Это однако не означает невозможность использовать RAII с продолжениями в общем случае, например, в википедии, в примере (который на С, но представим, что это С++) можно использовать RAII в любом месте, кроме последнего if (потому что из него программа не выходит).
Здравствуйте, Мишень-сан, Вы писали:
МС>Здравствуйте, Mazay, Вы писали:
M>>Вот, кстати, ещё одно свидетельство того, что программисты хотят программировать не только для компьютера, но для компилятора.
МС>Не думаю, что большинству программистов нафик впалось писать для компилятора. Просто если некие сложные расчёты будут проделаны компилятором один раз, при каждом запуске можно будет на халяву пользоваться готовым результатом, а не считать всё заново.
знаешь, наш предыдущий проект собирался "с нуля" больше чем за сутки у виндовс-товарищей. У нас (линуксоидов) — часа два-три.
Это не проблема, если ты ведешь сборку редко. Но вот если приходился лезть в самые глубины (как-то в мозиллу) — то начинается пересборка чуть не всего проекта. Начинаешь задумываться об оптимизации системы сборки.
Сейчас тоже весело, когда приходится править что-то в библиотеке, которая на шаблонах построена так, что мама не горюй. Любители те еще писали. Разве что НОД не вычисляют на шаблонах.....
Здравствуйте, BulatZiganshin, Вы писали:
BZ>вообще верит в макросы может только человек которыми ими никогда не пользовался. представь себе хотя бы отладку кода, используюшего макросы....
Вообще верить в безумную сложность отладки макросов может только человек, которыми ими никогда не пользовался.
Я этим занимаюсь регулярно, и не с сахарными макросами Немерле, а с кондовым сишным препроцессором (программируемым при помощи Boost.Preprocessor).
И ничего, все замечательно и быстро отлаживается.
Здравствуйте, Мишень-сан, Вы писали:
МС>Вообще же мне не совсем понятно, в какую сторону несёт новый стандарт — вводят какой-то зоопарк сказочных конструкций (как пример — альтернативный typedef и новый формат декларации функций), но при этом выбрасывают такие вещи как концепты. О стандарте на ABI и полноценных модулях остаётся только мечтать.
Ты как-то огульно кучу полезных вещей записал в сказочные конструкции, не очень понятно, с какой целью
Навскидку, не заглядывая в реальный список — auto, rvalue references, variadic templates, variadic macros, memory model, threads, локальные классы как аргументы шаблонов, range-based loop, атрибуты функций/классов/переменных, initializer lists.
Если в список заглянуть — так еще с десяток необходимых вещей наберется.
А концепты не выбросили, их просто признали не готовыми к публикации в этой версии стандарта.
Никто их важности не отрицает, просто фичу такого масштаба сложно встроить в такой огромный язык, как С++, и чтоб при этом ничего не поломалось и чтоб можно было фичей удобно пользоваться.
Это не D и не Python, где один человек принимает все решения и сует в язык каждую понравившуюся ему фичу, а потом чешет репу, глядя на зоопарк несовместимых друг с другом фич, который у него получился, и переписывает все нафиг, делая несовместимые версии языка. Тут люди задумываются над когерентностью языка. С++0x полностью совместим с С++03, с поправкой на неизбежную проблему с новыми ключевыми словами.
В общем, если действительно интересно — читай интервью по поводу выкидывания концепций из _этого_ стандарта.
синтаксические макросы хорошо известны с 60-х, как и их недостатки
