Будущее g++

кто сказал, что код безопасный? Выше написал

а теперь расскажи это своему товарищу, для которого крестовые строки безопасны на 100 процентов

вообще-то, это как раз «тяжёлое наследие C», в виде null-terminated строк и «сырых» указателей. Вроде как, их в каком-то новом стандарте C++ хотят убрать от греха подальше...

ты правишь сообщения быстрее, чем я тебе успеваю отвечать )

но все таки

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

это если ты вдруг забыл, о чем речь.

вообще-то, это как раз «тяжёлое наследие C», в виде null-terminated строк и «сырых» указателей

а так то кресты надежны, как скала, да? ) и голову можно выбросить, за ненадобностью.

понял, вопросов больше не имею.

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

это если ты вдруг забыл, о чем речь.

Вопрос, что понимать под «стандартными» методами. Проблема в том, что C++ должен включать (почти) весь C, это его «родовая» травма. Речь о том, что если не использвать низкоуровневые фичи (типа raw pointer и null terminated строк), а только то, что есть в std, то C++ даёт почти полную гарантию безопасной работы. К сожалению, костыли совместимости с C приводят иногда к таким вот ситуациям...

а так то кресты надежны, как скала, да? ) и голову можно выбросить, за ненадобностью.

если бы это было так, то C++ стал бы идеальным ЯП :) К сожалению, это не так... (в других ЯП тоже есть свои нюансы, если копнуть поглубже)

если не использвать низкоуровневые фичи (типа raw pointer и null terminated строк), а только то, что есть в std, то C++ даёт почти полную гарантию безопасной работы.

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

с++

#include <iostream>
#include <string>
#include <string_view>

int main() {
  std::string s = "Hellooooooooooooooo ";
  std::string_view sv = s + "World\n";
  std::cout << sv;
}

g++ -std=c++17 test.cpp -o test
./test

ой. опять тяжкое наследие гадит?

https://gcc.godbolt.org/z/4K4aGc

godbolt прилёг что-ли…

Вот линк на картинку тогда: https://imgur.com/a/VKHtAsr

https://gcc.godbolt.org/z/a55j73

:)

да пффф

https://godbolt.org/z/37f4Mz

а вот так ваще огонь

https://godbolt.org/z/b6d1T3

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

ну тут либо еще один const

const char* const result

либо

сonstexpr const char* result

в обоих случаях на этапе компиляции просто не пропустит.

Особенность реализации о которой написано в документации к методу с_str() для string.

Те же QString вообще напрямую не преобразуются к c_str, но через преобразование к QByteArray и дерганье data() отпадает нужда и в том что написано выше. Это просто stl string и его с_str() немножко калеки.

Согласен, ерунда получается... Спасибо за примеры, будем знать :)

P.S. Кстати, про это написано в документации:

Notes

It is the programmer's responsibility to ensure that the resulting string view does not outlive the string. 

Кстати, про это написано

да, и что?

