О размере стандарта C++

Почему странно? Почти везде такой подход.

А я не виноват, что вы не способны распознать сарказм.

Так это была попытка пошутить... Ну с шутками у вас еще хуже, чем с банальной эрудицией.

Всё осиливать и не надо. Чем больше осилишь и чем ловчее осиленным вертишь тем выше твой уровень. Достаточно знать где посмотреть.

perl5_guy

сам-то когда perl6 осилишь? и зачем? :)

С массивами что делать в таком подходе?

У «самого языка XML» стандарт тоже маленький, а у соседних XSLT - конский. Что сказать-то хотел, что можешь прочитать сотни страниц? Молодец, все могут. Это не повод переходить на описываемый ими шлак.

std::array же

итого, за почти 20 лет «сам» C++ распух чуть более чем на 100 страниц, на треть от C++98.

44%, вообще-то. Ближе к полутора разам.

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

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

в ущерб производительности и лаконичности.

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

Может у вас хотя бы с примером ущерба для лаконичности получится. Или нет?

не бывает наворотов бесплатно.

Ну т.е. в очередной раз пустой звиздеж. Ожидаемо.

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

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

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

Ето да. Одна из причин уменьшения числа страниц в C++14 по сравнению с C++11 в том, что между параграфами убрали пустую строку.

идёт замусоривание и опопсение языка.

Чта? Неосиляторы называют «попсой» всё что не могут осилить?

нет. всё, без чего спокойно обходились 20 с лишним лет.

Так и без самого C++ спокойно обходились. Не аргумент.

ты понимаешь

Я понимаю, что когда что-то есть в наличии, то это наличие можно продемонстрировать примерами.

Вот вы говорите про ухудшение производительности и лаконичности. Значит у вас это в наличии. Вот и покажите на конкретных примерах.

Но вы не сможете. Ведь говорить предметно — это совсем не то, что написать в резюме про отличное знание языка C++.

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

Например,
https://habr.com/ru/company/jugru/blog/438260/
Это, наверное, не подходит под те варианты ущерба, о которых хотелось услышать... Но ущерб вообще не такая штука, которую хочется примерить на себя ;)

я отлично знаю С++. и я его знаю уже лет 20 с лишним. меня никогда не удивляли доработки стандартов

Я не знаю языка C++, хотя работаю с ним больше 20 с лишним лет. Меня всегда удивлял базовый синтаксис языка. А доработки стандартов вызывают подлинное недоумение.

Я не могу читать чужой код, потому что в 90% слуаев не понимаю, что там вообще написано. Я все эти годы мечтал найти хотя бы одно руководство, которое бы на пальцах поясняло, как распарсивать базовый синтаксис языка при чтении программ. Но даже этого не нашел. Одно только ключевое слово const чего стоит, например невозможно запомнить в каких случаях имеем неизменяемый указатель, а в каких - неизменяемое значение по указателю. И хорошо если указатель первого уровня, когда появляется второй - то это вообще ребус. Вот скажи мне, как человек который отлично знает C++, как ты с этим управляешься? В чем секрет?

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

работаю с ним больше 20 с лишним лет

Ты прикалываешься?

Тебе уже много раз говорили, что проблема на твоей стороне.

Я программисту на C# показывал эту разницу с const. Он хоть и удивился, но сразу ее понял и запомнил.

Нет чтобы сслыку на источник дать, а на на очередной перевод на швабре.

Ну а статья ни о чём. Жаловаться на время компиляции и сравнивать с Си - ну бред же. Зачем мне работать вместо компилятора?

парсинг там очень простой. справа налево, с учётом приоритета операций. это требует некоторого опыта, но это вовсе не сложная операция. чуть менее читабельны темплейты. но и там нет ничего сложного.

а то, что ты спрашиваешь про const, описывается, емнип, чуть ли не у K&R. ну, во всяком случае, в любом нормальном учебном пособии по С. где-то в самом начале, где объясняется работа с типами и указателями. это обычная сишная нотация и плюсы в этом плане ничем от C не отличаются. совершенно тот же принцип - разбирать выражение справа налево.

