Здравствуйте, Cyberax, Вы писали:

C>3. Делаем так:
C>

C>struct B
C>{
C>    int a;
C>    std::basic_string<char,shmem_allocator<char> > b,c;
C>};
C>

C>Теперь внутренний буффер std::string будет распологаться в shared
C>memory/file mapping'е.

Да фиг там. Если длина строки не больше 32-х/16-ти байт (в зависимости от реализации), то большинство из них дежат эти значения в локальном буфере.

Тогда уж надо сделать что-то типа NullTerminatedAdapter на основе std::vector.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Cyberax, Вы писали:

C>>3. Делаем так:
C>>

C>>struct B
C>>{
C>>    int a;
C>>    std::basic_string<char,shmem_allocator<char> > b,c;
C>>};
C>>

C>>Теперь внутренний буффер std::string будет распологаться в shared
C>>memory/file mapping'е.

V>Да фиг там. Если длина строки не больше 32-х/16-ти байт (в зависимости от реализации), то большинство из них дежат эти значения в локальном буфере.

Саму строку (в данном случае всю структуру) нужно аллоцировать этим же аллокатором. Тогда всё нормально будет.

vdimas wrote:
> C>Теперь внутренний буффер std::string будет распологаться в shared
> C>memory/file mapping'е.
> Да фиг там. Если длина строки не больше 32-х/16-ти байт (в зависимости
> от реализации), то большинство из них дежат эти значения в локальном буфере.
Сама структура тоже создается этим же аллокатором.

Здравствуйте, alexeiz, Вы писали:


V>>Да фиг там. Если длина строки не больше 32-х/16-ти байт (в зависимости от реализации), то большинство из них дежат эти значения в локальном буфере.

A>Саму строку (в данном случае всю структуру) нужно аллоцировать этим же аллокатором. Тогда всё нормально будет.

Это значит надо наследовать от std::basic_string и переопределять операторы new/delete? А заодно еще около 20-ти конструкторов???

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, alexeiz, Вы писали:


V>>>Да фиг там. Если длина строки не больше 32-х/16-ти байт (в зависимости от реализации), то большинство из них дежат эти значения в локальном буфере.

A>>Саму строку (в данном случае всю структуру) нужно аллоцировать этим же аллокатором. Тогда всё нормально будет.

V>Это значит надо наследовать от std::basic_string и переопределять операторы new/delete? А заодно еще около 20-ти конструкторов???

Зачем же так сразу. Просто используешь аллокатор напрямую:

typedef std::basic_string<char,shmem_allocator<char>> sh_string;
typedef sh_string::allocator::rebind<B>::other b_allocator;

//  TODO: add exception handling
B * construct_from(B const & val) {
    b_allocator alloc;
    B * obj = alloc.allocate(1);
    alloc.construct(obj, val);
    return obj;
}

void destroy(B * obj) {
    b_allocator alloc;
    alloc.destroy(obj);
    alloc.deallocate(obj, 1);
}

Здравствуйте, alexeiz, Вы писали:


A>Зачем же так сразу. Просто используешь аллокатор напрямую:
[skip]

Напрямую можно еще проще через inplace new, стиль мне не нравится. Если бы уж прижало, то я бы скорее переопределил пару десятков конструкторов std::basic_string но сохранил читабельность.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, alexeiz, Вы писали:


A>>Зачем же так сразу. Просто используешь аллокатор напрямую:
V>[skip]

V>Напрямую можно еще проще через inplace new,

Да, так даже лучше.

> стиль мне не нравится. Если бы уж прижало, то я бы скорее переопределил пару десятков конструкторов std::basic_string но сохранил читабельность.

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

Здравствуйте, alexeiz, Вы писали:


A>>>Зачем же так сразу. Просто используешь аллокатор напрямую:
V>>[skip]

V>>Напрямую можно еще проще через inplace new,

A>Да, так даже лучше.

не совсем, ниже поясню

>> стиль мне не нравится. Если бы уж прижало, то я бы скорее переопределил пару десятков конструкторов std::basic_string но сохранил читабельность.

A>Зачем переопределять конструкторы? Ты же только память в другом месте аллоцируешь, а функциональность конструкторов у тебя остаётся такой же. Ну, допустим, ты унаследовал от basic_string, где в конструкторах наследуемого класса ты собрался использовать аллокатор?

Я же сказал в позапрошлом посте, что надо переопределить для типа оператор new. Для std::basic_string его переопределить неудасться, значит, надо переопределить его для своего наследника.

Inplace new мне не нравится по причине банальной: "двухтактная инициализация", невозможность использования в функциональном стиле.

Здравствуйте, Зверёк Харьковский, Вы писали.

коллега, по-моему это примерно тоже самое что говорить мол, русский язык плохой, потому что он допускает конструкции вида "я вашу маму [sensored]" и "да ты козел необразованный". язык только предоставляет возможности, а как вы ими воспользуетесь — это уже ваши проблемы.

Здравствуйте, Leonid V. Volnin, Вы писали:

LVV>Здравствуйте, Зверёк Харьковский, Вы писали.

LVV>коллега, по-моему это примерно тоже самое что говорить мол, русский язык плохой, потому что он допускает конструкции вида "я вашу маму [sensored]" и "да ты козел необразованный". язык только предоставляет возможности, а как вы ими воспользуетесь — это уже ваши проблемы.

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

Здравствуйте, dshe, Вы писали:

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

