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

S>> Просто имутабельность строки, гарантируется фреймворком в сэйв режиме. В нативе это возможно только через пометку памяти R/O.
C>В С++ для этого есть слово "const". Конечно, его можно снять const_cast'ом, но это уже ССЗБ.
Тем и хорош манагед, что в ССЗБ сильно ограничен. Тут уж выбирай свобода действий в нативе, но с буратинами, либо в отсутствии Папы Карло выискивать обходные пути.

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

C>>>Лучше молчать, если не знает.
C>>Таки нет в .NET тех фич, которые у меня были.
C>Ну давайте рассказывайте что за фичи-то.
Я же сказал — трансформация mutable/immutable с O(1) затратами (если это возможно), разные виды хранилищ (стековое, со Small Buffer Optimization), возможность сделать непотокобезопасную мутируемую строку, возможность делать разное представление и т.п.

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

C>>В С++ для этого есть слово "const". Конечно, его можно снять const_cast'ом, но это уже ССЗБ.
S> Тем и хорош манагед, что в ССЗБ сильно ограничен. Тут уж выбирай свобода действий в нативе, но с буратинами, либо в отсутствии Папы Карло выискивать обходные пути.

unsafe {
//Буратина
};

В С# буратин тоже хватает, на самом деле.

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

C>

C>unsafe {
C>//Буратина
C>};
C>

C>В С# буратин тоже хватает, на самом деле.
Я на этот момент уже обращал внимания, говоря об сэйв режиме. Причем заметь они помечаются специальным кодом,
и CAS может запретить данный код. В манагед большинство прекрасно чувствует себя и без unsafe. ССЗБ и без этого еще найдется.

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

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

C>>>Не, у меня круче всё было
S>>Ну своё то оно всегда
S>> Просто имутабельность строки, гарантируется фреймворком в сэйв режиме. В нативе это возможно только через пометку памяти R/O.
C>В С++ для этого есть слово "const". Конечно, его можно снять const_cast'ом, но это уже ССЗБ.
const — это не то.
Вот ты написал метод, который получает const char*.
Можешь ли ты сохранить внутри класса эту строку? Правильный ответ — нет, так как кто-то другой вполне мог эту строку получит не как константную и спокойно её меняет.
Побороть это можно с помощью COW, но тогда надо внутри обертки строки поддерживать счетчик ссылок, но он небесплатный.

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

ГВ>строка — это строка, дерево — это дерево, узлы — это узлы.

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

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

K>Таким глубоким, бесконечно глубоким, я бы сказал, возражениям я не могу ничего противопоставить. Такую рекурсию мой ограниченный умишко не вместит. Еще Энштейн говорил, что знает только две бесконечные вещи: вселенную и определение строки через строку. Да и то, насчет вселенной он был не совсем уверен.

Ну уж, куда вселенной до рекурсивной строки-то?!

Ладно, завязываем: по сути я тебя понял. Вопросы к WolfHound-у остались в воздухе, да и шут с ними. Это, по сути, даже не о терминах спор, а чуть ли не о коннотациях.

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

C>>В С++ для этого есть слово "const". Конечно, его можно снять const_cast'ом, но это уже ССЗБ.
G>const — это не то.
G>Вот ты написал метод, который получает const char*.
А зачем я буду писать такой метод?

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

E>>STL -- это часть средства для изготовления фрейсворков. Сам по себе STL фреймворком не является, так как без кучи великов на нём не поедешь...

C>STL это и есть фреймворк. Убогий — да. Но тем не менее фреймворк.
Нет, ну если ты сказал, то как же можно в этом сомневаться-то?

C>Давайте без домыслов и фантазий бабушки-гадалки, окей?
Ну расскажи нам как на "фреймворке STL" передать что-то по сети, или окошко написать, или, хотя бы, прочитать/записать UTF-16 текстовый файл...

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


C>>Давайте без домыслов и фантазий бабушки-гадалки, окей?
E>Ну расскажи нам как на "фреймворке STL" передать что-то по сети, или окошко написать, или, хотя бы, прочитать/записать UTF-16 текстовый файл...

И? .NET FW тоже не всемогущ. То, что он гораздо мощнее STL говорит лишь о том, что он гораздо мощнее убогой STL. Что Вам не понятно?

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

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

E>>>А я тебя по складам тогда буду: Кри-О-Срай?
C>>По складам? Если Вы подразумеваете по слогам, то по слогам читается криос рэй.
E>Эх! В стихах, видать, ты не знаток, увы!..
E>Но в целом в русском слоге всегда не больше одного гласного звука...

