LINUX.ORG.RU

Производительность C++

 ,


7

13

Как насчёт производительности у C++ по сравнению с C? Мои предположения на текущий момент:

1) Код, не использующий возможности C++ (то есть по сути plain C), скомпилированный C++ компилятором будет иметь абсолютно ту же производительность, что и код на С.

2) Исключения и dynamic_cast медленные. Если нам важна производительность, лучше их не использовать.

3) Класс без виртуальных методов, должен быть по производительности эквивалентен сишной структуре и функциям, обрабатывающим её. Не считая копирования. Нужно везде, где можно использовать передачу по указателю или ссылке (собственно, если в Си делать memmove при передаче структуры в качестве аргумента, то это вызовет примерно такой же оверхед, как дефолтный конструктор копирования С++. Верно?).

4) Класс с виртуальными методами полностью аналогичен пункту 3, но при вызове виртуальных методов добавляется небольшой оверхед. Сишный эквивалент obj->vtable->func(obj, ...). Если сравнивать с plain C кодом, реализующим ООП в той же манере (каждая структура-объект имеет поле, указывающее на структуру, содержащую адреса функций работы с ней), то оверхеда по сравнению с plain C не должно быть.

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

6) Шаблоны могут привести к разбуханию кода. Впрочем, #define-ы и inline-функции в C++ могут устроить то же самое. Вопрос: будет ли использование шаблона с одинаковыми параметрами создавать 2 копии реализации или же всё-таки компилятор догадается сделать её лишь один раз. А если шаблон используется с одинаковыми параметрами в нескольких объектных файлах? Будет ли реализация расшариваться между ними или у каждого своя?

7) Что насчёт inline-методов класса? (те, которые описываются прямо в момент определения самого класса, внутри блока class). Может ли их реализация расшариваться между модулями или в каждом будет своя копия (допустим, метод слишком длинный, чтобы инлайнится в момент вызова)?

Я не претендую на правоту, какие-то утверждения могут быть ложными. Хотел бы узнать, как обстоят дела на самом деле. А также какие подводные камни я ещё не знаю. Разумеется, речь идёт о последних версиях gcc/clang с включённой оптимизацией не ниже -O2.

★★★★★

Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от anonymous

Отлично, понятие клоунады ты усвоил. Теперь учим, что такое сарказм:

Лучше ссылочку на стартап, вся команда которого читает флеймы на ЛОРе :-)

anonymous
()
Ответ на: комментарий от anonymous

Но на это понимание было затрачено масса времени. Непомерное количество.

Так вы же тут наглядно показали, что вы дебил. Не нужно думать, что окружающие еще тупее вас.

При должном процессе обучения люди начинают нормально использовать современный C++ очень быстро. Всякие тонкости, конечно, требуют больше времени. А уж до уровня написать свою реализацию stl-ого контейнера вообще добираются не многие. Но это вообще не столько из-за сложности C++, сколько из-за сложности и противоречивости требований.

Указатель на какой-нибудь struct String в куче.

Вот и еще один источник багов. Старательно подготовленные грабли, на которые кто-нибудь наступит.

Никакой копипасты не будет. Будет либо 3 функции, одна общая, две для конкретных случаев, либо макрос.

Покажите.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Теперь учим, что такое сарказм

Лучше ссылочку на стартап, вся команда которого читает флеймы на ЛОРе :-)

А ты быстро учишься. Тебя бы в ПТУ или институт.

anonymous
()
Ответ на: комментарий от eao197

Так вы же тут наглядно показали, что вы дебил. Не нужно думать, что окружающие еще тупее вас.

А вот в этом то всё и дело :-) Откуда столько комплексов? :-)

При должном процессе обучения люди начинают нормально использовать современный C++ очень быстро. Всякие тонкости, конечно, требуют больше времени. А уж до уровня написать свою реализацию stl-ого контейнера вообще добираются не многие. Но это вообще не столько из-за сложности C++, сколько из-за сложности и противоречивости требований.

