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)
Ответ на: комментарий от Enthusiast

Он сказал дальше, что они иногда избегаю функций C98, и что они будут использовать функции будущих стандартов C++ если они приносят пользу, а не просто так. Они использую C++ потому что в любой момент, когда надо они смогут использовать его функции, а не потому что он там людей больше. И у них проблема не day-to-day разработки, а низкоуровневая работа с embedded системой, потому что они делают игровой движок, но и это не говорит о том что там нельзя использовать C++. Достаточно посмотреть на CryEngine или что то подобное, они так же используют вкрапления C для низкоуровневых вещей, чтобы добавить производительности. Важно понимать, что есть такая вещь как оптимизация под архитектуру.

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

О боже больничка. Ты хоть такую явную херню не неси.

Кеш обновлятся за сотни тактов

Это про кеш.

квант времени, который исполняется милисекунды.

Это про процесс.

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

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

Ты не мог бы процитировать, где он это сказал?

Про неиспользование шаблонов и прочего Майк говорит с 8-й минуты по 11-ю. Ответы на вопросы из зала начинаются с 1 часа 12-ти минут выступления, а вопрос о том, почему бы не использовать Си вместо Си++ был задан на 1-м часу 23-й минуте доклада.

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

Про неиспользование шаблонов и прочего Майк говорит с 8-й минуты по 11-ю

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

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

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

Понять бы еще что вы подразумеваете под «качеством».

Высокая производительность работы исполняемого кода - таково позиционирование Крестов среди языков высокого уровня.
Игродел Майк Эктон же показывает, что по производительности Си уделывает Си++, а использование последнего лишь дань общественному мнению.

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

Игродел Майк Эктон же показывает, что по производительности Си уделывает Си++

Чушь.

использование последнего лишь дань общественному мнению.

Так конкретная цитата будет?

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

Помогу

https://youtu.be/rX0ItVEVjHc?t=1h23m51s

Упрощенная транскрипция:

- What is rationality behind c++, why just not go with c?
- My personal preference would be c99 for sure, but...rationality is really cultural. Over last 15 years c++ has become culturally dominant, and so we accept that, and so we work with it

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

Давно смотрел это выступление. Удивило дикое ЧСВ у ТС. Особенно когда он отвечал на вопросы. Что нивелировало все выступление.

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

Игродел Майк Эктон же показывает, что по производительности Си уделывает Си++

где показывает ? как показывает ?

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

А теперь давай что-нибудь из отцов Unreal Engine. А то дохуя вас тут балаболов без опыта реальной разработки и с однобокими фактами наперевес.

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

Высокая производительность работы исполняемого кода - таково позиционирование Крестов среди языков высокого уровня.

Ну и что с этим не так? Сравните производительность C++ с производительностью других ЯВУ, особенно мейнстримовых. Хотя бы с Java и C#. Неужели у C++ будет низкая производительность?

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

Во-первых, как я вижу, вы не показали, что Майк Эктон говорил именно об этом. Во-вторых, можно ли считать C языком такого же высокого уровня, как C++?

В-третьих, вы, похоже, не понимаете, что предлагает C++ своим пользователям. Он предлагает a) возможность построения абстракций с очень невысокими накладными расходами на эти абстракции, и b) возможность, при необходимости, опускаться на самый низкий уровень для того, чтобы устранять узкие места такими же способами, как это делается в C.

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

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

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

Вчера Вася у подъезда сказал что лишп обогнал Си на синтетике числодробилок. Еще сказал много умных слов, но я не все запомнил. Пруфов тоже особо не было, но ты же понял что это рпавда?

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

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

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

Таких сейчас очень много, как мне кажется.

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

Ты русская языка писать не умеешь. Фразу построил криво - получил за это по соплям. Иди и редактируй пост, чтоб не позориться. Все остальное там верно, но тебя так и будут за кривые формулировки и опечатки чморить, поскольку к сути прикопаться нельзя. Не подставляйся так!

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

тебя так и будут за кривые формулировки и опечатки чморить

Невозможно зачморить царя. Даннинг и Крюгер не дадут его в обиду.

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

к тому, что инлайн функция на моей машине исполняется быстрее

Этому нет доказательств. Только брехня.

при том что вы с пеной у рта доказывали

Где я это доказывал?

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

О боже, глупое днище - толку с тобою разговаривать? Во-первых где она «ещё больше», если её нет? Что значит ещё? Верить в бенчи ламерка никто не будет.

#include <stdint.h>
#include <stdio.h>
#include <time.h>