Видать ты тоже не знаток: кри-ос-рай

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

ГВ>Не "строки в C++", а "строки MS STL".
При чём тут MS?
ГВ>Даже не смотря на то, что эти строки описаны в стандарте, нет никаких оснований переносить недостатки, свойственные тем или иным реализциям std::basic_string на весь C++.
Дети, STL и ASCIIZ — это единственные строки, стандартизованные в С++. И проблема у них — вовсе не в реализации. А в архитектуре, т.е. в том контракте, которым авторы наделили std::string. Сколько можно объяснять одно и то же? Вам показывают на пальцах: иммутабельные строки — эффективнее. Отдельный от них стрингбилдер — эффективнее. А вы опять за своё: "ой, так нечестно, ваши классы спроектированы под свои задачи". Конечно std::wstring неизбежно будет плодом компромиссов — потому что перед ней поставили противоречивые задачи.

ГВ>Не смеши меня, ладно? Никто из C++-ников не говорил (AFAIR), что std::wstring есть лучшее решение на все случаи жизни. Это только строка, предусмотренная стандартной библиотекой. Но "стандартная" не означает "обязательная к применению", поэтому нельзя апеллировать к этой реализации, как к обязательно используемой везде в C++ ("строка в C++" — фраза содержит именно такое неявное обобщение). Сама по себе подобная апелляция уже ошибочна. Не нравятся те или иные строки? Сделай другие.
Копец. Я уже семь раз написал на эту тему: самописанные строки не будут ни с кем интероперировать. Если бы с самого начала был спроектирован нормальный фреймворк, с раздельными контрактами на mutable и immutable строку — вот тогда да, могли бы существовать различные реализации, которые бы интероперировали на основе этих контрактов. Но в жизни ничего похожего нет — покажите мне хоть одну вменяемую реализацию строк, и хоть один непустой проект на её основе.

ГВ>Ну, поздравляю нефанатов. Наконец-то они дошли до того, что известно любому C++-нику. Что универсальных решений не бывает.
Не вижу, чтобы что-то было известно "любому С++-нику". Пока что любые C++ ники сопротивляются любым попыткам объяснить им, что std::string — УГ. Независимо от реализации.

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

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

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

Нет, процессор ничего знать не будет. Просто при попытке записи в R/O секцию произойдет исключение Access Violation. Ознакомься с основными принципами страничного механизма процессора.

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

C>Проверки не будет — запрета не будет. "Так в чем сила, брат?"

Сила, как всегда, в знании, которого в этом плане у тебя нет. Проверки не будет , а будет Access Violation при попытке модификации.

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

S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Так Рихтер все же прав или нет — насчет просмотра блоков ?
S>Ты его неправильно понимаешь. Никакие "блоки" памяти GC, естественно, не просматривает. У него есть полная информация об устройстве этих "блоков памяти".

The garbage
collector now traverses the heap linearly looking for contiguous blocks of garbage objects
(now considered free space). If small blocks are found, the garbage collector leaves the
blocks alone.
If large free contiguous blocks are found, however, the garbage collector shifts the
nongarbage objects down in memory (using the standard memcpy function that you’ve
known for years) to compact the heap.

Выделено мной. Как еще можно понимать linearly looking, я не понимаю.


PD>>Копировать без надобноси не надо , и такие конструкции лучше вообще употреблять с осторожностью.
S>Какие конструкции? Вызов методов? Ну так я тебе напомню, что код в основном из них и состоит.

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


PD>>Но для этого надо видеть, во что твой код примерно превратится. Без просмотра ассемблерного кода. Просто в уме понимать
S>Вот для понимания того, во что превратится твой код, нужно сначала съесть пуд соли с дизассемблером.

И да и нет. Для того, чтобы "видеть" за С++ конструкциями ассемблерные команды — да. Но этого я обычно и не делаю, разве что если меня вдруг удивит скорость некоторого фрагмента. А вот чтобы понимать, во что такая конструкция выльется — даже не обязательно знать асм.

PD>>Я не собираюсь анализировать не свои библиотеки, а говорю про свой собственный код. Его я смогу проанализировать и понять, что у меня делается.
S>Если "твой собственный код" пользуется библиотеками, то нихрена полезного из анализа "твоего собственного кода" не выйдет.

Какими библиотеками ?

Стандартная C RTL — да, используется, да, свою версию strcpy я не буду писать. Win32 — да, тоже, потому что я и не могу написать ее функции. Но про первую столько понаписано и столько сравнений проведено, и столько раз эта strcpy обсуждалась, что я знаю, чему тут можно верить. А поскольку основное время все же ест мой собственный код, то я над ним и полный хозяин.