я как-то даже в детстве с этим проблем не испытывала. я начинала изучать C в 12 лет. и никаких учебников не было. были текстовые файлы с документацией, которые шли с компилятором. позже у меня появилась книжка K&R.

вообще, прежде чем переходить к плюсам, надо изучить C. по любому современному учебнику, с выполнением заданий, которые там обычно бывают. я не знаю, насколько примеры из K&R сейчас актуальны (немного изменились стандарты, стало чуть больше типов), но задания там вполне адекватны и актуальны до сих пор. люди пытаются сразу влезть в плюсы, задают дурацкие вопросы. я понимаю, что у них в голове каша. поэтому надо начинать с малого, а потом уже переходить к более сложному. и в этом плане попытки подогнать плюсы под нубов я считаю особо вредными. нубы копируют штампы, которые они запомнили механически, но они не понимают, что они пишут. и «упрощение» синтаксиса не меняет сути проблемы. оно только делает ещё хуже: ещё больше непонимающих ломанётся «писать код». а в плюсах говно писать нельзя. там даже если компилятор сожрёт код, то не факт, что он будет работать. поэтому нужно понимание. и то, что люди неспособны отслеживать управление памятью - это тоже отупение. это значит, что они не понимают, как работает их собственный код. поэтому я против песочниц и таких «стандартов».

Нет, я реально каждый раз лезу в справочники чтобы понять что имел в виду автор. Вспоминаю, освежаю в памяти как там этот const в данном случае надо интерпретировать. И так по каждому аспекту языка. Вот недавно только научился выискивать пропадание данных со стека в выражениях, где доступ по указателю идет:

Что-то не могу получить из QString строку const char *

но это ведь тоже нелогично: константность в С++ нетранзитивна. то есть, нельзя гарантировать что если указатель константный, то содержимое по указателю менять нельзя. указатель константный, а то на что он указывает — мутабельное. и компилятор тут ничего отследить и гарантировать не может, в отличие от immutable в D, например.

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

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

Нет уж, потом нытьё про непонятные буковки выслушивать...
А тут вот сразу по существу: на тот ущерб нам покласть, чужой ущерб нам не ущерб и прочие аналогичные отмазки...

Как у классика: «К пуговицам претензии есть?»

парсинг там очень простой. справа налево, с учётом приоритета операций

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

Вот недавно только научился выискивать пропадание данных со стека в выражениях, где доступ по указателю идет:

Я научу тебя делать это правильно.

Вот у нас есть бажный код.

#include <QtCore/QtCore>

int main()
{
    QString logFileName="/Directory/Logs/Log.txt";
    qDebug() << "Log file name: " << logFileName;

    const char *fileName = logFileName.toStdString().c_str();
    printf("Const char * filename: ");
    printf(fileName);
    printf("\n");
}

g++ -O3 -isystem"/usr/include/qt" -fpic 1.cpp -l Qt5Core -fsanitize=address -fsanitize=undefined -fsanitize=leak -fno-omit-frame-pointer -g3

Вот вывод:

./a.out 
Log file name:  "/Directory/Logs/Log.txt"
=================================================================
==5858==ERROR: AddressSanitizer: heap-use-after-free on address 0x603000000430 at pc 0x7fec44416069 bp 0x7fff59666ff0 sp 0x7fff59666768
READ of size 2 at 0x603000000430 thread T0
    #0 0x7fec44416068 in printf_common /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:489
    #1 0x7fec44416a0c in __interceptor_vprintf /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1501
    #2 0x7fec44416b07 in __interceptor_printf /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1547
    #3 0x55903f1a02de in main /home/fsb4000/test/c/1.cpp:10
    #4 0x7fec42e94222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
    #5 0x55903f1a101d in _start (/home/fsb4000/test/c/a.out+0x701d)