Ну вот, и я об этом же :-) Очень немногие специалисты по Си++ обладают высокой квалификацией :-) Им лишь бы doc[«blabla»] можно было писать, остальное не важно :-)

Вот и еще один источник багов. Старательно подготовленные грабли, на которые кто-нибудь наступит.

Кто-нибудь из неквалифицированной шпаны? :-) Такие нам не нужны :-)

Покажите.

До свидания :-)

anonymous
()
Ответ на: комментарий от anonymous

С таким примитивным юмором в клоуны не возьмут :-)

Без вопросов, в данном вопросе полностью полагаюсь на твой авторитет.

anonymous
()
Ответ на: комментарий от anonymous

А вот в этом то всё и дело :-) Откуда столько комплексов? :-)

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

Даже от большого царя в этом треде больше полезной и интересной инфы, чем от вас.

Очень немногие специалисты по Си++ обладают высокой квалификацией :-)

Вы настолько тупы, что не понимаете простой вещи: дабы безопасно использовать C++ не нужно иметь столь же высокую квалификацию, как для написания библиотек уровня STL или Boost-а.

До свидания :-)

Да куда ж вы денетесь? Как миленький прибежите в очередную тему с дебильными агитками отказаться от C++ в пользу C. Скорее всего прям в эту же тему и вернетесь.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Но на это понимание было затрачено масса времени. Непомерное количество.

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

... либо макрос.

Привет, шаблончики :) Всегда хватало макросов? А если не хватает?

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

С++ — намного сложнее других языков в освоении. Потому что это инструмент экспертного уровня. У него высокий входной порог.

Объясни пожалуйста тогда, почему академики любят Паскаль?

anonymous
()
Ответ на: комментарий от anonymous

Объясни пожалуйста тогда, почему академики любят Паскаль?

Я, честно говоря, не знаю, что тут объяснять. Если я правильно знаю расклад, академики любят Haskell, а не Паскаль.

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

Ну хорошо, а вот тут ты наверно хотел сказать ...

С++ — намного запутанее других языков.

Под сложностью ты имеешь в виду обилие нелепых нагромождений, и противоречивость?

anonymous
()
Ответ на: комментарий от anonymous

О! Так ты опять здесь изливаешь мамкину лапшу, следовтельно ты все же малолетний нокрепший отрок! Божественное объебос)

anonymous
()
Ответ на: комментарий от anonymous

Если я правильно знаю расклад, академики любят Haskell, а не Паскаль.

Это если академики от Computer Science. А если от математики, то Фортран, в лучшем случае.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Под сложностью ты имеешь в виду обилие нелепых нагромождений, и противоречивость?

Нет. Всю модель языка. Противоречивость и несогласованность — лишь неизбежное в реальном мире свойство сложных систем. Ты, наверное, думаешь, что можно создать идеальный язык уровня С++?

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

Ты, наверное, думаешь, что можно создать идеальный язык уровня С++?

Для смайлика, как следует из общения с ним в других темах, таким языком является Common Lisp. Только вот на Common Lisp зарабатывать себе на жизнь он не может.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Только вот на Common Lisp зарабатывать себе на жизнь он не может.

Потому-то язык и кажется идеальным, что человек на нем не пишет за деньги и с дедлайнами, а только для своего удовольствия. Классика жанра :)

anonymous
()
Ответ на: комментарий от anonymous

Ты, наверное, думаешь, что можно создать идеальный язык уровня С++?

Незнаю, думаю ненужно этого делать.

Но если бы Страуструпу сказали: "... на твоё усмотрение, выкинь всё лишнее из C++". Чтобы было тогда?

anonymous
()
Ответ на: комментарий от anonymous

Чтобы было тогда?

Ну, я не знаю, что там реально лишнее. Там всё в системе работает. Все трудности идут от передачи объектов по значению. Появляются области видимости, деструкторы, RAII. Далее — мономорфные шаблоны, охватывающие value. В совокупности это дает много дополнительных степеней свободы, не все значения их пространства которых являются допустимыми. Это и составляет сложность языка.