PD>>Это тебе и кое-кому еще кажется, что это так. Профайлер лишь говорит о том, что есть, но ни слова не скажет о том, что могло бы быть. Вот тебе пример. Подсчет числа счастливых билетов. Тупо — 6-кратный цикл. Немного подумать — пятикратный. Еще подумать — тройной. А, оказывается, есть просто формула, без всяких циклов. Ну вот написал некий программист 6-цикл , видит, что все время уходит на... и что дальше ?
S>Будет повод исправить программу. А то, может быть, там всё время уходит не на цикл, а на ожидание пользовательского ввода этого номера. В итоге замена "шестикратного цикла" улучшит ситуацию на 1%.

Ушел от ответа. Никакого пользовательского ввода в этой задаче нет. А как все же исправить — неясно.

PD>>SQL — это тоже "управляемый" язык, так что здесь верно то же, что и для .Net. Но к программированию на уровне "я точно знаю, какие команды процессора у меня выполняются (даже если писалось не на асме)" это не относится.
S>Это очень узкая точка зрения. Грубо говоря, для SQL сервера команды процессора не имеют никакого значения. Не потому, что он "управляемый", а потому, что основное время уходит на ожидание подъема данных в память. Для него low-level — это "я точно знаю, какие страницы у меня читаются". И эта ситуация ничем принципиально не отличается от C++ и ассемблера. Точно так же опыт нарабатывается исключительно с помощью инструментов. И точно также опыт пользования MS SQL можно перенести на MySQL — как и Паскалевский опыт на С++. Потому что устройство "матчасти" примерно одинаковое. Переносить опыт с Паскаля на SQL, к примеру, будет неэффективно. И с SQL на STL тоже.

Я не случайно поставил слово "управляемый" в кавычки. Я вовсе не утверждаю, что он родня C#. Я просто одно утверждаю — он не компилируется в ассемблерные коды, а исполняется под управлением некоторой исполняющей системы. Больше я ничего не хотел сказать.

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

Если я правильно понял, то там идет оценка фрагментации кучи,
"При больших свободных прилегающих блоков, сборщиком мусора сдвигает
nongarbage объекты в памяти ", если небольшие то и нефиг эту кучу дефрагментировать.

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

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

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

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

PD>Нет, процессор ничего знать не будет. Просто при попытке записи в R/O секцию произойдет исключение Access Violation. Ознакомься с основными принципами страничного механизма процессора.

А кто будет знать? Дева мария или еще кто-то?
Именно процессор и делает такие провеки.

Кстати, что ты пытаешь доказать то? Что играться с атрибутами доступа к страницам памяти лучше, чем использовать иммутабельность?

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

PD>Выделено мной. Как еще можно понимать linearly looking, я не понимаю.
Очень жаль, что не понимаешь. Linearly looking вовсе не означает, что там есть цикл

for(int i=HeapStart;i< HeapLength;i++)
  if (IsGarbage__heap[i]) 
    ...

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

PD>Мой код состоит в основном отнюдь не из вызова методов. Вот в этом-то и в значительной степени разница между нашими подходами. Методы — это так, для лучшей организации, не более. А код состоит из реализации алгоритма, достаточно сложного, вообще говоря. Я могу эту реализацию написать с методами, могу и без методов, это будет организационно хуже, но работать будет также, даже, может, быстрее, если там не все inline у методов.
Ну, твоему коду, значит, повезло. Ему фреймворк не нужен — достаточно базовой арифметики (спасибо, что хотя бы она встроена в C++. А то ведь могли и это вынести в stl). Тут, правда, не совсем ясно, зачем вообще нужны плюсы. С тем же успехом можно колбасить код и на С — ведь никаким полиморфизмом или, скажем, ексепшнами, ты пользоваться не собираешься. Но это вопрос другой.

S>>Вот для понимания того, во что превратится твой код, нужно сначала съесть пуд соли с дизассемблером.
PD>И да и нет. Для того, чтобы "видеть" за С++ конструкциями ассемблерные команды — да. Но этого я обычно и не делаю, разве что если меня вдруг удивит скорость некоторого фрагмента. А вот чтобы понимать, во что такая конструкция выльется — даже не обязательно знать асм.
Вот это мне не вполне понятно. Что значит "во что такая конструкция выльется"? Асм, конечно, знать не обязательно. Но обязательно знать то, во что "выливается" конструкция. К примеру, выливается ли она в доступ к файлу подкачки, и если выливается, то когда. Для понимания того, что выделение массива данных размером в 5GB для обработки неизбежно потребует работы с файлом подкачки ассемблер знать не обязательно. Зато обязательно знать про архитектуру виртуальной памяти на той платформе, для которой ты пишешь — ну, чтобы вообще понимать, что такое файл подкачки. А если под "выливается" понимать, скажем, количество сбросов конвеера, то нужно как бы знать не только ассемблер на уровне MOV AH, AL, а вообще говоря архитектуру процессора.