0x603000000430 is located 0 bytes inside of 24-byte region [0x603000000430,0x603000000448)
freed by thread T0 here:
    #0 0x7fec444bcca1 in operator delete(void*) /build/gcc/src/gcc/libsanitizer/asan/asan_new_delete.cc:135
    #1 0x55903f1a02ac in __gnu_cxx::new_allocator<char>::deallocate(char*, unsigned long) /usr/include/c++/8.2.1/ext/new_allocator.h:125
    #2 0x55903f1a02ac in std::allocator_traits<std::allocator<char> >::deallocate(std::allocator<char>&, char*, unsigned long) /usr/include/c++/8.2.1/bits/alloc_traits.h:462
    #3 0x55903f1a02ac in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_destroy(unsigned long) /usr/include/c++/8.2.1/bits/basic_string.h:226
    #4 0x55903f1a02ac in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose() /usr/include/c++/8.2.1/bits/basic_string.h:221
    #5 0x55903f1a02ac in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() /usr/include/c++/8.2.1/bits/basic_string.h:657
    #6 0x55903f1a02ac in main /home/fsb4000/test/c/1.cpp:8
    #7 0x7fec42e94222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)

previously allocated by thread T0 here:
    #0 0x7fec444bbd29 in operator new(unsigned long) /build/gcc/src/gcc/libsanitizer/asan/asan_new_delete.cc:90
    #1 0x55903f1a0523 in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) /usr/include/c++/8.2.1/bits/basic_string.tcc:219
    #2 0x55903f1a0523 in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char const*, std::__false_type) /usr/include/c++/8.2.1/bits/basic_string.h:236
    #3 0x55903f1a0523 in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*) /usr/include/c++/8.2.1/bits/basic_string.h:255
    #4 0x55903f1a0523 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, unsigned long, std::allocator<char> const&) /usr/include/c++/8.2.1/bits/basic_string.h:502
    #5 0x55903f1a0523 in QByteArray::toStdString[abi:cxx11]() const /usr/include/qt/QtCore/qbytearray.h:689
    #6 0x55903f1a0523 in QString::toStdString[abi:cxx11]() const /usr/include/qt/QtCore/qstring.h:1372
    #7 0x55903f1a0523 in main /home/fsb4000/test/c/1.cpp:8
    #8 0x7fec42e94222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)

SUMMARY: AddressSanitizer: heap-use-after-free /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:489 in printf_common
Shadow bytes around the buggy address:
  0x0c067fff8030: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd
  0x0c067fff8040: fd fd fa fa fd fd fd fd fa fa fd fd fd fd fa fa
  0x0c067fff8050: fd fd fd fd fa fa 00 00 00 00 fa fa fd fd fd fd
  0x0c067fff8060: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd
  0x0c067fff8070: fd fd fa fa fd fd fd fd fa fa fd fd fd fd fa fa
=>0x0c067fff8080: fd fd fd fd fa fa[fd]fd fd fa fa fa fa fa fa fa
  0x0c067fff8090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff80a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff80b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff80c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff80d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==5858==ABORTING

Что мы видим из этого вывода:

ERROR: AddressSanitizer: heap-use-after-free // обращаемся к памяти, которую уже очистили
#3 0x55903f1a02de in main /home/fsb4000/test/c/1.cpp:10 // это строка printf(filename), именно тут мы падаем
freed by thread T0 here: 
#6 0x55903f1a02ac in main /home/fsb4000/test/c/1.cpp:8 // память была очищена, в строке     const char *fileName = logFileName.toStdString().c_str();
previously allocated by thread T0 here:
#7 0x55903f1a0523 in main /home/fsb4000/test/c/1.cpp:8 // выделена в той же строке

Если сразу не видно, какой тут баг, то нужно разложить строку на две, создание временной переменной std::string, и собственно получение строки С(вообще всегда в строке которой баг, убрать все дополнительные действия, чтобы в каждой строке выполнялось только одно действие, и потом перезапустить санитайзер)

    auto s = logFileName.toStdString();
    const char *fileName = s.c_str();

Санитайзеры это имба, супер крутая вещь, всегда пользуйся санитайзерами, в своих программах!

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

А ещё санитайзеры имба, потому что они работают для многих(всех?) языков LLVM и gcc.

То есть овладев этим инструментом для C++, ты овладел сразу отличным методом поиска ошибок для

