[соцопрос] Pure C

> Со второй компилятор не берет на себя слишком много

Это не вполне правда. Например, gcc при некоторых ключах сборки берет на себя смелость переставлять вложенные циклы местами, вводить дополнительные вложенные циклы, раскручивать и конвееризировать циклы, и тд. При этих трансформациях он абсолютно нигде не нарушает стандарт Си.

код очевидным образом соответствует инструкциям выбранного процессора

А это - откровенное 4.2. Соотвествие выхлопа «gcc -O2» и ассемблерного кода - крайне слабое. Чего стоят одни только связанные со strict aliasing оптимизации.

> код легко портируем, язык не использует особенности конкретного оборудования

Это тоже не вполне правда. Например, размер int зависит от конкретного оборудования. Если программист на него где-то в своем коде полагался - портировать такой код - хуже некуда.

Более того, из-за Си-шной штуки под названием integer promotion, поведение кода с переменными типа uint8_t, uint16_t в действительности зависит от sizeof(unsigned). И можно считать очень приятным везением, если в конкретной программе эта зависимость нигде не проявляется.

> Там нет ограничений на построения абстракций

В с++, если очень хочется, можно вытворять всё то же, что на plain c.

в виде готового механизма наследования.

В 99.999999% случаев его достаточно.

Нет возни с автоматически вызываемыми конструкторами и деструкторами.

Это не возня, это огромное удобство. Если тебе по какой-то причине эти вызовы вредны, ничто не мешает вместо предопределенных имен завести методы Construct() и Destruct(): их компилятор без твоего явного указания вызывать не будет.

В с++, если очень хочется, можно вытворять всё то же, что на plain c.

В общем случае нет.

>> Именно она не открывается.

у меня открывается

на этот раз у меня тоже O_o

Вопрос был в том, есть ли что то лучшее в обозначенном смысле. К чему придраться всегда можно найти.

>> Ну и почему это нельзя было по-человечески сделать, как в Go или D?

Машину времени на тот момент не изобрели (D появился где-то в 1999, а Go еще лет через 10).

зато паскалю был уже не первый десяток

Про int тоже не вполне правда, это проблемы программиста, полагаться надо на intXX_t. Про byte order бы лучше вспомнил.

> http://www.meta-alternative.net/pfront.pdf

Полулегендарный MBase в деле? :) Насколько я понимаю, в статье описана библиотека для разработки DSL. Вероятно, она крута, но библиотек для разработки DSL - килограммы. «Technically, PFront is just a syntax front–end for MBase. PFront is part of forthcoming 1.0 release of MBase framework» - то есть под капотом этой игрушки целый фреймворк. Ну и причем тут «Лисп может иметь любой синтаксис»? То, что в Лиспе есть возможность переопределить парсер, общеизвестно. Правда, я лично не знаю, что именно выдает этот прасер - Лисп-код или AST.

> то есть под капотом этой игрушки целый фреймворк.

Да хрен там. Это же всего лишь PEG-парсер. Такой на любом языке пишется за час. А прикрутить его можно к любому языку с макросами в стиле коммон лиспа. PEG позволяет объединять любые разные синтаксисы, так что им можно подменить стандартный парсер лиспа или схемы, и расширять сколько угодно. Для Схемы я нечто подобное делал, когда надо было SQL ембеддить.

Под «фреймворком» там понимается сомнительной ценности набор макр для неявного рекурсивного обхода дерева, в стиле Scrap Your Boilerplate.

Правда, я лично не знаю, что именно выдает этот прасер - Лисп-код или AST.

Так в Лиспе же нет разницы. Код это AST, а AST это код.

Там исходники всего pfront есть, все очень кондово сделано. С приличным Лиспом можно еще проще.

>> Да какое в плюсах к херам метапрограммирование? Даже если и есть какое-то, то оно неюзабельное, им только шизофреники всякие пользуются, и для удовлетворения своих шизофренических фантазий, а не для практики.

Бгг, расскажи это пользователям boost.

Бгг.. расскажи это таки пользователям буст.

По моему буст - это эдакий пруф оф консепт, что ДА, МЫ МОЖЕМ!!1111111

> По моему буст - это эдакий пруф оф консепт, что ДА, МЫ МОЖЕМ!!1111111

Ну вот я - пользователь Spirit и FC++. Не понтов ради, а для дела.

