[prog.c++] std::string и совместимость с C

Возможно, я ошибаюсь, но думается, что единственный толковый способ обеспечить в реализации std::string эффективную работу методов data() и c_str() -- это хранить в std::string всего один буфер, размер которого больше длины строки хотя бы на один символ. Чтобы в этом "хвостике" держать 0-символ, необходимый для c_str().

Получается, что если мне нужно хранить в программе 3M объектов std::string, то эти самые 0-символы будут съедать 3MiB RAM. Что несколько обидно в случаях, когда ни одна их этих строк для C-шных вызовов не используется.

Понятно, что в процентном отношении эти накладные расходы невелики, даже в 32-битовом коде, и они еще меньше в 64-битовом... Но все равно обидно :)

[prog.flame] Прочел тут прекрасное на тему непризнанных индустрией средств борьбы со сложностью

Сперва на глаза попалось вот это. Буквально на следующий день -- вот это. На мой взгляд, авторы обоих опусов стенают об одном и том же: ну вот есть же классные средства борьбы со сложностью, ну есть же. Только вот клята индустрия как сидела на старых и допотопных инструментах, так и сидит. И в упор не принимает продвинутых инструментов с высоким уровнем абстракций. В общем, не хотят массы писать на нормальных языках, сидят, редиски, на С и C++. Ну в лучшем случае на какой-нибудь убогой Scala. Нет, чтобы взять Хаскелль или Кложу...

А мне вот вспоминается 1995-й год. 486-й компьютер, с тактовой частотой 40MHz, 4MiB RAM. Windows 3.11, 150-ти страничный документ в Word 6.0. Нормально редактируется, разве что проверку орфографии приходится отключать. 16-битовое приложение, в 16-битовой ОС.

Для тех, кто не понял: всего четыре(!) мегабайта памяти и всего сорок мегагерц. И 16-битовый код.

К чему этот пример? К тому, что уровни абстракции -- это хорошо. Только эти уровни далеко не бесплатны. А вычислительные мощности за 20 лет, хоть и выросли, но бесконечными не стали. Посему, написанные на языках с высокими уровнями абстракции приложения тормозят даже на современном железе. А уж на железе 20-летней давности не смогли бы запуститься вообще. И уж не знаю, что здесь первично: накладные расходы на эти самые уровни абстракции, или же особенность мышления нового поколения разработчиков, избалованных безопасными языками и менеджед-средами. Но на практике все оказывается очень просто: как только сталкиваешься с ограничениями по железу, так сразу же абстракции, у которых не хватает ручек для полноценного управления и тонкой настройки, идут в жопу.

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

---

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

[prog.c++] Вакансия для опытного C++ника в Минске

Знакомый попросил помочь с анонсом вакансии для опытного C++ника в Минске, что с удовольствием и делаю.

Итак, официальное описание на tut.by, там же координаты официального контактного лица.

С неофициальными вопросами можно обращаться к ув.тов.Anatoly “Aen Sidhe” Popov.

Мопед, к сожалению, не мой, я только дал объяву :) Но, вроде как проект должен быть интересным. Пусть потенциальных соискателей обилие .Net-а в списке технологий не смущает. Ищется С++разработчик под Linux, для реализации нагруженного Web-а.

Upd. Важное дополнение из комментариев (специально для тех, кого может смущать название BelitSoft):

Мне тут рассказали, что BelitSoft пользуется дурной славой в мире IT Белоруссии (я сам из РФ, поэтому не сильно в курсе).

Так вот, мы достаточно автономны внутри Belitsoft, не занимаемся их основными продуктами и работаем над своими двумя продуктами. У нас тут всё хорошо в плане процессов, качества и всякое такое.

Так что, если есть желание - ждём.