PD>Какими библиотеками ?
Любыми библиотеками.
PD>Стандартная C RTL — да, используется, да, свою версию strcpy я не буду писать. Win32 — да, тоже, потому что я и не могу написать ее функции. Но про первую столько понаписано и столько сравнений проведено, и столько раз эта strcpy обсуждалась, что я знаю, чему тут можно верить. А поскольку основное время все же ест мой собственный код, то я над ним и полный хозяин.
Вопрос ровно в том, что такое "твой собственный код". Повторюсь: если этот код — это всего лишь арифметика, то ему просто повезло. Остальным, тем, кто не хочет, к примеру, педалить руками циклы в умножении матриц, хочется пользоваться библиотекой. И тут выясняется, что компилятор на диво умён — и иногда невинно выглядящие вещи (типа a*b) скрывают за собой холостое копирование килобайтов, а иногда наоборот — страшные навороты сворачиваются в очень компактный целевой код.
И без профайлера выяснить это невозможно — я еще раз повторяю пример с ошибкой в MS STL, из-за которой у них там было огребание со строками. Всего лишь немного другой алгоритм разрешения неопределённостей в частичных специализациях в компиляторе, и тот же самый пользовательский код с той же самой библиотекой начинает перформить совсем по-другому.

PD>Ушел от ответа. Никакого пользовательского ввода в этой задаче нет. А как все же исправить — неясно.
Я уже неоднократно слышу подобные гм-м, претензии, от профайлероненавистников. Еще раз неустанно повторяю: профайлер и не обещал вам сказать, как исправить. Но что исправить — профайлер скажет. Ситуация типа "у меня вся программа состоит из одного шестикратного цикла" встречаются, увы, крайне редко. Опять же — пример из далёкого тебе мира СУБД. "Показ плана запроса" не скажет тебе, какие индексы нужно поставить, и какие агрегатные таблицы нужно создать. Но без просмотра плана запроса угадать способ ускорения практически невозможно. Точнее, опять же так: опытный DBA может "в уме" прикинуть план запроса, с учётом селективности тех или иных предикатов, и еще много чего. Но его опытность — не в чтении книжек Кайта и Дейта. А в том, что он гонял реальные запросы на реальных базах под профайлером, и многократно наблюдал как за тем, что делает оптимизатор, так и за тем, куда уходит производительность. Программерская интуиция — это всего лишь кэш для фактов; если ты не будешь получать факты, то никогда не научишься предсказывать производительность. Вот, к примеру, ты, со всем своим опытом разработки, совершенно бессилен представить себе тот факт, что "мёртвые" строки не влияют на производительность программы. И что большинство приходящих тебе в голову "оптимизаций" в C# или Java только ухудшат производительность. И это несмотря на то, что про это пишут во всех книжках. А вот если бы ты поработал над конкретной задачей с профайлером в руках, то накормил бы конвеер своего процессора фактами. И уже на их основе получил новую, улучшенную "интуицию", которая бы ошибалась гораздо реже.

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

G>А кто будет знать? Дева мария или еще кто-то?
G>Именно процессор и делает такие провеки.

О господи! Ну прочитай же наконец про атрибуты страниц в страничном механизме. Пойми, что процессору все равно, куда писать — он транслирует вирт. адрес в физический через этот механизм, и если при этом атрибут страницы R/O, то возникнет исключение. А проверку эту он делает всегда. Всегда, понимаешь ?

G>Кстати, что ты пытаешь доказать то? Что играться с атрибутами доступа к страницам памяти лучше, чем использовать иммутабельность?

Я лишь хочу сказать, что константые объекты можно в принципе делать для любого класса, размещая их в R/O памяти.

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

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

S>Если я правильно понял, то там идет оценка фрагментации кучи,
S>"При больших свободных прилегающих блоков, сборщиком мусора сдвигает
S>nongarbage объекты в памяти ", если небольшие то и нефиг эту кучу дефрагментировать.

Да, я так же понял, но проход по блокам есть... Я же не говорю, что он с ними делает, я лишь отмечаю, что он их просматривает.