>> или препроцессор

Дает возможность использовать одни и те же заголовки/библиотеки как в C, так и в C++.

Сюрприз, но всякие #include именно препроцессор обрабатывает.

И очень зря. Правильная система модулей - большое благо.

> Правда, я лично не знаю, что именно выдает этот прасер - Лисп-код или AST.

учитывая синтакси Лиспа, это почти одно и то же =)

> И очень зря. Правильная система модулей - большое благо.

+1

>> Правда, я лично не знаю, что именно выдает этот прасер - Лисп-код или AST.

учитывая синтакси Лиспа, это почти одно и то же =)

Блин, да тут выступление хора %) Мне результат работы парсера интересен с чисто технической точки зрения - можно ли подсунуть, например, вывод скрипта на shell.

> Мне результат работы парсера интересен с чисто технической точки зрения - можно ли подсунуть, например, вывод скрипта на shell.

А почему нет? Определяем лисповую макру (execute-in-shell блаблабла), а компилятор сам и подсунет что надо куда надо, когда будет ее разворачивать. Я так connection string-и формирую, например.

> Блин, да тут выступление хора %) Мне результат работы парсера интересен с чисто технической точки зрения - можно ли подсунуть, например, вывод скрипта на shell.

кому подсунуть? результату работы парсера?

>> Мне результат работы парсера интересен с чисто технической точки зрения - можно ли подсунуть, например, вывод скрипта на shell.

А почему нет?

Я имею в виду - напрямую, в виде строки текста.

Можно принять за аксиому что всё можно и больше не задаваться вопросом «можно?». Это к слову.

Я имею в виду - напрямую, в виде строки текста.

Как сделаете так и будет - парсер от строки передаёт работу парсеру потока, диспетчер на macro-character его же вызывает.

Мне всегда казалось, что С++ дальнейшее развитие обычного С. А значит лучше использовать С++

Ты пробывал на cpp писать или просто теоретизируешь?

> зато паскалю был уже не первый десяток

Ну и сильно ли unit interface в pascal отличается от .h-файла?

Кстати, очень часто можно (и нужно) использовать forward declaration вместо подключения заголовочного файла.

> Кстати, очень часто можно (и нужно) использовать forward declaration вместо подключения заголовочного файла.

Афигеть. Это в каких случаях?

> Я имею в виду - напрямую, в виде строки текста.

Да кто ж мешает засунуть любое количество каких угодно преобразований после парсера? Хоть перлу скормить, а результат опять распарсить.

В pascal нет никаких unit-ов. Они были в борланде. И по сути - те же precompiled headers.

> Афигеть. Это в каких случаях?

Очевидно в тех, когда нужен только интерфейс класса, а не его реализация.

И да, не могу не вспомнить классика: «use headers if you must, use forward declarations if you can»

>>> Кстати, очень часто можно (и нужно) использовать forward declaration вместо подключения заголовочного файла.

Афигеть. Это в каких случаях?

Очевидно в тех, когда нужен только интерфейс класса,

Я првильно понимаю: интерфейс класса должен объявляться при помощи forward-деклараций в тех файлах, в которых он используется (под «использованием» я понимаю и реализация тоже)?

> под «использованием» я понимаю и реализация тоже

неправильно, полиморфизм например

Не осилил плюсы. THIS SHIT TOO COMPLICATED.

// class1.h

class Class1 {
// тут дальше идут определения методов
}

// class1.сpp

#include "class1.h"

// реализация Class1

// class2.h

class Class1;

class Class2 {
// ...

    Class1* something;
}

Так как class2.h не нужно само определение класса Class1 (ему просто достаточно знать, что существует класс Class1), то разумнее использовать forward declaration вместо подключения соответствующего заголовка. Тем самым можно избежать лишних зависимостей и ускорить время сборки.