Выкинем передачу объектов по значению, и можно выкинуть деструкторы, RAII, можно сделать шаблоны полиморфными. До кучи немного снизить их выразительность, ибо нефиг компилятор выводом загружать. С исключениями станет всё намного проще. Правда, придется прикрутить сборщик мусора, но сейчас все так живут. В итоге получим Java, только с прямым доступом к памяти. Зачем? Если Java уже есть.

anonymous
()
Ответ на: комментарий от anonymous

Объясни пожалуйста тогда, почему академики любят Паскаль?

Смотря где.

Во франции любят окамль, в латинской америке пролог, в мите лисп, но идиотам приходится на пистоне преподавать.

anonymous
()
Ответ на: комментарий от anonymous

Ну, я не знаю, что там реально лишнее.

Препроцессор, как минимум. Как максимум - сырые указатели в том виде, как они были взяты из С.

anonymous
()
Ответ на: комментарий от anonymous

Как максимум - сырые указатели в том виде, как они были взяты из С.

Ну я не думаю, что это что-то кардинально изменит. Прикладные программисты сейчас с сырыми указателями и так не работают. А те, кто пишет библиотеки, как раз и не хотели бы, чтобы указатели куда-то убирали.

Вообще, с моей точки зрения, С++ сейчас не самодостаточен. Прикладное программирование на нем относительно трудоемкое (особенно - в большом), ввиду отсутствия модульности и пакетных менеджеров. На С++ выносится поднимание тяжестей (GUI, обработка данных), тогда как динамично меняющаяся логика пишется на Java/Python/JavaScript/etc. В результате можно и быстро двигаться вперед на высококонкурентных рынках, и пользоваться высокой производительностью.

По моему опыту, Java очень так неплохо сопрягается с C++, в обе стороны.

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

Прикладное программирование на нем относительно трудоемкое (особенно - в большом), ввиду отсутствия модульности и пакетных менеджеров.

Проблема не столько в модульности и пакетных менеджерах. Больше мешают другие вещи:

- разные подходы, используемые в разных библиотеках. Кто-то использует исключения, кто-то нет. У кого-то один подход к владению ресурсами, у кого-то другой. Причем все это не просто так появилось, а как следствие широкого использования языка в разных нишах;

- зоопарк компиляторов и систем сборки. Плюс зачастую разработчики просто не думают о кроссплатформенности того, что они делают: работает на одной системе с одним компилятором, да и ладно.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Больше мешают другие вещи:

Совершенно верно. Но даже если мы добьемся приведения подмножества языка для всего используемого кода к общему знаменателю, проблема модульности всё равно останется. Гугл всю свою кодовую базу С++ рекомпилирует целиком при изменениях. Все модули сразу. В Java легко можно получить сотню-две мегабайт подключенных библиотек. С JIT-ом всё просто, а вот AOT-система для пересборки такого проекта потребует билд-фермы.

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

проблема модульности всё равно останется. Гугл всю свою кодовую базу С++ рекомпилирует целиком при изменениях. Все модули сразу.

Да есть причины на то, чтобы и с модулями продолжать жить с перекомпиляцией. Например, изменение режима выравнивания данных по-умолчанию. Или какие-нибудь хитрые ключики компилятора, по управлению представлением виртуальных таблиц и т.д.

Другое дело, что модули могут сильно время пересборки сократить. Но, насколько я понимаю, проблему макросов пока решить не смогли. А это значит, что просто огромный кусок имеющегося кода (даже на C++14 стандарте) не сможет быть преобразован в модули.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

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

Я лично для себя проблему модульности решил через Java и NAR Maven Plugin. NAR упаковывает как исходный код C++, так и скомпилированные библиотеки в jar-подобные архивы (.nar), которые подключаются Maven-ом так же, как и обычные ресурсы. Очень даже юзабельно, если ты уже знаком с Maven и С++ используешь совместно с Java.

//Психиатр

anonymous
()
Ответ на: комментарий от eao197

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

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

Да, С++ — намного сложнее других языков в освоении. Потому что это инструмент экспертного уровня.

