Читая чужие исходники...

Потому что C-строка - это реализация, а string - ее абстракция.

Не единственная, и не совместимая напрямую с системными вызовами.

> Зачем юзать std::string только как контейнер, если, например, активно не юзаются конкатенация и поиск?

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

Прошу прощения, сэр, но Вы неправы!

Кресты великолепно подходят для разработки и внедрения пользовательского интерфейса, но пихать их именно в системное (т.е. программирование самой ОС, ее базового слоя) право не стоит. Ибо абстракция требует лишних операций.

Я тут, собственно, Бернштейном-то совсем не с бухты-барахты тролил. Он хоть и странен, хоть и в поделках его со студентами очень часто черт ногу сломит, но именно он около 10 лет назад показал миру опенсорсников, что и на классическом C можно писать безопасные и быстрые программы. За подробностями можно сходить к нему на сайт.

Да, по просьбам трудящихся - старпер, закончил универ скоро 20 лет как. Таким образом образование уже неактуально ;-).

закончил универ скоро 20 лет как. Таким образом образование уже неактуально

Я универ 9 лет назад закончил. Но большинство того, что там учил, забыл еще лет 7 назад ☺

Не согласен. Допустим, в критическом для производительности месте есть выбор между двумя алгоритмами (а в числодробилках таких мест много). Один пусть упирается в скорость доступа к памяти, другой - в оверхед на ветвления. Как правило, не так долго набросать очень базовую и неполную реализацию того и другого, и посмотреть, где неустранимые издержки больше. В CUDA, например, часто выясняется, что разница скоростей сразу будет процентов в 80, при этом устранение боттлнека в одном из алгоритмов чревато кучей костылей. Тогда уже можно сделать однозначный выбор.

А то! Классы-же.

Но ведь не пригодные для наследования.

Ибо абстракция требует лишних операций.

Вот С++ как раз позволяет минимизировать затраты на абстракцию и даже исключить их.

Вот С++ как раз позволяет минимизировать затраты на абстракцию и даже исключить их.

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

Also, Н. Вирт «Алгоритмы + структуры данных = программы»

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

Хотел было кое-что написать по мотивам ОП (свои соображения). Но потом прочёл вот это:

Давайте, перед тем как что-то писать здесь, каждый укажет, какое отношение он имеет к программированию: есть ли диплом (или пока только зачётка) профильного ВУЗа, призы на олимпиадах по программированию и т.д.

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

Поэтому по теме решил не писать, дабы не испортить «мнение».

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

Список литературы, пожалуйста.

перегружаемые операции

Я правильно понимаю, что имелись в виду виртуальные функции? Мы говорим о С++, а не о Java или C#.

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

Список литературы, пожалуйста.

Лады. Поищу в понедельник. Давно про это читал - искать опять надо.

что имелись в виду виртуальные функции?

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

Поэтому по теме решил не писать, дабы не испортить «мнение».

Эт да! Письками меряться ;-)

ОК, к числодробилкам это не относится. В «гражданском» софте выбор алгоритма часто можно сделать до реализации, а применение заведомо более сложного алгоритма (например, квадратичного вместо линейного) - это преждевременная пессимизация

Т.е. на крестах надо писать шаблонами?

Стандартную библиотеку С++ видел?

А смысл в них тогда какой если вся прелесть наследования/перегрузки отваливается?

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

Не нужно, а можно. И потом, ещё раз, в 99% кода оверхед на вызовы виртуальных функций будет незаметен. Единственные места, где нужно экономить на спичках - внутри двойных-тройных циклов (т.е. везде, где код вызывается много раз). А там уже можно расстараться, даже заинлайнить что-нибудь.

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

Лады. Поищу в понедельник. Давно про это читал - искать опять надо.

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

dmfd Begemoth.

Почти убедили, что и на крестах тоже МОЖНО писать хорошо оптимизированные программы, если знать КАК. (Про новую реализацию шаблонов прочитал - впечатлило. Раньше было много хуже.)

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

Т.е. можно не искать про реализацию классов, перегрузку и проч?

У меня то же самое. Только все тонкие места отделены и написаны максимум с использованием шаблонов, самые тонкие места - с помощью препроцессорной магии (про отлетающие оптимизации я говорил на основании печального опыта). Зато весь интерфейс для работы с этими алгоритмами - приятный лаконичный ООП.

Кресты великолепно подходят для разработки и внедрения пользовательского интерфейса, но пихать их именно в системное (т.е. программирование самой ОС, ее базового слоя) право не стоит. Ибо абстракция требует лишних операций.

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

Я тут, собственно, Бернштейном-то совсем не с бухты-барахты тролил. Он хоть и странен, хоть и в поделках его со студентами очень часто черт ногу сломит, но именно он около 10 лет назад показал миру опенсорсников, что и на классическом C можно писать безопасные и быстрые программы.

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

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

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

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