PS: да, про интерфейс и реализацию я неправильно выразился — голова была другим занята :-(

> полагаться надо на intXX_t

Причем из-за integer promotion на этом пути есть подводные камни. Из-за обилия подобных нюансов, Си неоправданно сложен.

Если использовать что-нибудь подобное glib - таких проблем же не будет?

> Ну и сильно ли unit interface в pascal отличается от .h-файла?

да, достаточно сильно (впрочем, в том древнем паскале не было многих современных удобств, позаимствованных из модулы, которая впрочем тоже уже существовала)

Текущий стандарт языка — ISO/IEC 14882:1998, там std есть.

Прекрасно. Если в C++ string.h нет — сломали совместимость. Причем не сразу, а постепенно.

В любом случае в C++ C-style строковые константы не нужны. Они лишь вводят в заблуждение и делают язык неуклюжим.

Ну как бы у Страуструпа были другие цели: максимальная совместимость с C для более простой миграции на C++.

а) 100% совместимости так и не появилось. Более того, C развивается (и намного более разумно, чем плюсы, кстати); так что достижение совместимости становится почти неразрешимой задачей.

б) Её ломали постепенно; вызвав массу неудобств у программистов. И теперь программисту приходится узнавать про кучу всяких разнообразных костылей.

Машину времени на тот момент не изобрели (D появился где-то в 1999, а Go еще лет через 10).

А в паскале уже (при всех его недостатках) нормальный способ импорта библиотек.

В C #include оправдан, потому что язык макросов — это очень важная часть C. В плюсах #include — рудимент, от которого нужно было избавиться. Всё равно же теперь заменять #include <string.h> на #include <cstring>. Так нужно было сразу сделать оператор import или что-нибудь в этом роде.

[quote]Прекрасно. Если в C++ string.h нет — сломали совместимость. Причем не сразу, а постепенно.[/quote]

Грубо говоря,

[code] //<cstring> namespace std {

#include <string.h>

}; [/code]

Сам по себе string.h никуда не делся, но [b]настоятельно рекомендуется[/b] использовать новые заголовочные файлы (<csomething>) вместо старых (<something.h>).

Если Вы включаете старый заголовок, то namespace std в нем не будет — все декларации будут в глобальном пространстве имен, что, собственно, strongly discouraged.

Фактически компилятор C++ может спокойно скомпилировать практически любую программу, соответствующую стандарту ANSI/ISO C 90 — в этом и проявляется совместимость.

А если брать более поздний стандарт языка C (C99), то ISO C++98 с ним совместим далеко не полностью (хотя плюсовые компиляторы могут поддерживать плюшки C в качестве расширений языка).

Мне всегда казалось, что С++ дальнейшее развитие обычного С. А значит лучше использовать С++,

Ты пробывал на cpp писать или просто теоретизируешь?

Я этим на жизнь зарабатываю. Можешь поверить, опыт написания программ на С++ у меня есть.

А на C писал?

и в Си++ можно скомпилировать for(;P(«\\n»),R-;P(«|»))for(e=C;e-;P(«_»+(*u++/8)%2))P(«| »+(*u/4)%2); но обычьно к такому неприбегают а в Си порой приходиться прибегать и нектакому :)

открой для себя perl :)

>А на C писал?

Мало. В основном модули для ядра.

>А на C писал?

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

а) 100% совместимости так и не появилось. Более того, C развивается (и намного более разумно, чем плюсы, кстати); так что достижение совместимости становится почти неразрешимой задачей.

c99 уже много где используется?

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

На си писать проще, он менее строг.

и последний вопрос, а на python/ruby/etc писал ООП?

>и последний вопрос, а на python/ruby/etc писал ООП?

Нет. Как то руки не дошли до изучения этих языков. А что? После изучения Питона или Руби на меня должно снизойти великое озарение? Я пойму что жил неправедно?

да, после этого откроется истинная сущность cpp.Например, на питоне получается гораздо более локанично и элегантно.

В общем, моё мнение совпадает с
http://www.opennet.ru/opennews/art.shtml?num=27413

>На си писать проще, он менее строг.

Ну это спорный вопрос. Освоить С легче чем С++, это факт. А вот написать большой и сложный проект, не уверен. Нормальная поддержка ООП языком может здорово облегчить труд программиста.

>Например, на питоне получается гораздо более локанично и элегантно.

А мне тотальная утиная типизация не нравится. Через задницу (с точки зрения производительности) сделанная архитектура языка тоже. Не нравится влияние отступов. Наслушался я хвалебных отзывов о Питоне и как-то начал читать книжку по нему. Много не прочитал, дошел до того места, где говорится о том как реализованы циклы. После этого выкинул книжку нафиг.

Создатель языка явно желал хорошего brainfuck для тех, кто будет писать оптимизирующие компиляторы/интерпретаторы для Питона.

а C99 и не надо. достаточно:

int delete = 1;