double get_time_s(void) {
  struct timespec t;
  clock_gettime(CLOCK_REALTIME, &t);
  return (t.tv_nsec / 1e9) + t.tv_sec;
}

#define bench(n, f, ...) ({\
    uint64_t i = (n);\
    double start = get_time_s();\
    do { (void)f(__VA_ARGS__); } while(--i);\
    double time = get_time_s() - start;\
    fprintf(stderr, "%s(%.3f): %.3fcps\n", # f, time, (n / time));\
  })


inline void test(volatile uint64_t * a, volatile uint64_t * b) {
  ++(*a), ++(*b);
}
__attribute_noinline__ void test_noi(volatile uint64_t * a, volatile uint64_t * b) {
  ++(*a), ++(*b);
}


int main(void) {
  uint64_t n = 1000 * 1000 * 1000ul;
  volatile uint64_t a = 0, b = 0;
  
  bench(n, test, &a, &b);
  bench(n, test_noi, &a, &b);
}


test(1.720): 581311634.554cps
test_noi(1.743): 573792871.183cps

Как же ламерок слился. Слился с «процессов», слился с кешей. Начал съезжать на вывод темы на «царь доказывал то, что инлайн медленнее» - ты реально «думаешь», что своей одной извилиной меня куда-то загонишь? Я тебе позволяю юлить - радуйся пока позволяю.

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

Фразу построил криво - получил за это по соплям.

В чём она кривая - нука объясни.

Все остальное там верно, но тебя так и будут за кривые формулировки и опечатки чморить, поскольку к сути прикопаться нельзя.

Нет там «Фразу построил криво» - ты неправильно прочёл и докопался, а потом понял, что это не так, но всё равно продолжаешь кукарекать про «кривую формулировку».

Раз не понял - формулировка «не понятна», «не прозрачна», но никак не «кривая», либо «неправильная».

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

Высокая производительность работы исполняемого кода - таково позиционирование Крестов среди языков высокого уровня.

Мало того, что цепепе по уровню едва ли выше, чем Си, так ещё и его адепты даже имеющиеся примитивные механизмы абстракции, такие как классики, и то не применяют. Вот смотри. Выше было предложено для ошибок использовать класс Error, потому что использовать для этого std::string можно, но глупо, т.к. это игнорирует даже те самые механизмы абстракций, которые цепепе и отличают от Си. Истерика от этого классика потом перешла к появлению на свет доморощенных бенчмариков, которые демонстрируют как std::string обгоняет по скорости конструирования std::runtime_error. Из чего можно сделать вывод, что вместо throw std::runtime_error следует писать throw std::string, ведь быстрее же. Хотя зачем эти накладные расходы, когда можно отключать исключения... Т.е. даже те «высокоуровневые» средства, которые и есть в цепепе, самими же цепепешниками либо не используются, либо они их избегают и боятся, либо критикуют. Такие дела. :-)

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

Привет, маминхуй. Врядли поймешь, но все же: цэпепешники использут те фичи, которые в данный момент удовлетворят требовани проекта/части проекта/модуля. Захотят удобства, используют все, что нужно, потребуется скорость - напишут С-подобную кэш-френдли портянку. Хотя... Тусуй колоду,

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

Этому нет доказательств.

inc(2.269): 440791370.195cps incnoi(2.341): 427088741.773cps

ладно, если даже если вы ослепли, то я — не врач

next_time ★★★★★
()
Ответ на: комментарий от AnonCxx
test(1.720): 581311634.554cps
test_noi(1.743): 573792871.183cps

лол. даже по вашему тесту, на вашей машине выходит, что инлайн быстрее ))

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

Иди уроки учи и не лезь в разговоры взрослых

Это ты-то взрослый?

Картинку справа сверху посмотри дубина и почуствуй разницу

Попробуй читать учебники, а не только смотреть картинки. Но современные учебники, а не рекламные материалы MS 20-летней давности. Например, Танненбаум, 4 редакция: «Kernel mode in Windows is structured in the HAL, the kernel and executive layers of NTOS, and a large number of device drivers implementing everything from device services to file systems and networking to graphics». Микроядро? Не, не слышали.

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

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

Тебе в школе еще не объяснили что значит дефис в таком контексте?

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

Школьник - научись отличать kernel mode

https://en.wikipedia.org/wiki/Architecture_of_Windows_NT#/media/File:Windows_...

от kernel

https://en.wikipedia.org/wiki/Architecture_of_Windows_NT#Kernel

https://en.wikipedia.org/wiki/Protection_ring#SUPERVISOR-MODE