P.S. Кстати, прототипирование алгоритма на каком-нибудь мэпле или хаскелле впоследствии сильно экономит время.

верно, это уних там, а у нас нормальная бинарная система

имеется в виду не винда

Почему автор пишет все сам, когда есть готовые библиотеки?

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

Да напиши, пожалуйста, по «чужие исходники». (Это молодежь «письками мериться» любит в виде кто больше олимпиад и у кого образование круче. Я написал - у меня оно уже заржавело давно. ;-) )

Чужое мнение - оно не ради трепа только. Оно собственное представление расширяет.

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

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

Расширю про свой быдлокод для пояснения: я рабочий интерфейс на быдлоскриптах пишу - так быстрее писать. А вот вычислительное ядро (через межпроцессное взаимодействие или вызовами) - голый C.

Такова специфика работы. Да и переносимость важна.

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

спасибо за совет. но... мимо кассы. IRL я применяю библиотечные модули в коммерческих проектах. И заставить меня применять велосипеды могут лишь ОЧЕНЬ веские обстоятельства. Я и без вас в курсе, что на меня ложится бремя поддержки данного велосипеда. Учтите, я ещё не впал в маразм, что-бы «лепить ASCIIZ строки на уровень данных», на том уровне тоже что-то вроде STL, только моя реализация, заточенная под данный конкретный случай.

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

ну у меня в ТЗ прописано время. Если программа «думает» в течении 30и секунд, заказчик не ждёт, а просто пишет багрепорт: «программа зависла». Всё, точка. И то, что на 31й секунде программа наконец разродилась - его не волнует. А если 15 секунд думает, то пишет: «программа тупит». ВСЁ. И ничего с этим не поделать. У конкурентов данное действие выполняется мгновенно, а значит:
1. я дебил, и мне надо доделовать/переделовать код.
2. у конкурентов более простая задача - придётся это аргументированно доказать.
3. у конкурентов более мощное железо/каналы связи. Это тоже приходится доказывать, что я не волшебник
Вот и всё, в реальной жизни...

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

куча говна из указателей исключительно в вашей голове. Я не собираюсь вводить например в код на плюсах строчки из C непосредственно, я сделаю няшную ООПшную обёртку, где-то в глубине которой будут эти строчки. Об этом другие кодеры даже и не догадаются, если в исходники не заглянут. И не догадаются также и в том случае, если я ВНЕЗАПНО сменю представление строк из ASCIIZ, в стиль паскаля - буду хранить их длину явно. Им-то какая разница? Разве что скорость получения длинны строки станет постоянной, и не зависящей от длинны строки. (вот только зачем им длинна внутреннего представления? им максимум надо число символов, а число символов в этом веке так просто не получается, ибо один символ может занимать 1, 2, 3, и даже больше байт. И для его получения необходимо расковырять всю строку)

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

... а ещё возможность реализовать строку содержащую нулевой символ. strcpy который заранее знает сколько надо скопировать. Отличную производительность strlen. И ещё кучу других плюшек. Иногда положительных, иногда отрицательных.

Возьмем пример, который я поглядел ZoneMinder. Там чужих можно было использовать: 1 - Работа с сетью, например, более высокоуровневые либы нежели чем простые сокеты. 2. Работа с детектором движения, например использовать OpenCV, нежели чем писать свой самокат. 3. Работа с RTSP - опять же, есть аналоги.

Это только поверхностно.

Использование чужих (и как правило более отлаженных библиотек) позволяет - упростить свой код (уменьшить количество кода в программе), снизить количество потенциальных ошибок. Конечно, тащить в проект например Qt или Boost ради одноразовой отправки десяти байт по сети - это излишество.

... а ещё возможность реализовать строку содержащую нулевой символ.

а оно надо?

strcpy который заранее знает сколько надо скопировать.

что быстрее: while(*d++ = *s++); или size_t min_len = len_d < len_s ? len_d : len_s; for(size_t i = 0; i < min_len; i++) d = s;

Отличную производительность strlen.

зачем?

И ещё кучу других плюшек.

ага. например strcmp будет работать в разы медленнее.

Есть диплом программиста и стаж работы по написанию какой-нибудь системы учёта удоев козьего молока - человек формально профессиональный программист.

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

> указателей на строки с нулевым терминатором
А что, есть вариант по-другому строки организовать?

std::string, std::vector, pascal string.

Места больше же!

Места больше же!

По сравнению с размером данных? :)

А енто ужо смотря какого размера данные… У кого-то строки и по тысчюююю символов бывают, а кто-то просто «рузский езыг» помнит…