• C++
• C
• Vala
• Objective-C
• Swift (видел в какой-то статье, сам Swift не разу не запускал)
• D (тоже нашёл ссылку в инете, на пример)
• возможно в других языках gcc и llvm, нужно уточнить...

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

первое, что нашёл гугл: http://cseweb.ucsd.edu/~ricko/rt_lt.rule.html

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

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

Или кто-то всерьёз под изучением языка понимает зубрёжку списка функций и их аргументов из его стандартной библиотеки?

Вот я такой. Для C++ это накачка знания сторонних либ, само собой Qt, а также смотря что под задачу.

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

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

я отлично знаю С++

Бла-бла-бла.

Я вот знаю C++ так себе, но даже мне не составит труда сходу вспомнить несколько моментов в новых C++, которые положительно сказались на производительности:

move-semantic, благодаря чему в новом C++ вот такой код:

std::vector<double> make_data() {
   ...
   return std::vector<double>(100500, 0.0);
}

Сюда же добавим возможность перегрузки операций для rvalue references.

Сюда же добавим constexpr, который от версии к версии позволяет делать все больше и больше в compile-time.

Сюда же добавляем guaranteed copy elision из C++17.

Примеров на счет лаконичности так же можно привести несколько вот прям с ходу:

auto для вывода типа переменной;

range-for;

делегирующие конструкторы;

auto для вывода возвращаемого значения (особенно актуально для шаблонов функций);

decltype.

Ну и отдельно упомянем variadic templates, для имитации которых в старых C++ приходилось много приседать и получалось в итоге так себе.

В принципе, от человека, который отлично знает C++, можно было бы ожидать хотя бы одного конкретного примера обратного.

Но дело в том, что вы лишь говорите об отличном знании C++. Поэтому кроме бла-бла-бла сказать ничего не можете.

А могли бы, например, упомянуть initializer_list. Если бы знали что это и в чем его особенности.

Для того, чтобы статья была подтверждением тезисов Iron_Bug, необходимо, чтобы в статье было приведено два примера решения одной и той же задачи одним и тем же методом. Чтобы из примеров было видно, что на старом C++ задача решается в N строк, при компиляции требует M времени и работает затем S секунд. А на новом C++ эта же самая задача этим же самым методом решается в (N+k1) строк, компиляция требует (M**k2) времени и работает затем (S*k3) секунд.

Есть такое в статье на которую вы сослались?

Я не знаю языка C++, хотя работаю с ним больше 20 с лишним лет.
Я не могу читать чужой код, потому что в 90% слуаев не понимаю, что там вообще написано.

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

Вот сможете назвать хотя бы три объективных причины почему в вашем случае стоит предпочитать C++ другим альтернативам?

Какие ещё буковки?

Он же на Qt пишет, а тут без альтернатив.

Я думаю, что Qt — это уже последствия выбора C++.

Сильно сомневаюсь, что для его задач нужен именно C++, а не Java или, скажем, Eiffel, у которого была вполне себе достойная EiffelVision прямо «искаропки».

А на чём ещё писать гуй? Остаётся или джава или электрон.

PyQt5

У меня написано на чем писать гуй: Java или Eiffel. Для патологических неасиляторов плюсов, вроде Xintrea, Eiffel может быть более чем правильным выбором. Тем более, что для открытых проектов Eiffel бесплатен.

Так же можно вспомнить про FreePascal и его библиотеки, на основе которых Lazarus написан. Опять же, для тех, кто в C++ ну вообще никак, Pascal отличный выбор. Это было проверено еще лет 30 назад.

man Qt5

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

Гуи на Java страшный что ппц. Про Eiffel - это шутка? Lazarus вроде поверх Qt работает.

Он же мёртв. Так что-то новое запили, но я ещё не тыкал.

Я вообще слабо представляю себе биндинги для Qt. Там же всё на наследовании и виртуальных функциях. Как это через биндинги выразить?

Какие ещё буковки?

Вон, уже началось:

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

И это в отношении русского текста, написанного не самым сложным языком.

 — Не верьте, нет у них туалетной бумаги! Уже и унитаз приносил, и жопу показывал...
(q) бородатый анекдот