+--------+-------------------------------+-----------+
| Header | Binary safe C alike string... | Null term |
+--------+-------------------------------+-----------+
         |
         `-> Pointer returned to the user.

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

sds s = sdsnew("Hellooow");
s++ // nnooooooo...!

недопустимая операция. но тем не менее.

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

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

Тезис был о том, что в чистом С гораздо проще написать небезопасный код, чем в C++. Я согласен, что и в последнем есть проблемы, и там тоже можно «отстрелить» себе разные части тела. И это, на мой взгляд, дефект языка, связанный с его «историческим наследием».

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

В общем, дискуссия исчерпала себя. Всё тлен, жизнь боль, нет совершенства в этом мире...

Эпоха Dos начала заканчиваться, когда появился DirectX (1995 г.) и окончательно завершилась с приходом Windows 2000 (2000 г.). То есть у си было время с начала 80-х до 2000 чтобы захватить нишу системного ПО. В то время как у паскаля оставалась ниша прикладного ПО

Эпоха MS-DOS — это 1981-1995 год, время наибольшего использования и собственно наличия официальных релизов. Это же был и переходной период для Си, когда он начал заменять ассемблер в индустрии. Это же был и период, когда индустрия поняла, что писать крупные системы на Си нельзя, откуда возник спрос на C++. Напомню, что стандарт паскаля бы принят 1983 года, стандарт Си — 1989 год, стандарт C++ — 1998 год. То есть, паскаль как платформонезависимый язык утвердился раньше, а Си довольно долго сохранял роль утилиты для компиляции юниксовых программ, так сказать «широко известен в узких кругах».

А теперь посмотрите на даты создания DirectX и Windows 2000

У борланда была визуальная IDE еще в начале 90-х, так что аргумент не засчитывается.

Введено регулярное обновление и усложнение C++ (было раз в ~10 лет, теперь 3 года), Java (было раз в 2 года, теперь 2 раза в год). В связи с этим я спрашивал о необходимости введения потоков в STL

Это тупо маркетинг, не более того. Примерно как мозила перешла с версионирования 1.4.2-1.4.3-1.4.5 на 42-43-45. Реально важного и полезного между версиями ничего не возникает. Последняя реально полезная введенная в кресты фича — это лямбды, всё остальное — бурление говен, вроде «уберем из стандарта фичи, которые хорошие программисты никогда не используют», или «добавим в язык чужеродный синтаксис/семантику для очередного из бесчисленных частного случая», или просто «нынче в интернете модно иметь %фичанейм%, давайте не будем отставать от „прогресса“» — последнее особо актуально в маркетинговом плане, потому что индусы любят, когда есть много фич, а в последнюю очередь их волнует то, насколько фичами удобно пользоваться и как хорошо они сочетаются.

Зачем-то добавился новый компилятор C++

Какой? Шланг? Это не совсем компилятор C++, это скорее компилятор, написанный на C++, но компилирует он что угодно.

В Python внедряются особенности, противоречащие прежней идеологии

Идеология питона — это implementation-defined язык, который беспорядочно тянет хайповые фичи в свой состав. Потому вполне себе идеологично и идеоматично.

Похоронен Flash. Взамен ему предлагают WASM

Если бы адоба могла сделать среду выполнения, которая была бы хоть чуть менее дырява, чем друшлаг, то у нее до сих пор была бы ниша. На самом деле Flash заменили при помощи HTML5.

C# c Unity уже уверенно сидит в нише разработки игр. То есть там, где до недавнего времени у C++ была монополия

К сожалению, я играл в эти игры. То, что в нулевых годах не мог позволить себе даже трэшэвый проект, теперь у нас повсюду. А именно, провисания игры на секунду-другую даже на самых топовых компьютерах с 1080 и 9900K, задержка ввода, которая плавает в зависимости от сцены при довольно стабильной частоте кадров. Например, They Are Billions — типовой такой сишарпный современный проект, клон Stronghold, но почему-то у крестового Stronghold таких проблем никогда не было.

Язык Си дает изначально крайне опасные методы работы с данными

гарантии безопасности создаются при помощи проверки предусловий, постусловий и инвариантов

А теперь то же самое, только на русском и не абстрактными фразами.

const char *result = std::string(«some»+ «thing» + «something else»).c_str();
сдуру, знаешь ли, можно и хер сломать. (превед s++)

Переход на сишные указатели = выход за стандартные методы. Это как в рекламе: если видишь звездочку — ищи примечание, в котором зарыта собака.

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

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

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

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

Фичи тут: https://en.cppreference.com/w/cpp/compiler_support
Там новость и фоточка. В следующий раз когда соберётся комитет, они будут обсуждать С++23

А, все-таки модули есть, но никем не поддерживаются. Чудненько. Ждем больше таких стандартов.

а теперь расскажи это своему товарищу, для которого крестовые строки безопасны на 100 процентов

Да я вижу прекрасно, что там в коде. Ты взял указатель на строку и вынес за пределы видимости. Взяв указатель ты прежде всего отказался от автоматического контроля видимости и взял на себя всю ответственность за работу с указателями. В C++ есть ссылки «&», потому использование сишных указателей недопустимо.

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

это если ты вдруг забыл, о чем речь.

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

g++ -std=c++17 test.cpp -o test
./test

ой. опять тяжкое наследие гадит?

Нет, это C++17 гадит.

https://godbolt.org/z/37f4Mz
а вот так ваще огонь
https://godbolt.org/z/b6d1T3
крч если стоит задача нарукожопить - их есть у меня

Да, это снова C++17, в котором внесли в набор стандартных инструментов небезопасную работу с указателями.

Тезис был о том, что в чистом С гораздо проще написать небезопасный код, чем в C++. Я согласен, что и в последнем есть проблемы, и там тоже можно «отстрелить» себе разные части тела. И это, на мой взгляд, дефект языка, связанный с его «историческим наследием».
Конечно, и в Паскале можно написать небезопасно. Но это надо постараться.
В общем, дискуссия исчерпала себя. Всё тлен, жизнь боль, нет совершенства в этом мире

Исходная спецификация паскаля вообще не допускала никаких небезопасных операций. Но в итоге мы имеем такую реализацию, как Free Pascal, в которой работа с указателями слизана с Си. Так же до C++17 в языке не было никаких «кароче, сам следи за временем жизни, компилятор хочет отдохнуть».

У борланда была визуальная IDE еще в начале 90-х, так что аргумент не засчитывается.

Была то была, но когда она начала нормально работать с DirectX? Точных данных я не нашёл, но по отзывам до Delphi 5 (1999) проблемы были. А без DirectX нормального fps под Windows не получить. Соответственно, нишу в создании игр паскаль потерял и двинулся в сторону документооборота, где уже Java всё захватывала.

Это тупо маркетинг, не более того. Примерно как мозила перешла с версионирования 1.4.2-1.4.3-1.4.5 на 42-43-45.

Это не «тупо» маркетинг, а вынужденный маркетинг. И сравнение с мозиллой тут удачно. Вопрос: кто заставляет Java, у которой всегда лозунг был «тупо, но стабильно» ускорить процесс развития?

Реально важного и полезного между версиями ничего не возникает.

Ну так и я об этом. Зато возникает вредное. Обратимся к этой ссылке: Будущее g++ (комментарий) Тут человек пишет:

Нет, это C++17 гадит.

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

Шланг? Это не совсем компилятор C++, это скорее компилятор, написанный на C++, но компилирует он что угодно.

Ну вот и ответ автору темы. gcc не может отдать C++ в руки clang потому что тот «не совсем компилятор C++».

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

А была ли у adobe такая цель? Судя по действиям, похоже что цель была похоронить.

На самом деле Flash заменили при помощи HTML5.

Flash был более удобен мелким компаниям и одиночкам. Крупным компаниям это было не выгодно, ибо конкуренция. Вот и заменили. Дыры какие-то придумали. Как будто в другом ПО дыр нет. На что заменили? На TypeScript? На что заменят? На C# для WASM?

К сожалению, я играл в эти игры. … провисания игры на секунду-другую даже на самых топовых компьютерах…

Провисания важны покупателю. Продавцу важно, что товар приобретён, а он приобретён.

Видно уже куда паутинки сходятся?

А, все-таки модули есть, но никем не поддерживаются. Чудненько. Ждем больше таких стандартов.

Все стандарты так выходили: Например C++11 вышел в 2011, а gcc стал полностью поддерживать его с версии 4.8 которая вышла March 22, 2013.

С С++20 наоборот всё хорошо, возможно полностью будет поддержан уже в gcc 11, который выйдет весной 2021… Visual Studio 2019 тоже обещают добавить недостающую поддержку до конца года…

Roadmap:

H2 2020: Finish C++20.

H1 2021: Work on vNext. (We currently don’t know how much time we’ll have to work on vNext. Hopefully it will be more than 6 months.)

только на русском

окай.

// !!!АХТУНГ!!! примеры учебные! 

int divide(int a, int b){
    // вот тут необходимо выполнить проверку предусловия b!=0
}
...
int add(int a, int b){
    // вот тут мы должны убедиться, что при сложении
    // не произойдет переполнение целого. 
    // это проверка постусловия.
}
...
int mult(int a, int b){
    int result = 0;
    for(int i = 1; i <= b; i++){
        // вот тут мы проверяем инвариант - результат сложения не вызовет переполнение result.
        result += a;
    }
}
...

как обрабатывать ошибку - на усмотрение, потребности у всех разные.

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

Переход на сишные указатели = выход за стандартные методы

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

многим нужно чтобы работало, и побыстрее

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

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

Была то была, но когда она начала нормально работать с DirectX? Точных данных я не нашёл, но по отзывам до Delphi 5 (1999) проблемы были

Давай я задам другой вопрос: когда DirectX начала нормально работать и поддерживаться видеокартами? С этим вопросом сталкивался любой, кто играл в игры на первом Unreal Engine, который выпущен в 1998 году. DirectX использовался не потому, что был такой крутой, а потому что монополист рынка сфота для пек, Microsoft, тогда вендорлочил всех на свою ось.

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

Соответственно, нишу в создании игр паскаль потерял и двинулся в сторону документооборота, где уже Java всё захватывала

Я что-то пропустил: в какой момент жава захватила документооборот? Можно пример громких названий того времени?

Это не «тупо» маркетинг, а вынужденный маркетинг. И сравнение с мозиллой тут удачно. Вопрос: кто заставляет Java, у которой всегда лозунг был «тупо, но стабильно» ускорить процесс развития?

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

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

Есть большое число мудаков, которых хлебом не корми — дай поучаствовать в создании нового стандарта. Я не знаю, что конкретно ими движет, но я знаю, что они есть и их много. Вот посмотри на этот список:
https://isocpp.org/wiki/faq/wg21#herb-sutter
и ужаснись тому, сколько из этих людей в качестве заслуг имеют вахтерство/модерацию и самоотверженное сидение в комитетах.

Можно спорить о том, что вреда от комитетов больше, чем пользы, поскольку в результате мы имеем фактически реализации, отличающиеся в разной степени от стандарта — а какая тогда разница, со стандартом или без? Volatile придумали в сишке использовать до стандартизации, рано или поздно эта фича была бы принята во многих компиляторах. Однако, даже на фоне стандарта, MSVC все равно имел свою семантику volatile, потому что Microsoft в своих стенах собрал адекватов, которые прекрасно понимали, что комитет пишет какую-то лютую чушь и семантика volatile из стандарта абсолютно бесполезна — здесь даже нет фактора vendor-lock/монополизации, потому что в компиляторе был режим совместимости со стандартом. По сути стандартизация была попыткой найти некий общий знаменатель среди всех костылей в реализациях существовавших тогда компиляторов. Я подчеркиваю, что не «сделать грамотно», а «найти компромис среди всех плохих реализаций».

Я вообще думаю, что все адекватные челы уже давно забросили мысли о том, что «можно было бы поучаствовать в комитете» — они прекрасно понимают, что язык состоит из костылей и комитет только добавит новых костылей вместо решения проблем. Я до сих пор в шоке от того, какой кошмар приняли в первом ANSI SQL — хотя, казалось бы, у вас есть Oracle, есть Borland c Firebird, который был на то время тоже серьезным игроком — и все равно стандарт пишется с полным игнорированием многоверсионных СУБД.

К слову, потому опытные разрабы на крестах не спешат осваивать новые стандарты, а запасаются попкорном и ждут развития событий. Вот ввели модули в C++20 — а их до сих пор никто не поддерживает.

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

А была ли у adobe такая цель? Судя по действиям, похоже что цель была похоронить

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

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

Flash был более удобен мелким компаниям и одиночкам. Крупным компаниям это было не выгодно, ибо конкуренция. Вот и заменили. Дыры какие-то придумали. Как будто в другом ПО дыр нет. На что заменили? На TypeScript? На что заменят? На C# для WASM?

Flash был редкостным друшлагом — это факт. В этом плане он переплевывал все браузеры вместе взятые. Я уже написал, на что заменили Flash — на HTML5

К сожалению, я играл в эти игры. … провисания игры на секунду-другую даже на самых топовых компьютерах…

Провисания важны покупателю. Продавцу важно, что товар приобретён, а он приобретён

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

// вот тут мы проверяем инвариант - результат сложения не вызовет переполнение result

Это не инвариант, а вполне себе постусловие. Инвариантом в данном случае может являться кратность числу a или b, которая нарушается при переполнении.

Теперь напоминаю, о чем была речь:

Как ты можешь гарантировать, что никто нигде в тысячах блоков вызовов sdsnew/sdsfree не изменит указатель на строку?

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

Я не понимаю, при чем тут проверка при инициализации к безопасности операций языка. Язык Си дает изначально крайне опасные методы работы с данными, которых не было у кобола, не было у фортрана, хотя это более ранние языки, чем Си. C++ и паскаль могут дать 100% гарантию того, что при работе со строками стандартными методами ты никогда не получишь ошибку работы с памятью

А ты мне суешь какие-то переполнения чисел и деления на ноль. Контракт «управляющая ссылка на динамическую облатсь памяти не может изменяться» вполне себе реализуем в компиляторе без каких-либо сверхъестественных приемов и без проверок во время выполнения программы.

Переход на сишные указатели = выход за стандартные методы

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

Да, теоретически бибилотека могла бы реализовать некий абсолютно непрозрачный тип, которым нельзя было бы пользоваться как строкой, а только через соответствующие функции библиотеки, которые принимают этот конкретный тип строк. Проблема в том, что в Си нет средств для того, чтобы гарантировать, что никакая функция не нарушает этого правила. Допустим, ты сделаешь «typedef sds intptr_t», однако, какой-то неаккуратный програмист сделает «s1+s2» — и привет. Хуже всего то, что это не просто чтение, а и высвобождение памяти.

Даже если допустить, что мы как-то выдрессировали программистов, и все они на 100% избегают арифметики — как избежать ошибки работы с памятью при присвоении указателей на строки? Double-free — это самая популярная ошибка при работе с указателями. (update: конечно же, «use after free» — это самая популярная. Но и «double free» тоже достаточно востребована).

В итоге при работе с крестовыми или паскалевыми строками для безопасного выполнения мне ничего не нужно делать, а просто брать любые стандартные методы и код 100% будет работать безопасно, поскольку компилятор укажет на ошибку — а для Си нужно прекладывать неординарные уссилия для ручной проверки корректности операций, которая даст сбой, пусть даже один из тысячи раз — и что, мне от этого легче будет? Почему я и пишу, что с такими же успехами ты мог бы писать, что с sds-строками безопасно работать в ассемблере — главное, пользуйся только функциями библиотеки, и все будет в порядке. А то, что в базовом языке наблюдается полный угар и малейшее неаккуратное движение дает труднообнаруживаемую ошибку — это тебя почему-то не волнует. И нет, этой проблемы нет в крестах, где нужно прикладывать неординарные усилия просто для того, чтобы ошибку написать.

как избежать ошибки работы с памятью при присвоении указателей на строки? Double-free — это самая популярная ошибка при работе с указателями. (update: конечно же, «use after free» — это самая популярная. Но и «double free» тоже достаточно востребована).

Читать предупреждения компилятора?

и аннотировать каждую функцию, чтобы компилятор проверял всё что возможно при компиляции: https://docs.microsoft.com/en-us/cpp/code-quality/understanding-sal?view=vs-2019

https://gcc.godbolt.org/z/jK8769

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

Я и не говорю, что DirectX был крутой. Я говорю о том как душили конкурентов.

Я что-то пропустил: в какой момент жава захватила документооборот? Можно пример громких названий того времени?

Есть такой термин - Enterprise software (https://en.wikipedia.org/wiki/Enterprise_software). Возможно, я неверно его перевожу как «документооборот», но использовать английский не хотелось. Как правильно перевести? Насколько я знаю, Java всю жизнь в этой сфере находится. И громких названий тут трудно найти, ибо это закрытый софт, используемый внутри предприятий.

Вот посмотри на этот список: https://isocpp.org/wiki/faq/wg21#herb-sutter

Да. Правильная ссылка. На представителя Microsoft в комитете.

Однако, даже на фоне стандарта, MSVC все равно имел свою семантику volatile, потому что Microsoft в своих стенах собрал адекватов, которые прекрасно понимали, что комитет пишет какую-то лютую чушь…

Именно. Сами писали чушь в стандарт, потому и прекрасно понимали.

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

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

Flash был редкостным друшлагом — это факт. В этом плане он переплевывал все браузеры вместе взятые.

Я не помню, чтобы у Flash была такая репутация, когда он был Macromedia Flash.

Я уже написал, на что заменили Flash — на HTML5

Ну и как на HTML5 векторную графику рисовать? Где хранить библиотеку изображений? Где там мувиклипы и таймлайны?

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

Ответ на эту цитату в следующей цитате:

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

В итоге при работе с крестовыми или паскалевыми строками для безопасного выполнения мне ничего не нужно делать, а просто брать любые стандартные методы и код 100% будет работать безопасно, поскольку компилятор укажет на ошибку — а для Си нужно прекладывать неординарные уссилия для ручной проверки корректности операций, которая даст сбой, пусть даже один из тысячи раз — и что, мне от этого легче будет? Почему я и пишу, что с такими же успехами ты мог бы писать, что с sds-строками безопасно работать в ассемблере — главное, пользуйся только функциями библиотеки, и все будет в порядке. А то, что в базовом языке наблюдается полный угар и малейшее неаккуратное движение дает труднообнаруживаемую ошибку — это тебя почему-то не волнует. И нет, этой проблемы нет в крестах, где нужно прикладывать неординарные усилия просто для того, чтобы ошибку написать.

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

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

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

Си нет средств для того, чтобы гарантировать, что никакая функция

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

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

окай, о 100% безопасности крестов. воспроизведу ссылочку, для ленивых https://gcc.godbolt.org/z/a55j73 . никаких экстраординарных усилий я тут в упор не наблюдаю. на всякий случай пишу буквами - [] - это оператор. напрочь стандартный. туда никак нельзя было проверку выхода за перделы строки вкрячить? а пачиму? в поисках ответа на этот вопрос можно узнать много интересного.

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

[] - это оператор. напрочь стандартный. туда никак нельзя было проверку выхода за перделы строки вкрячить?

у всех контейнеров есть безопасный аналог [] - это метод at

https://gcc.godbolt.org/z/Mxz8fd

спс, я в курсе )

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

Что интересней строки вообще не являются контейнером, ну по крайней мере в С++ они не контейнер. Опять же, метод at() есть только у тех контейнеров которые поддерживают интерфейс random access, а таких контейнеров среди прочих не так уж много, больше как раз тех у которых этого at() нет, в виду специфики того, что они должны делать.

Инвариантом в данном случае может являться кратность числу a или b, которая нарушается при переполнении.

Лолшто.

2u * 1073741824u = 2147483648u =(при касте к signed int) -2147483648, что кратно и 2, и 1073741824

и аннотировать каждую функцию, чтобы компилятор проверял всё что возможно при компиляции: https://docs.microsoft.com/en-us/cpp/code-quality/understanding-sal?view=vs-2019

Да, аннотации — это интересный шаг вперед, но с довольно ограниченной применимостью.

https://gcc.godbolt.org/z/jK8769

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

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

Я и не говорю, что DirectX был крутой. Я говорю о том как душили конкурентов

Ну, и? В 1999 году у всех были проблемы с использованием DirectX, не только у борланда. О чем тогда разговор?

Есть такой термин - Enterprise software (https://en.wikipedia.org/wiki/Enterprise_software). Возможно, я неверно его перевожу как «документооборот», но использовать английский не хотелось

Наиболее точным переводом «enterprise software» на русский будет «лох, открывай кошель».

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

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

Ну и как на HTML5 векторную графику рисовать? Где хранить библиотеку изображений? Где там мувиклипы и таймлайны?

Векторная графика на SVG и жабоскрипте. Я плохо знаком с флешем, потому предполагаю, что мувиклипы и таймлайны делаются на <video>.

Я не помню, чтобы у Flash была такая репутация, когда он был Macromedia Flash

Бг-г-г, Macromedia Inc. — это другая фирма, которая была давно и неправда.

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

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

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

Здесь смешались в кучу конелюди. Кресты изначально предоставляют расширяемые инуструменты для создания безопасных абстракций, на основе которых уже сделано std. Паскаль содержит безопасные абстракции глубоко внутри компилятора, из которых торчит ограниченный набор символов, которые реализуются в каком-нибудь system.pas, и они весьма плохо расширяются.

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

Уже отвечал:

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

Также в другом треде я приводил пример этого самого «асма с типами»:

mov TComponent(ebx).FComponentStyle, eax

Си выполнял роль препроцессора для ассемблера, и в этой роли он был более-менее приемлим. Эта роль не подходит уже для написания небольших утилит/сервисов, которые оперируют более-менее сложными осмысленными данными, а не просто наборами байт, поскольку выдает либо глюкодром и друшлаги, либо требует неоправданных затрат ресурсов. Индустрия же тупо натянула сову на глобус — вот здесь я и делаю акцент. Оракл завалил проект ресурсами, поскольку уже был коммерчески успешным на момент модернизации и расширения системы. Microsoft тоже был коммерчески успешен во время расширения в сторону оконных систем, и первые 32-битные форточки таки были редкостным глюкодромом - спасибо Си за это. Позже высокоуровневый системный софт из винды мигрировал на кресты, а на Си осталось только ядро и отдельные системные софтины, под которые были выделены избыточное кол-во ресурсов и самые квалифицированные кодеры. Для сравнения, непожатое ядро седьмой винды весит 5 Мб, типовое непожатое ядро линя 2.6.32 — 9 Мб. Да, линь тоже заваливают избыточными ресурсами, но делают это на волонтерской основе.

И именно Microsoft в конце девяностых единолично занимался введением в Си безопасных функций работы со строками, которые до сих пор отсутствуют в GCC и Clang. Но эти меры — капля в море, чего только стоят неявные преобразования целых-вещественных чисел, даже в асме x86 были специальные явные инструкции для этого, а не просто «mov».

окай, о 100% безопасности крестов. воспроизведу ссылочку, для ленивых https://gcc.godbolt.org/z/a55j73 . никаких экстраординарных усилий я тут в упор не наблюдаю. на всякий случай пишу буквами - [] - это оператор. напрочь стандартный. туда никак нельзя было проверку выхода за перделы строки вкрячить? а пачиму? в поисках ответа на этот вопрос можно узнать много интересного.

    _NODISCARD reference operator[](const size_type _Off) noexcept /* strengthened */ {
#if _CONTAINER_DEBUG_LEVEL > 0
        _STL_VERIFY(_Off <= _Mypair._Myval2._Mysize, "string subscript out of range");
#endif // _CONTAINER_DEBUG_LEVEL > 0
        return _Mypair._Myval2._Myptr()[_Off];
    }

    _NODISCARD const_reference operator[](const size_type _Off) const noexcept /* strengthened */ {
#if _CONTAINER_DEBUG_LEVEL > 0
        _STL_VERIFY(_Off <= _Mypair._Myval2._Mysize, "string subscript out of range");
#endif // _CONTAINER_DEBUG_LEVEL > 0
        return _Mypair._Myval2._Myptr()[_Off];
    }

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

Стандарт не предусматривает конкретных действий для конкретно «operator[]», в стандарте есть еще куча недомолвок, которые дают карт бланш на кривые реализации std — здесь я спорить не буду.

2u * 1073741824u = 2147483648u =(при касте к signed int) -2147483648, что кратно и 2, и 1073741824

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

Частный случай же ж

…который опровергает твоё общее утверждение, ага. Как теперь ты его используешь для проверки переполнения?

расширяемые инуструменты для создания безопасных абстракций

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

Например?

Кстати по поводу Pascal VS C тех времен, у Кернигана была статейка в которой он бушевал по поводу того старого паскаля и приводил все свои негодования и претензии к той реализации, сейчас понятное дело многое из этого уже исправлено, но как контекст того почему все же у С оказался достаточный рукав времени чтобы захватить индустрию вполне сгодится. Датируется это все 1981 годом http://www.lysator.liu.se/c/bwk-on-pascal.html

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

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

Паскаль содержит безопасные абстракции глубоко внутри компилятора
Например?

Строки, динамические массивы, Variant. Это из более-менее старых, сейчас, конечно, в паскаль перекочевали шаблоны и контейнеры на них.

у Кернигана была статейка в которой он бушевал по поводу того старого паскаля и приводил все свои негодования и претензии к той реализации

Да, и эта статейка демонстрирует, что даже в 1981 году Керниган в упор не видел проблем Си и рассуждал с позиции «изобретено не нами». Это я про «There are no static variables and no initialization», «Some miscellaneous problems of type and scope» — вот этот пункт особо забавно выглядит на фоне совершенно бездарной реализации системы типов в Си и отсутствии проверки типов аргументов в функциях. Я не спорю, что паскаль того времени имел свои проблемы, которые вошли в список Кернигана, правда, давай не забывать, что на тот момент уже три года как существовала Модула-2, которая по сути была продолжением паскаля и в итоге идеи оттуда были «бэкпортированы» в реализации паскаля.

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

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

совершенно бездарной реализации системы типов в Си

ну так запили свою, одаренную, емое

https://godbolt.org/z/zz74oa

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

в релиз рантайме такая проверка типов ничего не стоит.

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

глубоко внутри компилятора Строки, динамические массивы, Variant.

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

https://raw.githubusercontent.com/graemeg/freepascal/2e3d36f4c0a3d63de8a30c8baec047ff87dc17ba/rtl/inc/dynarrh.inc

https://raw.githubusercontent.com/graemeg/freepascal/2e3d36f4c0a3d63de8a30c8baec047ff87dc17ba/rtl/inc/dynarr.inc

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

https://raw.githubusercontent.com/graemeg/freepascal/ff09069ca95dd43aac52d5d89c89cf0b23b985fe/rtl/inc/variant.inc

https://raw.githubusercontent.com/graemeg/freepascal/ff09069ca95dd43aac52d5d89c89cf0b23b985fe/rtl/inc/varianth.inc

Опять ртл, опять ничем не отличается от подхода с++

Выкидываем ртл получаем сишку. ЧТД.

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

Везде одна и та же история, никто не может оторваться от того факта, что придется скатиться в сишку на дне.

Это из более-менее старых, сейчас, конечно, в паскаль перекочевали шаблоны и контейнеры на них.

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

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

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

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

Наиболее точным переводом «enterprise software» на русский будет «лох, открывай кошель»… Бг-г-г…

Понятно. Вообще я все эти факты приводил, чтобы предугадать какой язык будет в лидерах через несколько лет. Но теперь понял, что это не совсем то, что мне надо. Важнее вопрос какой язык взять, если планируется, что проект будет жить и развиваться лет 20 или более. Соответственно, составил табличку с баллами (чем выше балл, тем надежнее; таблица на 2 столбца выглядит тут некрасиво, потому в виде кода):

|Ada	|5 |
|Go	|5 |
|Java	|7 |
|Python	|8 |
|CLisp	|13|
|Pascal	|13|
|BASIC	|19|
|Scheme	|20|
|Fortran|21|
|C++	|35|
|C	|47|

Другие языки имеют меньшие баллы. Если говорить отдельно о C++, то:

|C++11	|15|
|C++14	|12|
|C++17	|4 |

Методика очень грубая. Баллы зависят только от числа компиляторов (интерпретаторов) языка. Но это надёжнее, чем надеяться на мощь корпорации, которая завтра может исчезнуть или перестать поддерживать свой продукт. Ну и, если вспомнить о теме, в данном случае выгоднее, чтобы был и g++, и clang. Путь они даже медленнее будут развиваться.

Я так понимаю, clang - высер Яблочных, да забудится имя их, которым нужен был Objective-C, который никому кроме них на хрен ни разу не падал. Ну и не-GPL, чтобы продать. Я не понимаю, как вообще можно сравнивать кустарную подделку барыг с высоким искусством, да не узрят очи Столлмана этой предательской темы!

«немножко»

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

поэтому люди и пишут на Qt, да куда уж там, жаба и то сделана для людей, а не КамАЗов.

ну так запили свою, одаренную, емое
https://godbolt.org/z/zz74oa
типы чекаются в дебаге. не забывай покрывать юнит-тестами вызовы и будешь уверен, что типы передаются как надо

И делать проверки покрытия мне нужно руками — ну и что ты несешь? Всё в итоге сводится к тому, что программа будет работать настолько правильно, насколько человек будет мало ошибаться. А по мере роста проекта это становится делать сложнее и сложнее.

И нет, простая инструментальная фиксация покрытия не катит, потому что могут быть неявные вариации исполнения.

Строки и динамические массивы часть ртл, вариант скорее всего тоже

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

Опять ртл, опять ничем не отличается от подхода с++

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

Выкидываем ртл получаем сишку. ЧТД

Компилятор не может сгенерировать код без RTL:

https://wiki.freepascal.org/Minimal_RTL