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

_>>>Зачем? Подобный код в плюсах не имеет смысла.
_>>>Получится что-то вроде :
Нет не получится. Объяснить почему?
_>>>

_>>>    int a = 0;
_>>>    int c = 10;
_>>>    int b = 0;
_>>>    (*(&b)) = ( &a == NULL ? *(&a) : c) / 100;
_>>>

S>>Это не эквивалентный код.
_>Хорошо. Измените сами по вкусу .
_>Зачем мне такой код ? Какой нибудь толковый пример есть?

Этот пример такой же толковый, как и любой другой. Что Вам показать? Работу с nullable типами, хранимыми в СУБД крупной enterprise системы? Так тут боюсь С++ вообще загнется (точнее не С++, а программист, которуму так (не)повезет).

K>алгоритмическая сложность та же

Нужно, впрочем, заметить, что это в худшем случае.

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

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

K>>>Ну и чем может быть спровоцировано такое непонимание? Для добавления последовательности в начало нужно заменить 0 узлов. И создать 1 новый узел. Сложность O(1). При этом доступ по индексу будет с логарифмическим.
S>> Если речь идет об иммутабельной структуре, то придется создать новые узлы от вершины до модифицируемого узла, модифицируя в том числе и суммарные длины в подветках.
S>>Сложность будет равна сложности поиска.

K>Это для вставки. А не для добавления к началу/концу т.е. конкатенации.
Может я чего то не понимаю — В чем разница? Так структура мутабельна мы должны выделить новыю ссылку на корень,и от него добраться либо в конец либо в начало,
выделяя новую ветку, с модификациу длины?

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

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

S>>Нет, не надо. Читать RTFM про то, как работает GC. Он не занимается уборкой.

PD>Уборкой или не уборкой, но исследованием кучи он занимаетеся или нет ? И время на это исследование от числа объектов там зависит или тоже нет ?

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

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

C> _itoa_s(i,buffer,10);
C> temp = buffer;
C> ws.append(StringToWString(temp));

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

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

itow спасет отца русской демократии.

wchar_t * _itow(
   int value,
   wchar_t *string,
   int radix 
);

На С++ говоришь несколько лет прогил, да?
Ну ну...

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

Кстати мутабельная реализация. http://rsdn.ru/article/cpp/segmented_list.xml

Автор(ы): Алексей Семенюк
Дата: 31.10.2004
В статье приводится пример реализации нестандартного контейнера, позволяющего обеспечить приемлемую скорость доступа к произвольному элементу и вставки/удаления в произвольную позицию.

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

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

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

PD>>>Просто R/O секцию. Создается в C++ #pragma dataseg(имя). Ей можно поставить атрибуты без W. Некая функция (конструктор констант , получив ее базовый адрес, ставит разрешение по записи, записывает, снимает опять. А что и как там хранить — предмет отдельного разговора. Например, куча константных объектов, которые можно туда добавлять и оттуда удалять (эти методы могут снимать защиту), но функции их изменения получат exception просто по защите на уровне процессора, так как снимать защиту не умеют.

G>>Выделенное — дикий оверхед, оптимизацей в таком случае и не пахнет.

PD>Не особенно такой уж дикий. Все зависит от того, где и как это применять.
Смена атрибутов доступа к странице памяти заставляет проваливаться в ядро, это очень большой оверхед независимо от того где применять.

G>>Оно нафиг не нужно, если неизменяемость доказана компилятором из системы типов.
PD>Да, но оно позволяет иметь неизменяемость независимо от типа .
А теперь докажи преимущества такого подхода перед формальным доказательством неизменяемости.
Учти также что формальное доказательство дает огромный простор для оптимизации, в отличе от runtime проверок.

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

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

_>>>>Зачем? Подобный код в плюсах не имеет смысла.
_>>>>Получится что-то вроде :
C>Нет не получится. Объяснить почему?
_>>>>

_>>>>    int a = 0;
_>>>>    int c = 10;
_>>>>    int b = 0;
_>>>>    (*(&b)) = ( &a == NULL ? *(&a) : c) / 100;
_>>>>

S>>>Это не эквивалентный код.
_>>Хорошо. Измените сами по вкусу .
_>>Зачем мне такой код ? Какой нибудь толковый пример есть?

C>Этот пример такой же толковый, как и любой другой. Что Вам показать? Работу с nullable типами, хранимыми в СУБД крупной enterprise системы? Так тут боюсь С++ вообще загнется (точнее не С++, а программист, которуму так (не)повезет).
Не, из этого примера ничего не понятно. Пусть это в СУБД полезно, еще что нибудь? Почему я собственно не могу указатели на ноль проверять?
Ведь согласно MSDN