ты цитируешь и не понимаешь о чем там говорится, ядро NT - микроядро, архитектура ОС на базе такого ядра - типичная микроядерная. Что работает на одном уровне с микроядром никак не влияет на архитектуру ОС, перечитай вики еще раз если до тебя не доходит.

In a monolithic kernel, the operating system runs in supervisor mode and the applications run in user mode. Other types of operating systems, like those with an exokernel or microkernel, do not necessarily share this behavior.

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

Ты снова привел кучу нерелевантного хлама.

In a monolithic kernel, the operating system runs in supervisor mode and the applications run in user mode.

(пожимая плечами) Ну, поздравляю, ты нашел описание Windows. О чем ты вообще споришь?

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

О чем ты вообще споришь?

действительно - чего я с тобой дебилом спорю

https://en.wikipedia.org/wiki/Architecture_of_Windows_NT#Kernel

That is, the kernel performs almost all the tasks of a traditional microkernel; the strict distinction between Executive and Kernel is the most prominent remnant of the original microkernel design, and historical design documentation consistently refers to the kernel component as «the microkernel».

перевести сможешь ? хотя мне лично пох.й

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

чего я с тобой дебилом спорю

Да ты еще и нервничаешь почему-то.

the strict distinction between Executive and Kernel is the most prominent remnant of the original microkernel design

перевести сможешь ?

«Строгое разделение между Исполнительной системой и Ядром - самый заметный остаток исходного микроядерного дизайна» - что как бы намекает, что исходный микроядерный дизайн давно похерен. От себя добавлю - дизайн никогда не был по-настоящему микроядерным, об этом еще ~25 лет назад писали (тогда микроядра были в моде).

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

Ну надо же, смайлик попрощался, но вернулся вновь.

Выше было предложено для ошибок использовать класс Error, потому что использовать для этого std::string можно, но глупо, т.к. это игнорирует даже те самые механизмы абстракций, которые цепепе и отличают от Си.

Маленькая проблемка: предложенный класс Error имел говнореализацию. Даже вот такая реализация не имела бы проблем вашего класса Error:

class parsing_result {
  std::string desc_;
public :
  parsing_result(const parsing_result &) = default;
  parsing_result(parsing_result &&) = default;
  parsing_result(std::string desc) : desc_(move(desc)) {}

  bool success() const { return desc_.empty(); }
  const std::string & error_desc() const { return desc_; }
};

Истерика от этого классика потом перешла к появлению на свет доморощенных бенчмариков, которые демонстрируют как std::string обгоняет по скорости конструирования std::runtime_error.

Да какие проблемы? Предложите недоморощенные, aka промышленного качества, бенчмарки.

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

что как бы намекает, что исходный микроядерный дизайн давно похерен

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

These mechanisms include low-level address space management, thread management, and inter-process communication (IPC)

и режим процессора в котором работает микроядро никак не влияет на его архитектуру, вот например тоже типичне микроядро

http://prex.sourceforge.net/doc/overview.html

Практически все RTOS микроядерные и работают на процессорах у которых нет даже MPU или MMU для разграничения и защиты памяти.

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

а архитектура у ядра NT классическая микроядерная - микроядро содержит только минимально необходимое

Вы откуда это знаете? Работаете в Microsoft в команде разработке ядра Windows?

Практически все RTOS микроядерные и работают на процессорах у которых нет даже MPU или MMU для разграничения и защиты памяти.

Какое отношение OpenSource-ные RTOS имеют к ядру Windows?

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

и режим процессора в котором работает микроядро никак не влияет на его архитектуру, вот например тоже типичне микроядро

http://prex.sourceforge.net/doc/overview.html

Ну и? Микроядро в режиме ядра, остальное - в режиме пользователя: http://prex.sourceforge.net/doc/img/overview.gif

Всё, как в учебниках.

Практически все RTOS микроядерные

RTOS пишут и жук, и жаба, и этикетки на свои поделия лепят любые, лишь бы поярче.

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

Маленькая проблемка: предложенный класс Error имел говнореализацию.

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

Даже вот такая реализация не имела бы проблем вашего класса Error:

Эта реализация демонстрирует то, что цепепе ты знаешь не очень хорошо, а ещё стиль не очень: Смотри:

// эти строчки не нужны, компилятор сгенерирует сам.
parsing_result(const parsing_result &) = default;
parsing_result(parsing_result &&) = default;

// эти функции-члены можно объявить noexcept.
// особенно тем, кто считает микросекунды в своих бенчмариках.
bool success() const { return desc_.empty(); }
const std::string & error_desc() const { return desc_; }

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

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