Академический уровень — Haskell — статейки, грантики.

Инженерный уровень — Common Lisp — не видно, не слышно, все спокойно работает.

Уровень ПТУ — C++ — гуру, евангелисты, философы, скандалы, истерики.

anonymous
()
Ответ на: комментарий от anonymous

Common Lisp — не видно, не слышно, все спокойно работает.

Ага, все спокойно работают, используя С, Java, C# и С++. Раньше устраивали бурные лиспосрачи (при том работая с С и С++), а теперь уже смирились и просто иногда вяло пытаются напомнить о существовании такого языка.

anonymous
()
Ответ на: комментарий от anonymous

Раньше устраивали бурные лиспосрачи (при том работая с С и С++), а теперь уже смирились и просто иногда вяло пытаются напомнить о существовании такого языка.

Это ты про местных? Так это же Россия, тут культуры такой нет.

anonymous
()
Ответ на: комментарий от anonymous

Поржали всем отделом в BMW

А кто сказал, что птушники не нужны?

anonymous
()
Ответ на: комментарий от eao197

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

Ну сказал гадость, что в итоге ты приобрёл? :-)

Даже от большого царя в этом треде больше полезной и интересной инфы, чем от вас.

Чего? :-)

Вы настолько тупы, что не понимаете простой вещи: дабы безопасно использовать C++ не нужно иметь столь же высокую квалификацию, как для написания библиотек уровня STL или Boost-а.

Так за это и речь, что для того, чтобы писать на Си++ квалификации большой не требуется :-) Я это и говорил, но до тебя трудно доходит походу :-) Сам спросил про квалификацию неких Си++ программистов, которые делают известные продукты, и тут же сам признался, что «дабы безопасно использовать C++ не нужно иметь столь же высокую квалификацию» :-) Ну что же ты такой непоследовательный? :-)

Да куда ж вы денетесь? Как миленький прибежите в очередную тему с дебильными агитками отказаться от C++ в пользу C. Скорее всего прям в эту же тему и вернетесь.

Так я же сказал «до свидания» :-) Не проводить же тут целый день с тобой :-)

anonymous
()
Ответ на: комментарий от eao197

Напомню что было при прошлых попытках гнать на сишку и заявлять «нельзя в стримы»:

#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>

typedef struct {
  uint32_t x, y;
} struct_t;

inline char * struct_to_string(char * str, struct_t s) {
  return str + sprintf(str, "{x: %u, y: %u}", s.x, s.y);
}

inline char * int_to_string(char * str, int i) {
  return str + sprintf(str, "%i", i);
}

inline char * string_to_string(char * str, char * s) {
  uint64_t len = strlen(s);
  return memcpy(str, s, len) + len;
}

#define to(type, x) ({__auto_type ret = x; *(type *)((void *) &ret);})

#define to_string(str, x) _Generic((x),\
  int : int_to_string(str, to(int, x)),\
  char * : string_to_string(str, to(char *, x)),\
  struct_t : struct_to_string(str, to(struct_t, x))\
)

#define FIRST(a, ...) a
#define SECOND(a, b, ...) b

#define EMPTY()

#define EVAL(...) EVAL32(__VA_ARGS__)
#define EVAL32(...) EVAL16(EVAL16(__VA_ARGS__))
#define EVAL16(...) EVAL8(EVAL8(__VA_ARGS__))
#define EVAL8(...) EVAL4(EVAL4(__VA_ARGS__))
#define EVAL4(...) EVAL2(EVAL2(__VA_ARGS__))
#define EVAL2(...) EVAL1(EVAL1(__VA_ARGS__))
#define EVAL1(...) __VA_ARGS__

#define DEFER1(m) m EMPTY()
#define DEFER2(m) m EMPTY EMPTY()()
#define DEFER3(m) m EMPTY EMPTY EMPTY()()()
#define DEFER4(m) m EMPTY EMPTY EMPTY EMPTY()()()()

#define IS_PROBE(...) SECOND(__VA_ARGS__, 0)
#define PROBE() ~, 1