A nullable type can represent the correct range of values for its underlying value type, plus an additional null value.

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

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

C>> _itoa_s(i,buffer,10);
C>> temp = buffer;
C>> ws.append(StringToWString(temp));

C>>Про сложность кода и явную костыльность С++ (обратите внимание как пришлось извратиться, чтоб сконвертировать число в wstring там, где StringBuilder делает конвертацию сам и не парит нам мозги) и говорить не стоит — вся красота перед глазами.
CC> Ай хорошо!
CC>Прекрасный пример!

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

CC>itow спасет отца русской демократии.
798 ms — ноздря в ноздрю. Кроме того, что С# вариант на много проще и не требует явного вызова функции конвертации.

CC>

CC>wchar_t * _itow(
CC>   int value,
CC>   wchar_t *string,
CC>   int radix 
CC>);
CC>

CC>На С++ говоришь несколько лет прогил, да?
CC>Ну ну...

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

Так что с replace? Будет вменяемый пример?

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

_>И как же программисты С++ до сих пор не загнулись при работе с enterprise системами?
Загнулись. Потому 99% enterprise это Java и .NET

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


C>> _itoa_s(i,buffer,10);
C>> temp = buffer;
C>> ws.append(StringToWString(temp));

C>>Про сложность кода и явную костыльность С++ (обратите внимание как пришлось извратиться, чтоб сконвертировать число в wstring там, где StringBuilder делает конвертацию сам и не парит нам мозги) и говорить не стоит — вся красота перед глазами.
CC> Ай хорошо!
CC>Прекрасный пример!

Кстати, С++ вариант по прежнему падает, если count >= 10000

Прекрасный пример — тут Вы правы.

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

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

_>>И как же программисты С++ до сих пор не загнулись при работе с enterprise системами?
C>Загнулись. Потому 99% enterprise это Java и .NET
Насчет Jаva соглашусь. А пример широко известной дотнет enterprise системы ( ну там CRM — ЕRP какой-нибудь)?

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

C>Кроме того, что С# вариант на много проще и не требует явного вызова функции конвертации.
Да не особо там разницы. Просто в шарпе натыкано хелперов-конверторов.
Есть у меня на одном проекте либа, на которой все основано. С ее использованием тоже получится чисто по коду "на много проще и не требует явного вызова функции конвертации".
Так что это в принципе мелочи.

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

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

G>Смена атрибутов доступа к странице памяти заставляет проваливаться в ядро, это очень большой оверхед независимо от того где применять.

См. мой ответ выше.

G>Учти также что формальное доказательство дает огромный простор для оптимизации, в отличе от runtime проверок.

Пойми наконец, что никакой проверки не будет вообще.

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

G>>Учти также что формальное доказательство дает огромный простор для оптимизации, в отличе от runtime проверок.
PD>Пойми наконец, что никакой проверки не будет вообще.
Ага, процессор магическим образом будет узнавать куда писать не надо.

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

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

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

_>>>И как же программисты С++ до сих пор не загнулись при работе с enterprise системами?
C>>Загнулись. Потому 99% enterprise это Java и .NET
_>Насчет Jаva соглашусь. А пример широко известной дотнет enterprise системы ( ну там CRM — ЕRP какой-нибудь)?

Sharepoint, Dynamics

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

C>>Кроме того, что С# вариант на много проще и не требует явного вызова функции конвертации.
CC>Да не особо там разницы. Просто в шарпе натыкано хелперов-конверторов.
CC>Есть у меня на одном проекте либа, на которой все основано. С ее использованием тоже получится чисто по коду "на много проще и не требует явного вызова функции конвертации".
CC>Так что это в принципе мелочи.

Когда таких мелочей — миллион — это становится сущей головной болью. Хорошо, что у Вас есть либа, а что делать тому, кто читает Ваш код? Лазать в либу и еще ее читать?

C>>На С++ я не программировал уже ой как много лет. Так что забыл больше, чем многие из здесь присутствующих плюсистов когда-либо знали.
CC>Ну хоть как MSDNом пользоваться не забывай.
Вот-вот. Почему-то с С# на такой банальщине не приходится "пользоваться MSDN".

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

S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Хм... Что такое ссылки наружу — я не знаю, а вот про блоки памяти вроде Рихтер говорит, что он их просматривает, ну и дальше — что именно делает.
S>Объект может содержать в себе ссылки, а может не содержать. В отличие от С++/native, про все объекты заранее известно, есть ли в них ссылки. В строках — нет. Поэтому "просматривать" их не нужно.