Это разница 1%, которая вызвана не инлайном, а разницой в сгенерированном коде.

__attribute_noinline__ void test_tsar(volatile uint64_t * a, volatile uint64_t * b) {
  asm(
    "incq (%0)\n"
    "incq (%1)\n"
    ::  "r"(a), "r"(b): "rdi", "rsi"
  );
}
test(1.725): 579755370.366cps
test_tsar(1.575): 634775519.297cps

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

Скобочки дебила, потуги дебила, смешно.

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

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

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

Эта реализация демонстрирует то, что цепепе ты знаешь не очень хорошо

Еще раз для совсем тупых: я не эксперт в C++ и никогда не декларировал, что знаю C++ хорошо.

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

Ну и? Микроядро в режиме ядра, остальное - в режиме пользователя: http://prex.sourceforge.net/doc/img/overview.gif

так у тебя зрение херовое - ну тогда ладно, драйверы там в режиме ядра работают если чо

RTOS пишут и жук, и жаба, и этикетки на свои поделия лепят любые, лишь бы поярче.

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

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

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

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

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

так у тебя зрение херовое - ну тогда ладно, драйверы там в режиме ядра работают если чо

У тебя знания херовые - драйверы работают в режиме ядра и у классического Mach.

полагаю

Лучше бы ты выводы делал.

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

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

Во-первых, варианту смайлика с его классом Error была предъявлена конкретная претензия: этот класс в принципе на поддерживает работу с динамическими строками (в отличии от подхода, примененного в picojson). Вам нужны какие-то экспертные и/или эмпирические оценки для того, чтобы понять состоятельность или несостоятельность этой претензии?

Во-вторых, здесь были предъявлены результаты замеров. Что в этих результатах не устраивает? Где какие-либо другие результаты?

Или вам нужны мнения «признанных экспертов», а своей головой вы думать не приучены?

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

драйверы работают в режиме ядну и чего дра и у классического Mach

и это твои доказательства того что ядро NT - не микроядро ? повторю картинку

https://en.wikipedia.org/wiki/Architecture_of_Windows_NT#/media/File:Windows_...

найди дохера отличий от того что ты буквально только что назвал классическим микроядром

http://prex.sourceforge.net/doc/overview.html

разницв только что в PREX не релизована куча говна из Executive

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

Во-первых, варианту смайлика с его классом Error была предъявлена конкретная претензия: этот класс в принципе на поддерживает работу с динамическими строками

Перед ним никто не ставил задачу написать класс Error с динамическими строками.

(в отличии от подхода, примененного в picojson).

Подход не правильный - std::string не предназначен олицетворения ошибки.

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

Конечно, ведь суть представленного класса Error была не в том, чтобы решить внезапно возникшую задачу генерации динамических строк, а в том, что он просто демонстрировал вариацию правильного подхода, а не того, что в picojson. Претензии к классу Error, который не содержит копию string, а содержит указатель на char, в данном случае просто выглядит как придирка на почве личной неприязни.

Во-вторых, здесь были предъявлены результаты замеров. Что в этих результатах не устраивает? Где какие-либо другие результаты?

Там результаты сравнения string с runtime_error, а не с Error смайлика.

Или вам нужны мнения «признанных экспертов», а своей головой вы думать не приучены?

Так я своей головой подумал и дал свою оценку твоему классу Error.

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

так у тебя зрение херовое - ну тогда ладно, драйверы там в режиме ядра работают если чо

драйверы работают в режиме ядну и чего дра и у классического Mach

и это твои доказательства того что ядро NT - не микроядро ?

Память у тебя херовая, но специально для тебя привожу полную цитату.

повторю картинку

Ответ см. выше.

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

но специально для тебя привожу полную цитату

т.е. ты согласился что в микроядерных ОС мироядро не обязательно строго отделено от остальной части системы ? ну и какие еще вопросы у тебя остались - почему ядро NT не микроядро ?

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

Перед ним никто не ставил задачу написать класс Error с динамическими строками.

Слив. Смайлик говорил, что он может сделать «правильнее», чем picojson. А picojson возвращает динамические строки.

Подход не правильный - std::string не предназначен олицетворения ошибки.

Какие ваши доказательства?

Там результаты сравнения string с runtime_error, а не с Error смайлика.

Напомню, что смайлик кричал про возврат runtime_error и таки привел в качестве решения проблемы вариант с runtime_error. Что говорит о признании им правомочными претензий к качеству реализации класса Error.

Так я своей головой подумал и дал свою оценку твоему классу Error.

Я не предоставлял своей реализации класса Error. Вы бредите.

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