А как же тогда известная песня в исполнении В.Леонтьева:

...Каждый хочет иметь и невесту, и друга...

А ведь казалось бы, совершенно безобидный текст.

Здравствуйте, dshe, Вы писали:

D>Здравствуйте, Leonid V. Volnin, Вы писали:

LVV>>Здравствуйте, Зверёк Харьковский, Вы писали.

LVV>>коллега, по-моему это примерно тоже самое что говорить мол, русский язык плохой, потому что он допускает конструкции вида "я вашу маму [sensored]" и "да ты козел необразованный". язык только предоставляет возможности, а как вы ими воспользуетесь — это уже ваши проблемы.

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

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

vdimas wrote:
> A>Саму строку (в данном случае всю структуру) нужно аллоцировать этим же
> аллокатором. Тогда всё нормально будет.
> Это значит надо наследовать от std::basic_string и переопределять
> операторы new/delete? А заодно еще около 20-ти конструкторов???
Зачем же так грубо, выглядит примерно так:

const ShmemAllocator alloc_inst(segment.get_segment_manager());

typedef std::string<char,std::char_traits<char>,
    ShmemAllocator> MyString;

MyString *str=segment.construct<MyString>("OptionalObjectName")
    (alloc_inst);
//Конструктор std::string с одним параметром-аллокатором

MyString *str2=segment.construct<MyString>("OptionalObjectName")
    ('a',11,alloc_inst);

Здравствуйте, Leonid V. Volnin, Вы писали:

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

LVV>ну дык разве это не так?
LVV>не все же люди могут следить за своей речью, многие сначала говорят, а потом думают.
LVV>в результате именно так и получается. так что сомнений нет — русский язык плохой

Что ж, даже в естественных языках нет совершенства.

Здравствуйте, Leonid V. Volnin, Вы писали:

LVV>коллега, по-моему это примерно тоже самое что говорить мол, русский язык плохой, потому что он допускает конструкции вида "я вашу маму [sensored]" и "да ты козел необразованный". язык только предоставляет возможности, а как вы ими воспользуетесь — это уже ваши проблемы.

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Leonid V. Volnin, Вы писали:

LVV>>коллега, по-моему это примерно тоже самое что говорить мол, русский язык плохой, потому что он допускает конструкции вида "я вашу маму [sensored]" и "да ты козел необразованный". язык только предоставляет возможности, а как вы ими воспользуетесь — это уже ваши проблемы.

VD>Некорректная анлогия. ЯП и разговорные языки сильно отличаются.
VD>ЯП скорее корректнее сравнивать с инструментами. Если есть безопасный инструмент позволяющие выполнить работу приметно так же эффективно как и опасным, то разумный человек скорее выберет безопасный.

черт его знает. с инструментами сравнивать скучно :) не ассоциируются у меня языки программирования с инструментами.
с инструментами можно сравнить вспомогательные библиотеки наверное. SDK какое-нибудь. IDE пожалуй можно. но язык программирования?.. язык программирования это тогда уж скорее способ работы с инструментами.
но здесь я аналогию еще не придумал :)

Здравствуйте, igna, Вы писали:

I>Здравствуйте, Cyberax, Вы писали:

C>>last_hardcoder wrote:
>>> приемника C++
C>>Это как "приемник Путина"?

I>

Он его ночами крутит, ловит, контра, ФРГ. (C)

Ага!

Приёмник — это девайс такой.
Преемник — это тот, кто "преемлет" мою должность после меня. Преемственность у нас.

Здравствуйте, Left2, Вы писали:

L>Не ссорьтесь, горячие парни Решается всё просто — ставите себе debug symbols и смотрите на имена функций. Статистику не мерял, но "на глаз" в XP процентов 80-90 кода на С++.

MS переписал код с "кустарного C" на C, который можно без проблем прогнать через рядовой С++ компилятор.
В частности объявления в стиле K&R были заменены на ANSI-шные.

D>MS переписал код с "кустарного C" на C, который можно без проблем прогнать через рядовой С++ компилятор.
D>В частности объявления в стиле K&R были заменены на ANSI-шные.

Не совсем понял что значит "C, который можно без проблем прогнать через рядовой С++ компилятор". Насколько я видел — в call-stack большинство вызываемых функций являются членами классов. Я конечно в pure C не силён, но насколько я знаю он member-функций не поддерживает.

Здравствуйте, Left2, Вы писали:

D>>MS переписал код с "кустарного C" на C, который можно без проблем прогнать через рядовой С++ компилятор.
D>>В частности объявления в стиле K&R были заменены на ANSI-шные.

L>... Насколько я видел — в call-stack большинство вызываемых функций являются членами классов...

Во первых стоит уточнить о каких “80-90% кода XP“ шла речь.
Ядро, API, базовые библиотеки и сервисы сделаны на C, просто были переработаны и адаптированы на подмножество, которое нормально поддерживается стандартом C++.

Далее немалая часть кода переведена с C на C++ почти машинным способом (наглядный пример фрагменты MFC).

Имели (C):

struct HDC;
void Proc(HDC hdc, …);

Получили (C++):

class CDC
{
    …
    void Proc(…)
}

В принципе разница только в том, что (для MS-компиляторов) указатель на объект/структуру будет передан через регистр (как правило ECX). Назвать это C++ можно с большой натяжкой.

Поэтому заявление: “… процентов 80-90 кода на С++”, стоило бы заменить на “процентов 80-90 пародии на C++”.