#define CAT(a,b) a ## b

#define NOT(x) IS_PROBE(CAT(_NOT_, x))
#define _NOT_0 PROBE()

#define BOOL(x) NOT(NOT(x))

#define IF_ELSE(condition) _IF_ELSE(BOOL(condition))
#define _IF_ELSE(condition) CAT(_IF_, condition)

#define _IF_1(...) __VA_ARGS__ _IF_1_ELSE
#define _IF_0(...)             _IF_0_ELSE

#define _IF_1_ELSE(...)
#define _IF_0_ELSE(...) __VA_ARGS__

#define HAS_ARGS(...) BOOL(FIRST(_END_OF_ARGUMENTS_ __VA_ARGS__)())
#define _END_OF_ARGUMENTS_() 0

#define MAP(m, first, ...)           \
  m(first)                           \
  IF_ELSE(HAS_ARGS(__VA_ARGS__))(    \
    DEFER2(_MAP)()(m, __VA_ARGS__)   \
  )(                                 \
    /* Do nothing, just terminate */ \
  )
#define _MAP() MAP

#define op(x) str = to_string(str, x);

#define fprintf_proturbo(file, ...) ({\
  char * str = malloc(1000500), * s = str;\
  EVAL(MAP(op, __VA_ARGS__));\
  *str = 0;\
  int i = fprintf(file, "%s", s);\
  free(s);\
  i;\
})


int main(void) {
  struct_t st = {10, 23};
  fprintf_proturbo(stderr, 234235, " ", 523523, "\n", st, " ", 423523, "\n");
}

Впредь - будь человеком и когда пытаешься что-то сравнивать с си - ты завёшь меня и спрашиваешь «как это будет на си». Сравнивать что-то может только тот, кто умеет, а кто не умеет - сравнивать не может.

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

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

Надо нам, крестовикам, дружить - кто защитит нас в битве с лиспонечестью? Они так и победят нас, пока мы будем сраться друг с другом. А вообще надо понять - критика бывает обоснованная, критика не определяет что-то дерьмом - критика нужна для понимания слабых сторон, чтобы далее устранить их. Чего ты добьёшься, если и дальше будешь фанатично отрицать реальность. ^_^

AnonCxx
()
Ответ на: комментарий от AnonCxx

Типичный царский код - бессмысленная акробатика, ни на что реальное не годная (и к тому же явно краденая). Ради использования «стрима» предлагается каждый раз определять макрос to_string. Верх удобства.

Надо нам, крестовикам, дружить

Ты не крестовик. А дружить с тобой - зашквар.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

явно краденая

А вот такие гнилые предъявы надо бы пруфцами подкреплять. Хотя, чего это я? Где ты, а где пруфцы...

anonymous
()
Ответ на: комментарий от anonymous

зашквар

Я слышал, сейчас это очень модное слово.

Сам не люблю блатной жаргон, но не смог подобрать близкое по значению слово из литературного русского :/

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от anonymous

Риторические приемы у него тоже не оригинальные. Этим еще древние греки с римлянами баловались, да и сейчас мало какая философская полемика без них обходится.

//Психиатр

anonymous
()
Ответ на: комментарий от tailgunner

и к тому же явно краденая

Действительно краденная.

Ради использования «стрима» предлагается каждый раз определять макрос to_string. Верх удобства.

Подожди, а где ты был когда мне предлагалось это: https://godbolt.org/g/nDbkL0. Я что-то тебя не видел, а тут вдруг вылез.

Определять его каждый раз не надо - надо доопределять для добавления новых типов. Для си это не является проблемой, ибо нет проблемы с нагромождением типов.

Да и в любом случае что там что тем требуется определить «оператор», а доопределить в to_string не особо чего-то стоит.

Ты не крестовик.

Без разницы кто я - главное кто тебя в сравнении с тобою. Остальное не важно, вернее это важно только для слабых, когда ничего нет, но как-то выделиться хочется. У тебя есть «всё» - звёзды, попытки меня тереть, уверенность в себе(наигнанная) и прочее, но это не важно. Твоё утверждение ничего не стоит, ибо даже как крестовик я больше тебя.

Давай проще. Негоже чумазому ставить в упрёк кому-то, что он чумазый. Особенно в тех случаях, когда он чумазый менее.

А дружить с тобой - зашквар.

Естественно - для тебя. Пока что у тебя, да и любого другого есть единственное оправдание «царь идиот». Есть факт - ты слабее, но как это оправдать? Ты давно для себя определился, что лезть ты не будешь, но при этом будешь делать вид, что царь ничего из себя не представляет, но не идёшь с ним ты на конфронтацию не потому, что он сильнее, а потому - что ты его за оппонента не считаешь.

Т.е. «царь - собачка, а я не бью братьев наших меньших» - это работает для твоих безмоглых фанов, но не особо.

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

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

AnonCxx
()
Ответ на: комментарий от anonymous

Эти разоблачители комнатные. Стоит ли в нынче щас учить язык Си? (комментарий)

Даже не поленился - гуглим/пишем разворачивалку __VA_ARGS__ + кладём чутка дерьма + 3минуты времени и вуаля - готово.
гуглим

AnonCxx
()
Ответ на: комментарий от AnonCxx

гуглим/пишем разворачивалку __VA_ARGS__ + кладём чутка дерьма + 3минуты времени и вуаля - готово.

кладём чутка дерьма

Царский рецепт!

anonymous
()
Ответ на: комментарий от anonymous

Разоблачи эту пасту.

#define eval(args...) eval32(eval32(args))
#define eval32(args...) eval16(eval16(args))
#define eval16(args...) eval8(eval8(args))
#define eval8(args...) eval4(eval4(args))
#define eval4(args...) eval2(eval2(args))
#define eval2(args...) eval1(eval1(args))
#define eval1(args...) args

#define zero() 0
#define nas_zero_0() 1, 0
#define second(a, b, args...) b
#define concat(a, b) a ## b
#define invoke(f, args...) f(args)
#define has_args_helper(first, args...) invoke(second, concat(nas_zero_, first)(), 1)
#define has_args(args...) has_args_helper(zero args ())

#define __if1(f, b) f
#define __if0(a, f) f
#define __if(cond, a, b) invoke(concat(__if, cond), a, b)

#define empty(args...)
#define for(op, first, args...) op(first) _for empty() (args)(op, args)
#define _for(args...) __if(has_args(args), for, empty)
#define for_each(op, args...) eval(for(op, args))
AnonCxx
()
Ответ на: комментарий от anonymous

Ну подожди, это рецепт крестов - я сделал по рецепту крестов пасту на сишке - в чём проблема?

При этом сделал даже быстрее и лучше - моя хоть 100500 строк в хипе не генерит.

AnonCxx
()
Ответ на: комментарий от tailgunner

Ну когда нечего ответить - предпринимай убогий потуги хоть в чём-то обвинить царя. Ну выклал ты это - что из этого следует? Попытайся опять. Балабол я в чём и почему.

AnonCxx
()
Ответ на: комментарий от anonymous

Это относительно дорогой язык для программирования в большом

Да, пожалуй тут возражать сложно. Поэтому не буду.

eao197 ★★★★★
()
Ответ на: комментарий от AnonCxx

Балабол я в чём и почему.

superhackkiller1997> Я уже работаю над убийцей сишки, подожи полгодика и мы сравним мою реализацию и гццешную.

tailgunner> Опубликуй ссылку на нее здесь.

superhackkiller1997> Да, так и будет

Разговор был в 2013 году. Ссылку ты не опубликовал. Поэтому ты балабол.

Кстати, а как насчет блога - написал уже?

tailgunner ★★★★★
()
Ответ на: комментарий от AnonCxx

char * str = malloc(1000500)
Надо нам, крестовикам, дружить - кто защитит нас в битве с лиспонечестью? Они так и победят нас, пока мы будем сраться друг с другом.

Етить-колотить, да ты совсем больной.

eao197 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.