Так Рихтер все же прав или нет — насчет просмотра блоков ?

S>Это тебе ясно исключительно потому, что ты провёл сотни экспериментов с С++.

Нет . Я вообще довольно долго писал на Паскале (не Дельфи) под ДОС. И все, что я там знал, я перенес сюда. Свойства алгоритмов и работы с памятью не зависят от языка, если это native код.

>Теперь тебе сразу видно — где стоит поменять алгоритм, где заменить аллокатор, а где сразу нужно переходить на MMX и прочую низкоуровневую химию. Для новичка С++ — точно такая же непредсказуемая штука. Типа поставил где-то в неочевидном месте слово const — бах, сразу скорость подпрыгнула на 20%. Почему, отчего — хрен поймешь. Потому что не все могут выполнять в уме частичную специализацию и определять на глаз, где компилятор сможет выкинуть конструктор копирования временного экземпляра.

Поменять алгоритм — да, но это от языка не зависит.
Аллокатор — частично согласен.
Хрен поймешь — не согласен, есть Disassembly
Копировать без надобноси не надо , и такие конструкции лучше вообще употреблять с осторожностью. Но для этого надо видеть, во что твой код примерно превратится. Без просмотра ассемблерного кода. Просто в уме понимать

PD>>Все так или иначе документировано и от наличия или отсутствия опыта у меня не очень зависит.
S>Это неправда.

Это твое ИМХО, не более.

PD>>Нашел bottleneck — определи суть — больше так не делай.
S>Это неправда.

Тжс.

PD>>Не потому, что профайлер показал его, а по определенной сути.
S>Это неправда.

Туда же.
PD>>В принципе я мог бы и без профалера эту суть найти, просто анализом, медленнее, конечно, будет.
S>Анализом? Это каким? Ну-ка, ну-ка, покажи мне способ при помощи "анализа" за конечное время выяснить, где порылась собака в быстродействии программы на основе того же boost::lambda?

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



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

Это тебе и кое-кому еще кажется, что это так. Профайлер лишь говорит о том, что есть, но ни слова не скажет о том, что могло бы быть. Вот тебе пример. Подсчет числа счастливых билетов. Тупо — 6-кратный цикл. Немного подумать — пятикратный. Еще подумать — тройной. А, оказывается, есть просто формула, без всяких циклов. Ну вот написал некий программист 6-цикл , видит, что все время уходит на... и что дальше ?
И я если бы использовал плохую структуру данных, был бы обречен на то, чтобы улучшать работу с ней ( и возможно улучшил бы на 10-20%), вместо того, чтобы выбрать адекватную и получить ускорение в разы.


>Тот же SQL Server — есть масса факторов, влияющих на производительность запросов.

SQL — это тоже "управляемый" язык, так что здесь верно то же, что и для .Net. Но к программированию на уровне "я точно знаю, какие команды процессора у меня выполняются (даже если писалось не на асме)" это не относится.

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

C>Так что там с Replace? Мы увидим тест для replace внутри wstring`а, который бы отрабатывал по времени примерно столько же, сколько отрабатывал тест на append? Слабо?
А что не так с алгоритмом replace ?

       DWORD t1 = ::GetTickCount();
    wchar_t* buf = new wchar_t [200000000]; 
    std::wstring str1 ;
    wchar_t s[] = L"c1";
    for(size_t i = 0; i < 200000000; )
    {        
        _tcscpy(&(buf[i]),s);
        i+= _tcslen(s);
    }
    str1 = buf;

    DWORD dif_tim = ::GetTickCount() - t1;

    std::cout << "append: elapsed: " << dif_tim <<" millisecond"<< std::endl;
    std::cout << str1.length() << std::endl;

    t1 = ::GetTickCount();
    std::replace(buf, buf + _tcslen(buf)  , L'1', L'2');

    dif_tim = ::GetTickCount() - t1;
    std::cout << "replace (wchar array) : elapsed  : " << dif_tim <<" millisecond"<< std::endl;

    t1 = ::GetTickCount();
    std::replace(str1.begin(), str1.end(), L'1', L'2');
    dif_tim = ::GetTickCount() - t1;
    std::cout << "replace (wstring) : elapsed  : " << dif_tim <<" millisecond"<< std::endl;

у меня результат такой :

append: elapsed: 1203 millisecond
200000000
replace (wchar array) : elapsed : 328 millisecond
replace (wstring) : elapsed : 500 millisecond
Press any key to continue .

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

C>Кстати, С++ вариант по прежнему падает, если count >= 10000
C>Прекрасный пример — тут Вы правы.
Ну, этож твой код падает