Тема: Почему большинство софта для *nix систем написано на С, а не на С++

Ответить в теме
Страница 6 из 6 ПерваяПервая ... 4 5 6
Показано с 101 по 109 из 109
  1. Вверх #101
    Частый гость Аватар для homo ludens
    Пол
    Мужской
    Сообщений
    751
    Репутация
    141
    Итак, про глупость.

    В этом посте я пока разберусь только с одной глупостью - с непониманием понятия сложности компиляции и тьюринговской полноты одним отдельно взятым плюсовиком.
    Про автоматы, IBM и другие интересные глупости поговорим в отдельном посте.

    Повторю свои слова - для сферического компилятора в вакууме (т.е. без дополнительных фич, без препроцессора, без оптимизации и без ограничений - чистый парсинг и кодогенерация) имеем следующие верхние пороги времени компиляции.
    C - линейная.
    C++ - бесконечная.

    Доказательство.
    1. Теоретическое.
    Посылки:
    Шаблоны реализуют Тьюринг-полную модель вычислений во время компиляции.
    Программа на Тьюринг-полном языке может выполняться бесконечно.
    Не существует алгоритма, способного определить - бесконечно ли выполняется программа.

    Вывод:
    Для компилятора С++ с учетом отсутствия ограничений возможно создание программы, компилирующейся вечно.
    Для С (даже с учетом препроцессора) модель компиляции тьюринг-полной не является.
    Препроцессор не рекурсивен, знаете ли.

    2. Экспериментальное.
    Pal к сожалению, как его ни просили, не захотел указать список кошерных компиляторов С++. По моему мнению этот список эквивалентен пустому множеству.
    Но так как что-то взять надо - возьмем обычный gcc4.
    Вспомнив слова Pal
    Цитата Сообщение от pal Посмотреть сообщение
    потому что, если бы ты узнал об этом из стандарта, то ты бы также знал, что все, что требует больше 17 шагов - не с++
    можно удивиться, что gcc - это не С++, поскольку у него стоит ограничение шаблонной рекурсии не 17, а 500.
    Но вспомнив другие слова Pal, можно уже ничему не удивляться.
    Чтобы привести компилятор к сферическому коню в вакууме мы будем использовать параметр -ftemplate-depth-5000.

    Программа 1 - функция Аккерманна.
    Код:
    template <int x, int y> struct Ackermann
    {
       enum  {  val = Ackermann<x-1, Ackermann<x, y-1> ::val>::val   };
    };
    
    template <int y> struct Ackermann<0, y>
    {
       enum { val = y + 1 };
    };
    
    template <int x> struct Ackermann<x, 0>
    {
       enum 
       { 
          val = Ackermann<x-1, 1>::val
       };
    };
    
    int main(void)
    {
      return Ackermann<XXX,YYY>::val;
    }
    Функция растет очень быстро, тем кто прогуливал и не знает, что это за функция - в педивикию.

    Итак, что имеем на 25 строк кода.

    Код:
    [dEEpl0y@delirium template]$ time g++ -DXXX=1 -DYYY=1 -ftemplate-depth-5000 -c ackermann.cc
    0.00user 0.02system 0:00.03elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+16outputs (0major+4371minor)pagefaults 0swaps
    
    [dEEpl0y@delirium template]$ time g++ -DXXX=4 -DYYY=1 -ftemplate-depth-5000 -c ackermann.cc
    x86_64-alt-linux-g++: Internal error: Segmentation fault (program cc1plus)
    Please submit a full bug report.
    See <http://bugzilla.altlinux.org> for instructions.
    Command exited with non-zero status 1
    132.28user 0.27system 2:12.55elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (0major+32539minor)pagefaults 0swaps
    Через 132 секунды компиляции 25 строк кода компилятор пукнул и умер.

    PS
    Да, кстати про 17 уровней.
    Pal написал вот такой интересный текст.
    Цитата Сообщение от pal Посмотреть сообщение
    потому что, если бы ты узнал об этом из стандарта, то ты бы также знал, что все, что требует больше 17 шагов - не с++
    Но вот стандарт, говорит совсем другое.

    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf
    AnnexB p1246

    The limits may constrain quantities that include those described below or others. The bracketed number following each quantity is recommended as the minimum for that quantity. However, these quantities are only guidelines and do not determine compliance.
    И на следующей странице читаем

    - Recursively nested template instantiations [17].
    Не соблаговолит ли господин Pal объяснить это мелкое несоответствие, и на каком основании он присвоил себе право решать - что является С++, а что - нет.
    И не соблаговолит ли господин Pal сообщить все-таки список кошерных (по его мнению) компиляторов С++? Второй раз прошу, между прочим.
    The future is already here - it is just unevenly distributed. (c) W. Gibson


  2. Вверх #102
    Частый гость Аватар для homo ludens
    Пол
    Мужской
    Сообщений
    751
    Репутация
    141
    И еще по примеру pal.

    Имеем время препроцессора - линейное O(n)
    На выходе препроцессора иеем n->m символов (m>n)
    Имеем линейное время компиляции O(m)

    На этом основании можно сказать что время компиляции и препроцессирования будет равно O(n) + O(m)
    Что естественно больше чем O(n)
    Но это вообще-то подлог - говорили мы о компиляции.
    И только о компиляции.
    Более того, о компиляции без оптимизации (а там шайтанов своих тоже хватает)
    И кроме того повторяю еще раз - даже с препроцессором компиляция С не будет бесконечной.
    А в С++ - даже без препроцессора - будет.

    PS
    Тут в связи с жестоким миксом дедлайнов и маевок времени торчать на форме почти нет.
    Однако ответы на высказывания pal - дам обязательно.
    А на ближайшей корпоративной маевке проведу эксперимент - пройду по плюсовикам и проверю - не приехал ли кто-то на "мультипарадигменной" машине.
    И не живет ли кто в "мультипарадигменной" палатке.
    А то советовать другим "мультипарадигменный язык" - легко, ЧСВ поднимается до размеров IQ (а иногда и перерастает).
    А вот жить в "мультипарадигменной" квартире почему-то никто не хочет.
    Несмотря на радостные рекомендации восторженниых риэлтеров.

    Я не пользуюсь мультипарадигменной машиной.
    Для поездок на работу в 10 кварталах - беру велосипед.
    Для поездок по городу в пробках на большие расстояния - Toyota Prius the best.
    Для поездок бухим по клубам - вызываю такси.
    А за город со спуском на пляж - Нива.
    И пытаться совместить все это в одной машине есть глубокое непонимание реальности.
    А пытаться рекомендовать это другим = демонстрировать собой домашние задания из учебника по теории мемов.
    The future is already here - it is just unevenly distributed. (c) W. Gibson

  3. Вверх #103
    Посетитель
    Пол
    Мужской
    Возраст
    46
    Сообщений
    237
    Репутация
    18
    Цитата Сообщение от homo ludens Посмотреть сообщение
    В этом посте я пока разберусь только с одной глупостью -
    ...
    C - линейная.
    C++ - бесконечная.
    сколько не повторяй, оно останется глупостью
    Повторю свои слова - для сферического компилятора в вакууме (т.е. без дополнительных фич, без препроцессора, без оптимизации и без ограничений - чистый парсинг и кодогенерация)
    не было таких слов, так что это не повторение, а жалкая попытка увильнуть
    но можем пройтись и по этому
    если препроцессор - дополнительные фичи, то тебе будет очень трудно найти программу на с без дополнительных фич. можно сказать, что язык с вобще перестанет существовать
    если без ограничений, то на невоображаемых компьютерах на любом языке можно придумать программу, которая не скомпилируется потому как не влезет

    однако, это все твои личные фантазии, стандарт говорит о наличии огранничений и о директивах препроцессора
    Для компилятора С++ с учетом отсутствия ограничений возможно создание программы, компилирующейся вечно.
    отсутствие ограничений высосано тобой из пальца
    ты можешь приписывать языку какие угодно вымышленные свойства, но все выводы, построенные на них, не будут иметь ничего общего с реальностью
    Препроцессор не рекурсивен, знаете ли.
    знаем
    но и не линеен, а ты пытался втереть именно это
    можно удивиться, что gcc - это не С++, поскольку у него стоит ограничение шаблонной рекурсии не 17, а 500.
    тут нечему удивляться, это ни для кого не секрет
    у gcc много расширений, меняющихся от версии к версии, в том числе и это
    Чтобы привести компилятор к сферическому коню в вакууме мы будем использовать параметр -ftemplate-depth-5000.
    во первых, строго говоря, чтобы сделать время компиляции бесконечным, глубина рекурсии должна быть не 5к, а тоже бесконечной
    во вторых, ты никак не изменил стандарт с++ передачей параметров компилятору
    PS
    Да, кстати про 17 уровней.
    Pal написал вот такой интересный текст.
    потому что, если бы ты узнал об этом из стандарта, то ты бы также знал, что все, что требует больше 17 шагов - не с++
    Но вот стандарт, говорит совсем другое.
    совсем-совсем ? опять ничего не понял или прикидываешься ?
    ты забыл процитировать первый пункт про бесконечность
    Because computers are finite, C++ implementations are inevitably limited in the size of the programs they
    can successfully process. Every implementation shall document those limitations where known. This docu-
    mentation may cite fixed limits where they exist, say how to compute variable limits as a function of available
    resources, or say that fixed limits do not exist or are unknown.
    The limits may constrain quantities that include those described below or others. The bracketed number following each quantity is recommended as the minimum for that quantity. However, these quantities are only guidelines and do not determine compliance.
    И на следующей странице читаем
    - Recursively nested template instantiations [17].
    Не соблаговолит ли господин Pal объяснить это мелкое несоответствие, и на каком основании он присвоил себе право решать - что является С++, а что - нет.
    какое мелкое несоответствие ? 17 не совсем равно 17 ?
    там написано, что компиляторам нужно документировать, какую глубину рекурсии они поддерживают и рекомендуется поддерживать не менее 17, но если кто-то вдруг будет поддерживать меньше, то за это его сильно ругать не будут
    я понимаю, что моя интерпретация тебя не устроит и ты продолжишь отмазываться, но почему же ты не прочел документацию на использованный тобой параметр ?
    -ftemplate-depth-n
    Set the maximum instantiation depth for template classes to n. A limit on the template instantiation depth is needed to detect endless recursions during template class instantiation. ANSI/ISO C++ conforming programs must not rely on a maximum depth greater than 17.
    И не соблаговолит ли господин Pal сообщить все-таки список кошерных (по его мнению) компиляторов С++? Второй раз прошу, между прочим.
    второй раз отправляю в гугл
    Цитата Сообщение от homo ludens Посмотреть сообщение
    И еще по примеру pal.

    Имеем время препроцессора - линейное O(n)
    На выходе препроцессора иеем n->m символов (m>n)
    Имеем линейное время компиляции O(m)

    На этом основании можно сказать что время компиляции и препроцессирования будет равно O(n) + O(m)
    Что естественно больше чем O(n)
    Но это вообще-то подлог - говорили мы о компиляции.
    И только о компиляции.
    Более того, о компиляции без оптимизации (а там шайтанов своих тоже хватает)
    подлогом тут занимаешься ты
    пойди прочитай стандарт
    можешь начать с пункта 5.1.1.2
    исходник на с - не вывод препроцессора, а вход
    кстати, об отдельном этапе оптимизации стандарт тоже ничего не говорит

    т.е. ты тут пытаешься утверждать, что либо стандарт запрещает препроцессор и оптимизацию, либо что он их не запрещает, но на самом деле никто ими не пользуется, так что этим можно пренебречь
    и то и другое - чушь

    если ты будешь продолжать утверждать, что исходник на с состоит из вывода препроцессора, я начну утверждать, что исходник на с++ состоит из вывода компилятора и время компиляции является нулевым
    И кроме того повторяю еще раз - даже с препроцессором компиляция С не будет бесконечной.
    А в С++ - даже без препроцессора - будет.
    да повторяй сколько угодно, глупость останется глупостью
    в с++ нету бесконечной глубины рекурсии шаблонов, а в с нерекурсивный препроцессор все равно не влезет в память существующих машин на очень маленьких программах. а чуть выше ты утверждал не про конечность, а про линейность
    я уже не говорю о том, что шаблоны призваны заменить препроцессор и сравнивать их с его отсутствием несколько некорректно
    как не менее некорректно ругать метапрограммы за то, что они могут долго выполняться. почему ты до сих пор используешь язык, на котором можно написать бесконечный цикл?
    Последний раз редактировалось pal; 07.05.2009 в 14:48.

  4. Вверх #104
    Посетитель
    Пол
    Мужской
    Возраст
    46
    Сообщений
    237
    Репутация
    18
    кстати, слухи о нерекурсивности препроцессора сильно преувеличены
    #include рекурсивны и там тоже есть лимит на глубину(минимум 15), который при желании можно повысить
    лол ?

  5. Вверх #105
    Частый гость Аватар для homo ludens
    Пол
    Мужской
    Сообщений
    751
    Репутация
    141
    Цитата Сообщение от pal Посмотреть сообщение
    не было таких слов, так что это не повторение, а жалкая попытка увильнуть
    Пост #33 в этой теме.


    Цитата Сообщение от pal Посмотреть сообщение
    какое мелкое несоответствие ? 17 не совсем равно 17 ?
    Ты заявил, что все что больше 17 - не С++.
    Стандарт однако рекомендует (а не обязывает) значение 17 как минимальное.
    Таким образом если кто-то напишет компилятор с бесконечной вложенностью - это будет С++.
    В отличие от твоего заявления.

    Цитата Сообщение от pal Посмотреть сообщение
    кстати, слухи о нерекурсивности препроцессора сильно преувеличены
    #include рекурсивны и там тоже есть лимит на глубину(минимум 15), который при желании можно повысить
    лол ?
    Напиши функцию Аккермана на препроцессоре.

    Я проясню свою позицию еще раз, если тебе лень читать предыдущие посты.
    Компилятор (да, сферический, в вакууме) можно разбить на три части.
    Препроцессинг, парсинг и генерацию кода.
    Каждый из них - линеен, в некотором приближении конечно, но - линеен.

    1. Линейность препроцессора
    Тут на самом деле как считать.
    Если ты считаешь #include за одну строчку кода - то конечно нелинейная и тогда да, O(infinity).
    А если ты считаешь ее за одну строчку кода плюс количество строк во вкладываемом файле - то увы, линейная.
    И даже если отменить ограничение на количество вложенных инклюдов.
    Более того, даже без этого ограничения - halting problem для препроцессора никак не стоит. В отличие от темплейтов.
    Если считаешь иначе - попробуй на препроцессоре написать функцию Аккермана.

    2. Линейность парсера.
    Ну тут я думаю все понятно. Даже для контекстно-свободных неоднозначных грамматик сложность не превышает O(n^3). А для таких как С и С++ - строго линейная.

    3. Линейность кодогенератора.
    Тут сложнее. Кодогенерация включает в себя кучу алгоритмов, например оптимальной разбивки переменных по регистрам, что ЕМНИП вообще NP-полная задача.
    Но! Эти задачи локальны в пределах блока/области видимости/функции, и в общем виде, в соответствии с правилами O-нотации ими можно пренебречь.
    Результат - O(n). Хотя, возможно O(n log n). Как сделать.

    Теперь о сферическом компиляторе в вакууме, или почему без ограничений.
    O-нотация - это ассимптотика. Соответственно вычислять ее на конечном множестве - все равно что считать lim(n->infinity) на множестве от 0 до 10.
    Поэтому и без ограничений. Потому что с ограничениями - о ужас, на нашей планете не останется Тьюринг-полных языков. Ведь Тьюринг-машина предполагает бесконечную память и время выполнения. И halting problem для конечных языков не стоит - достаточно перебрать все состояния машины.

    Цитата Сообщение от pal Посмотреть сообщение
    как не менее некорректно ругать метапрограммы за то, что они могут долго выполняться. почему ты до сих пор используешь язык, на котором можно написать бесконечный цикл?
    Я не ругаю метапрограммы за то что они могут долго выполняться. Ты плохо читал предыдущие посты. Мои претензии в другом.
    Я не против метапрограммирования, как и не против longjmp, FSM на сервере или даже использования 10-уровневых иерархий наследования.
    Я просто считаю, что нет вещей плохих и хороших, а все - в зависимости от задачи.
    Для каждой задачи есть универсальное решение и есть оптимальное. И в соответствии с теоремой о бесплатном ланче эти два решения обычно не совпадают. Соответственно бывают случаи, когда требуется оптимальное решение, и универсальные способы приходится забыть. Это кстати касается и автоматов на сервере, до которых мы надеюсь доберемся.
    Так вот, о метапрограммировании.
    Мне, на С иногда очень не хватает метапрограммирования. Как и на SQL, и на других языках. Выкручиваюсь кодогенераторами, парсерами, или даже заменой стандартного препроцессора на m4.
    Дизайнеры С++ хотели сделать параметризированную систему типов с сохранением type-safety. Сделали походя метапрограмминг, как побочный результат. Для меня - это признак плохого дизайна.
    Если метапрограмминг - это плохо с точки зрения С++, то нафига его сделали?
    А если это хорошо и правильно - почему они не сделали метапрограмминг полностью, и какого черта в 21-м веке в Qt делает метаобъектный компилятор moc? При таком развитии событий параметризованные типы получались бы как частный случай, но плюс к этому любой используемый сегодня кодогенератор/стаб генератор/метаобъектный компилятор и мелкие примочки типа PIMPL и половины паттернов превратились бы в очердной #metainclude.
    Ты мог бы переопределять модификаторы public/private/protected, любые ключевые слова (например class или const). Но сейчас и здесь - ты гордишься тем что ты можешь перегружать функции и касты?
    Извини, смешно.
    Либо трусы оденьте, либо крестик снимите.
    Или метапрограммирование - плохо, тогда зачем вы его сделали.
    Или это хорошо - тогда почему его сделали так убого, в том же Nemerle все намного интересней.
    Или он получился методом случайных блужданий. И вот эта гипотеза объясняет все.
    The future is already here - it is just unevenly distributed. (c) W. Gibson

  6. Вверх #106
    Посетитель
    Пол
    Мужской
    Возраст
    46
    Сообщений
    237
    Репутация
    18
    Цитата Сообщение от homo ludens Посмотреть сообщение
    Пост #33 в этой теме.
    там ничего не было про "без дополнительных фич, без препроцессора, без оптимизации и без ограничений - чистый парсинг и кодогенерация", зато было про с++, а у с++ есть четкое определение, которое имеет мало общего с твоими фантазиями
    Ты заявил, что все что больше 17 - не С++.
    Стандарт однако рекомендует (а не обязывает) значение 17 как минимальное.
    Таким образом если кто-то напишет компилятор с бесконечной вложенностью - это будет С++.
    В отличие от твоего заявления.
    это уже не смешно
    компилятор будет сответствовать стандарту, а программа, использующая больше 17 уровней, будет соответствовать только этому компилятору
    Напиши функцию Аккермана на препроцессоре.
    ты уже притомил с акерманом
    во первых, твой практический пример не доказал того, что ты обещал
    во вторых, тебе будет очень трудно доказать практическим примером бесконечное время компиляции
    в третьих, если ты до сих пор не остановился, то хотя бы выбери функцию с бесконечной рекурсией
    Я проясню свою позицию еще раз, если тебе лень читать предыдущие посты.
    Компилятор (да, сферический, в вакууме) можно разбить на три части.
    Препроцессинг, парсинг и генерацию кода.
    а можно и на 50
    Каждый из них - линеен, в некотором приближении конечно, но - линеен.
    бред
    1. Линейность препроцессора
    Тут на самом деле как считать.
    Если ты считаешь #include за одну строчку кода
    я это считаю за 8 символов, ты бы еще килограммами мерял
    - то конечно нелинейная и тогда да, O(infinity).
    А если ты считаешь ее за одну строчку кода плюс количество строк во вкладываемом файле - то увы, линейная.
    И даже если отменить ограничение на количество вложенных инклюдов.
    лол
    т.е. ты определил, что время работы препроцессора линейно зависит от числа потраченных тактов процессора
    кто бы сомневался
    Более того, даже без этого ограничения - halting problem для препроцессора никак не стоит. В отличие от темплейтов.
    Если считаешь иначе - попробуй на препроцессоре написать функцию Аккермана.
    мы уже выяснили, что она ни для кого не стоит, а ты все суешь сюда вычислимую функцию
    2. Линейность парсера.
    Ну тут я думаю все понятно. Даже для контекстно-свободных неоднозначных грамматик сложность не превышает O(n^3). А для таких как С и С++ - строго линейная.
    ты уже придумал парсер, не строящий таблицу символов, или таблицу символов с константным временем доступа ?
    и ты используешь необычное определение контекстно-свободности
    3. Линейность кодогенератора.
    Тут сложнее. Кодогенерация включает в себя кучу алгоритмов, например оптимальной разбивки переменных по регистрам, что ЕМНИП вообще NP-полная задача.
    Но! Эти задачи локальны в пределах блока/области видимости/функции, и в общем виде, в соответствии с правилами O-нотации ими можно пренебречь.
    Результат - O(n). Хотя, возможно O(n log n). Как сделать.
    в общем случае пренебречь как раз нельзя, т.к. никто не запрещает иметь один очень большой блок на всю программу
    а еще есть whole program optimization

    но это все не имеет никакого значения, потому что ты непринужденно меняешь n от этапа к этапу
    я предлагаю не ограничиваться полумерами, а выделить по этапу на процессорную инструкцию, выполняемую компилятором
    "а у моего компилятора тысячная инструкция выполняется за такт, а у твоего - за два, следовательно мой компилятор в два раза быстрее \m/"
    Теперь о сферическом компиляторе в вакууме, или почему без ограничений.
    O-нотация - это ассимптотика. Соответственно вычислять ее на конечном множестве - все равно что считать lim(n->infinity) на множестве от 0 до 10.
    это очередная шутка ?
    на бесконечном множестве она вообще никого не интересует, т.к. там в любом случае конца не будет
    Поэтому и без ограничений. Потому что с ограничениями - о ужас, на нашей планете не останется Тьюринг-полных языков. Ведь Тьюринг-машина предполагает бесконечную память и время выполнения. И halting problem для конечных языков не стоит - достаточно перебрать все состояния машины.
    это ужас только для тебя и тьюринг полноту приплетал только ты
    весь остальной мир как жил с ограничениями, так и живет и в ус не дует
    Я не ругаю метапрограммы за то что они могут долго выполняться. Ты плохо читал предыдущие посты. Мои претензии в другом.
    еще раз перечитал твой первый пост и до сих пор не верю
    Я не против метапрограммирования, как и не против longjmp, FSM на сервере или даже использования 10-уровневых иерархий наследования.
    Я просто считаю, что нет вещей плохих и хороших, а все - в зависимости от задачи.
    Для каждой задачи есть универсальное решение и есть оптимальное. И в соответствии с теоремой о бесплатном ланче эти два решения обычно не совпадают. Соответственно бывают случаи, когда требуется оптимальное решение, и универсальные способы приходится забыть.
    казалось бы, как это относится к топику
    Это кстати касается и автоматов на сервере, до которых мы надеюсь доберемся.
    Так вот, о метапрограммировании.
    Мне, на С иногда очень не хватает метапрограммирования. Как и на SQL, и на других языках. Выкручиваюсь кодогенераторами, парсерами, или даже заменой стандартного препроцессора на m4.
    Дизайнеры С++ хотели сделать параметризированную систему типов с сохранением type-safety. Сделали походя метапрограмминг, как побочный результат. Для меня - это признак плохого дизайна.
    ты себе льстишь, если думаешь, что они старались для тебя
    Если метапрограмминг - это плохо с точки зрения С++, то нафига его сделали?
    А если это хорошо и правильно - почему они не сделали метапрограмминг полностью,
    а ты почему не сделал ? а остальные почему не сделали ?
    наверное, потому что не успели
    и какого черта в 21-м веке в Qt делает метаобъектный компилятор moc?
    я уже говорил, что qt - не с++
    какой спрос с людей, не слышавших об стл ?
    используй gtkmm
    При таком развитии событий параметризованные типы получались бы как частный случай, но плюс к этому любой используемый сегодня кодогенератор/стаб генератор/метаобъектный компилятор и мелкие примочки типа PIMPL и половины паттернов превратились бы в очердной #metainclude.
    Ты мог бы переопределять модификаторы public/private/protected, любые ключевые слова (например class или const).
    у тебя какая-то каша в голове
    с++ - не изменяемый, а дополняемый язык
    если переопределять + на -, то это потом никто не поймет, а если очень хочется, то используй любой кодогенератор/препроцессор, только потом не жалуйся
    Но сейчас и здесь - ты гордишься тем что ты можешь перегружать функции и касты?
    мне тут нечем гордиться, но если бы я участвовал в создании, то гордился бы тем, что вышел самый мощный язык общего назначения из имеющихся
    Извини, смешно.
    Либо трусы оденьте, либо крестик снимите.
    Или метапрограммирование - плохо, тогда зачем вы его сделали.
    Или это хорошо - тогда почему его сделали так убого, в том же Nemerle все намного интересней.
    Или он получился методом случайных блужданий. И вот эта гипотеза объясняет все.
    я понял, в чем твоя проблема
    ты хочешь пони
    Последний раз редактировалось pal; 18.05.2009 в 01:38.

  7. Вверх #107
    Частый гость Аватар для homo ludens
    Пол
    Мужской
    Сообщений
    751
    Репутация
    141
    Цитата Сообщение от pal Посмотреть сообщение
    там ничего не было про "без дополнительных фич, без препроцессора, без оптимизации и без ограничений - чистый парсинг и кодогенерация", зато было про с++, а у с++ есть четкое определение, которое имеет мало общего с твоими фантазиями
    Там было про сферический компилятор С++ в вакууме.
    После твоих постов я уточнил, что я понимаю под сферичностью.

    Цитата Сообщение от pal Посмотреть сообщение
    это уже не смешно
    компилятор будет сответствовать стандарту, а программа, использующая больше 17 уровней, будет соответствовать только этому компилятору
    Это уже не смешно. Программа, использующая больше 17 уровней будет компилироваться (а не соответствовать) на этом компиляторе и на любом компиляторе, поддерживающем количество уровней больше 17.
    И безусловно будет программой не на бейсике, а на С++.
    И соответствовать стандарту, так как ни одного обязательного пункта стандарта не нарушает.

    Цитата Сообщение от pal Посмотреть сообщение
    ты уже притомил с акерманом
    во первых, твой практический пример не доказал того, что ты обещал
    во вторых, тебе будет очень трудно доказать практическим примером бесконечное время компиляции
    в третьих, если ты до сих пор не остановился, то хотя бы выбери функцию с бесконечной рекурсией
    Если притомил - извини, я честно не для того здесь запостил чтобы тебя притомить.
    Мой практический пример доказал, что время компиляции С++ кода можно увеличивать до бесконечности не меняя количество символов кода при условии неограниченности уровней вложенности теиплейтов.
    Твоего практического примера делающего тоже самое на препроцессоре - нету.
    Более того, для доказательства O(infinity) не требуется писать функции с бесконечной рекурсией. Достаточно показать что при константной длине программы время обработки может расти неограниченно.
    Что я и сделал.

    Цитата Сообщение от pal Посмотреть сообщение
    я это считаю за 8 символов, ты бы еще килограммами мерял
    Цитата Сообщение от pal Посмотреть сообщение
    лол
    т.е. ты определил, что время работы препроцессора линейно зависит от числа потраченных тактов процессора
    кто бы сомневался
    Я определил что время работы препроцессора зависит от количества принятых символов. Из файла. И если он принимает файл три раза - значит символы считаются три раза.
    И поэтому возможность написать #include "__FILE__" при отсутствии ограничений на вложенность инклюдов может ввести препроцессор в бесконечный цикл. Но при этом оставить его линейным.
    Цитата Сообщение от pal Посмотреть сообщение
    мы уже выяснили, что она ни для кого не стоит, а ты все суешь сюда вычислимую функцию
    Мосье явно мало писал на Тьюринг-неполных языках...
    Хотя, опыт - дело наживное.

    Цитата Сообщение от pal Посмотреть сообщение
    ты уже придумал парсер, не строящий таблицу символов, или таблицу символов с константным временем доступа ?
    А в чем проблема с константным временем доступа? В том что такой структуры нет в STL?
    Таблицу символов можно сделать даже O(1) на раз, другой вопрос что при этом расходы на память будут неприемлимы. Таблица ключевых слов например реализуется именно как perfect hash с константным лукапом.
    Но даже O(log m) - это максимум при самой хреновой реализации, где m- количество символов в таблице, что уже дает верхнюю границу - логлинейную.
    А если поставить на входе что-то типа Bloomier filter (http://www.ee.technion.ac.il/~ayellet/Ps/nelson.pdf) - то можно сделать ее сколь угодно близкой к линейной.
    Цитата Сообщение от pal Посмотреть сообщение
    и ты используешь необычное определение контекстно-свободности
    Где я давал определение контекстно-свободной грамматики? И зачем мне это делать, если это определение знают все, не прогуливавшие занятия?
    Или ты так понял термин ambiguous CFG?
    Погугли, много интересного найдешь...

    Цитата Сообщение от pal Посмотреть сообщение
    в общем случае пренебречь как раз нельзя, т.к. никто не запрещает иметь один очень большой блок на всю программу
    Можно большой блок конечно. Но даже в этом - худшем случае, больше логлинейной не получаем. Если разработчики компилятора - разумные люди.
    Реально везде используются приближенные методы. С той же раскидкой по регистрам вроде юзаются "окна" в коде. Правда уже не помню, достаточно давно этим занимался.
    Хотя, повторяю, здесь - как сделать.
    И по любому у С++ сложность будет по крайней мере не меньше, чем С.

    Цитата Сообщение от pal Посмотреть сообщение
    а еще есть whole program optimization
    Ну это я отсек, вот там как раз может быть много шаманства. Но от языка компиляции они зависят мало и для С++ и С будут одинаковы.

    Цитата Сообщение от pal Посмотреть сообщение
    это очередная шутка ?
    на бесконечном множестве она вообще никого не интересует, т.к. там в любом случае конца не будет
    Мосье явно прогуливал ту лекцию, где давали О-нотацию...
    На всякий случай продублирую.
    Big O notation is also called Big Oh notation, Landau notation, Bachmann–Landau notation, and asymptotic notation.
    http://en.wikipedia.org/wiki/Big_O_notation
    Почитай полностью - найдешь много интересного.
    А пока просто запомни - это ассимптотическая оценка, изобретенная не программистами, а математиками. И оценивается как lim x->infinity.
    Цитата Сообщение от pal Посмотреть сообщение
    это ужас только для тебя и тьюринг полноту приплетал только ты
    весь остальной мир как жил с ограничениями, так и живет и в ус не дует
    Мосье наверное ничего не знает о жарких дискуссиях на тему - делать ANSI SQL Тьюринг-полным или нет. А ведь вопрос достаточно интересный - может ли СУБД выполнять запрос который она не может не только выполнить но и соптимизировать..
    Впрочем если весь остальной мир считается равным С++ тусовке а все остальное объявляется песочницей - то ты прав.
    Цитата Сообщение от pal Посмотреть сообщение
    казалось бы, как это относится к топику
    Ты обвинил меня в том, что я ругаю метапрограммы. Я прояснил свою позицию. Я их не ругаю. Я ругаю реализацию, которая взяла все недостатки метапрограммирования без его достоинств, причем сделала этом методом броуновского движения.
    Это надо суметь, сразу так не получится.

    Цитата Сообщение от pal Посмотреть сообщение
    ты себе льстишь, если думаешь, что они старались для тебя
    примерно 200 лет назад было написано:
    Не знаю что за люди здесь
    Но птичьи пугала в полях
    Кривые, все до одного!
    (c) Исса, сын крестьянина
    http://kabir.com.ua/japan/hokky_issa.html
    Наверное те крестьяне тоже могли бы сказать поэту, что пугала не для него ставились.

    Цитата Сообщение от pal Посмотреть сообщение
    а ты почему не сделал ? а остальные почему не сделали ?
    наверное, потому что не успели
    Для реализации базового движка industrial-strength требуется от 5 человекомесяцев (моих). С учетом моей зарплаты - это внушительная сумма, которую я не готов заплатить за счастье всего мира.
    Другие однако делали, см. тот же Nemerle, OpenC++, MetaC, ADF+SDF.
    Другой вопрос что они делали
    а. решения, зависящие от языка (а можно сделать полностью универсальное решение)
    б. решения академические, чисто академический интерес и представляющие
    в. решения крайне неудобные либо ограниченные.

    Можно сделать по другому и full extensible reflexive languages обсуждались еще в 80-х.
    Погугли например IPG (Incremental Parser Generator).

    Цитата Сообщение от pal Посмотреть сообщение
    я уже говорил, что qt - не с++
    Сильно!
    Цитата Сообщение от pal Посмотреть сообщение
    какой спрос с людей, не слышавших об стл ?
    Они не любили синематограф! Тьфу, блин, С++.
    Цитата Сообщение от pal Посмотреть сообщение
    используй gtkmm
    лол!
    QT- написанный на С++ с использованием метаобъектного компилятора это не С++.
    А gtkmm, юзающий С-шный glib - это С++!
    Для тех, кто не в курсе - для gnome была написана либа на С, которая имитировала STL (как его в те времена представляли) со списками и прочей лабудой.
    Называлась glib.
    Либа мерзкая - например обратной совместимости в ней нету и старые проекты могут не компилиться под старые.
    Ну и плюс идеология STL сама по себе неприятна, а на С вызывает стойкое отвращение и желание похмелиться - как 3д шутер на старом инерционном жк-мониторе.
    Но это оказывается теперь С++!
    Что своих списков в С++ не оказалось?
    Цитата Сообщение от pal Посмотреть сообщение
    с++ - не изменяемый, а дополняемый язык
    если переопределять + на -, то это потом никто не поймет, а если очень хочется, то используй любой кодогенератор/препроцессор, только потом не жалуйся
    Странно, как раз + на - в С++ можно переопределить и куча народу перепределяет так например матричные операции. И таки да, ты прав - никто потом не понимает.

    А кодогенераторами я и так пользуюсь, по другому не выйдет.
    Генерация автоматических маршаллеров, объектов доступа баз данных и т.п.
    Даже для такой тупой задачи как написания LUA-wrappers у меня просто сканируется h-файл.

    Только на С++ это сделать на порядки сложнее - синтаксис наворочен плюс перегрузки операторов плюс наследование плюс много фич, которые казались очень полезными всем, а оказались хороши только в относительно узком круге задач.

    Кстати еще такое замечание.
    По моей статистике более 95% джуниоров пыталась писать свой класс TMatrix, иллюстрируя мем о mental masturbation. И 100% этого кода потом идет в корзину.
    У меня сейчас работает человек, который на предыдущей работе написал под миллион строк работы с матрицами на С++. Там было очень много расширений и код был рассчитан на многолетнюю эксплуатацию (ага, при таких меняющихся стандартах!).
    Мне даже говорить ему о таких вещах как BLAS и LAPACK не хотелось - по человечески жалко было.

    Цитата Сообщение от pal Посмотреть сообщение
    я понял, в чем твоя проблема
    ты хочешь пони
    Пока я вижу не пони. Пока я вижу того самого camel который is a horse designed by commetee.
    Такого пони - не хочу.

    Цитата Сообщение от pal Посмотреть сообщение
    Большая красивая картинка
    О, двач в каментах!
    Моар в мой /s/!

    Ждем педобира?
    The future is already here - it is just unevenly distributed. (c) W. Gibson

  8. Вверх #108
    Посетитель
    Пол
    Мужской
    Возраст
    35
    Сообщений
    202
    Репутация
    7
    Ждем педобира?
    в данном случае нужен грамотный лиспоёб.
    Чтобы грамотно обьяснили где лучшее в мире ООП и метапрограммирвоание.

  9. Вверх #109
    Посетитель
    Пол
    Мужской
    Возраст
    35
    Сообщений
    202
    Репутация
    7
    я то думаю почему вы о всякое ерунде.
    оказывается уже наговорились о всём насущном тут
    https://forumodua.com/showthread.php?t=33649


Ответить в теме
Страница 6 из 6 ПерваяПервая ... 4 5 6

Похожие темы

  1. З "Win" на "Nix" + GUI
    от YOKO в разделе Программное обеспечение
    Ответов: 10
    Последнее сообщение: 18.10.2007, 14:50
  2. 3d графика и *NIX системы
    от Alisan в разделе Программное обеспечение
    Ответов: 23
    Последнее сообщение: 26.02.2007, 13:27
  3. Ищу *nix livecd с GCC компилятором
    от cTcangel в разделе Программное обеспечение
    Ответов: 54
    Последнее сообщение: 19.12.2006, 00:35
  4. FTP-client API for *nix
    от krieger в разделе Программирование
    Ответов: 4
    Последнее сообщение: 23.05.2005, 03:26

Социальные закладки

Социальные закладки

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения