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

S> Приходится делать свои аналоги
S>Например http://www.rsdn.ru/forum/dotnet/3303143.flat.aspx#3303143

Автор: Serginio1
Дата: 24.02.09

S>там есть реализация RStdingBuilder.
S> Так или иначе ни один класс не может реализовать все, что от него нужно, но у StringBuildera внутренности закрыты, поэтому
S>и пользователскую реализация сделать нельзя или сложно.
Так об этом и речь, что приходится городить огород. А обычные С++ строки как правило с этим справляются. Мне только один раз приходилось писать свои оптимизированные строки а-ля rope для одного сетевого фильтра.

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

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

PD>Отсюда ясно, что эффект от иммутабельности может быть как существенным и положительным, так и существенным и отрицательным. Если генерировать набор строк, не меняя длины исходной строки, а только заменяя в ней символы, то без иммутабельности эта задача решается на одной строке, одном буфере. С иммутабельностью мы рискуем захватить мегабайты, прежде чем проснется GC и уничтожит всю эту иммутабельную кунсткамеру. Более того, на нелюбиом тобой массиве из char (ASCIIZ то есть) эти операции можно выполнять на одном буфере даже при изменении длины строки, лишь бы только за пределы буфера не выходить.

Если бы в java/.NET не было StringBuffer/StringBuilder, это было бы проблемой. А так это станет проблемой только если у программера, писавшего этот алгоритм, кривые руки.

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

a>> M>Угу, потом пытаешься скрестить QString с bt_str и материшься трехэтажным матом

a>> Угу. Бывает конечно и такое. Если самому можно определять какую библиотеку использовать то вопросы межвидового взаимодействия как правило не стоят, или решаются административным порядком. Но дело в том что я довольно много занимаюсь вопросами интеграции и взаимодействия с сторонними аппликациями ( иногда весьма старыми и экзотическими) и здесь "окружающая среда" имеет решающее значение. Я далеко не всегда могу выбирать то что мне нравиться ( в том числе иногда и сам язык),часто приходиться мириться с тем что есть. . В этом плане С++ с его многообразием библиотек более универсален чем С#.


M>Да ничего он не универсален. Весь этот «внешний» мир и появился из-за такой вот «универсальности». В идеальном мире, где строка была бы встроена в язык С++, броблемы QString <-> bt_str просто не появилось бы. А так, создали кучу проблем, миллион несовместимых классов строк, активно с тим все боремся, но при этом гордо: «а посмотрите, какой С++ универсальный»
Что поделать, тяжёлая наследственность . Но это и есть та самая "окружающая среда" и она существует не зависимо от нашего желания и броться с ней пока удобней из плюсов. Когда абсолютно всё перепишут на дотнете то будет нам всем счастье.

Здравствуйте, alexey_ma, Вы писали:
_>Ясень пень что не решают, но иногда помогают. Разговор вроде был о возможности выбора оптимальной реализации строк в зависимости от задачи и о проблемах интеграции. Так вот, когда я из хука лезу в Сlarify11 (он почему-то написан на MFC 7.0) чтобы прочитать там пару строчек из ObjectivGrid я использую СString ( мало того я вынужден компилировать хук с той же версией MFC что и Сlarify — иначе не работает), если работаю с CОМ — использую BSTR и т.п — так понятно?
Нет, непонятно. Я не понимаю, что там делается внутри Clarify и каким боком тут вид строки, но вот про BSTR более-менее понятно. Вот в шарпе нет никакого BSTR, но при этом каким-то волшебным образом он интероперирует с COM. Вы не задумывались, почему?


_>Про замечательный интероп шарпа c CОМ на примере ВНО, я полагаю замнем
Можно и замять — мне всё равно. В принципе, на текущем фреймворке реализация in-proc COM серверов для unmanaged хостов — не лучший способ скрасить себе жизнь. А вот в обратную сторону интероп работает просто прекрасно.

S>>Покажите код на С++, который делает это злое волшебство. Тот самый, который никак-никак не заработает в шарпе. Я даже за деньги не буду выкачивать PowerBuilder 6 и искать в нём объект называемый DataWindow.
_>Не могу я код показать, но он есть и работает
А что, стеснительность не позволяет?
_>Возможно что подобный код какой нибудь гений может написать и на шарпе , но вряд-ли он будет короче и понятней.
При чём тут гений — это вопросы примитивной технической реализации. В принципе, ничего страшнее platform invoke нам всё равно не светит.

_>Да чего там PowerBuilder, набросайте VB6 апликацию с MSFlexGlig и попробуйте получить из этого грида пару строчек или хотя-бы текст какого нибудь Label тоже из VB6. К сожалению ( или к счастью) мир пока не весь еще дотнет, с дотнетом кстати интегрировться легко.
Я не буду качать себе VB6 и MSFlexGrid — зачем? Приведите код на С++, который это делает, и по-вашему, невоспроизводим на шарпе.

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

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

S>Я не совсем пойму, для чего тебе это потребовалось. В чём смысл этого? Можно иметь иммутабл дерево, можно иметь иммутабл стек. Иметь произвольный иммутабл граф иммутабл объектов — трудно, почти что невозможно. И, на первый взгляд, ненужно.

Ну признаться , я не очень пойму, почему граф нельзя, а дерево можно. Но не в этом дело. Я просто хочу сказать, что это не так просто, и именно поэтому ИМХО их нет в языке, и я не могу создать иммутабл объект сам.

S>Опять же, пойми, что мы не пытаемся перехватывать все изменения и бросать исключение. Задача — описать иммутабл при помощи системы типов, так, чтобы изменить значение было просто невозможно.

Да понял я тебя, не волнуйся

S>>>Можно, но обычно незачем. Массовый ToUpper обычно применяется к коротким строкам, там дешевле сделать копию, чем делать inplace.
PD>>Вот это по крайней мере звучит странно. Почему дешевле сделать копию, если ее можно не делать ?
S>Потому, что работа над оригиналом — дорогая.

А если не секрет, почему все же. Я упорно не могу понять, чем такое на легальном C#

string s= ...
string s1 = s.ToUpper();

дороже, чем на некоем C#-подобном языке, где string mutable

string s= ...;
StringHelper.ToUpper(s);// заменяет в s на верхний регистр

Я даже в этом языке твой любимый хелпер употребил

На С

char szString[N];
strcpy(szString,...);
strupr(szString);

никак не может быть дороже, чем

char szString[N], szStringCopy[N];
strcpy(szString,...);
strcpy(szStringCopy,szString);
strupr(szStringCopy);

Операции будут те же и в этом моем псевдо-C#. Почему дороже ?
PD>>Ну вручную все , что угодно можно сделать. Я же писал — вопрос о реализации. Дальше будем вручную дописывать прочие методы от string (CompareTo, Contains, IndexOf...)
S>Да, тут ты прав. Всё это нужно было сархитектурить по-другому.

Ява, Антон, Ява . Это не к MS, это к Sun. MS просто не решилась все это серьезно изменить — боялись оттолкнуть программистов на Яве.

PD>>Это как ? Не понял. В string ??? Или в StringBuilder все же ?
S>А внутри стрингбилдера по-твоему что?

Я так полагаю, кусок из short . Можно и посмотреть, но лень. Но какое отношение это имеет к росту числа строк (строк!) о котором ты пишешь ?

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

PD>>Отсюда ясно, что эффект от иммутабельности может быть как существенным и положительным, так и существенным и отрицательным. Если генерировать набор строк, не меняя длины исходной строки, а только заменяя в ней символы, то без иммутабельности эта задача решается на одной строке, одном буфере. С иммутабельностью мы рискуем захватить мегабайты, прежде чем проснется GC и уничтожит всю эту иммутабельную кунсткамеру. Более того, на нелюбиом тобой массиве из char (ASCIIZ то есть) эти операции можно выполнять на одном буфере даже при изменении длины строки, лишь бы только за пределы буфера не выходить.

E__>Если бы в java/.NET не было StringBuffer/StringBuilder, это было бы проблемой. А так это станет проблемой только если у программера, писавшего этот алгоритм, кривые руки.

Ну кривые или не кривые — это не вопрос, а вот то, что на Яве/C# без особой надобности создают новые куски памяти из символов (специально даю такое низкоуровневое определение) там, где это совсем не обязательно — это факт.

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

E>Ну то есть выражения вида a |= 16 не нужны, и даже вредны?
Ты путаешь объекты и переменные.
Есть объект число. Этот объект не изменяемый.
Есть переменная. Она может быть изменяемая или не изменяемая.

E>Кста, ты тут много раз заметил, что авторы шарпа не смогли родить мутабельную строку, которая могла бы быть эффективным значением...
Это не возможно.

E>IMHO, разделение на два класса происходит именно оттуда...
Нет.
Они не осилили поискать в интернете эффективную структуру для неизменяемой строки.
И из-за этого тупо клонировали явовский стрингбильдер.

Здравствуйте, Игoрь, Вы писали:

S>> Так или иначе ни один класс не может реализовать все, что от него нужно, но у StringBuildera внутренности закрыты, поэтому
S>>и пользователскую реализация сделать нельзя или сложно.
И>Так об этом и речь, что приходится городить огород. А обычные С++ строки как правило с этим справляются. Мне только один раз приходилось писать свои оптимизированные строки а-ля rope для одного сетевого фильтра.

Ну про функциональность стрингбуилдера давно плюются.
Не вижу веских причин для его качественной переделки. Или ввести новый более функциональный мутабельный строковый тип.
С другой стороны на кодепрожект наверняка полно таких классов на любой вкус.
Просто к сторонним библиотекам относишься настороженно.

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

S>Нет, непонятно. Я не понимаю, что там делается внутри Clarify и каким боком тут вид строки, но вот про BSTR более-менее понятно. Вот в шарпе нет никакого BSTR, но при этом каким-то волшебным образом он интероперирует с COM. Вы не задумывались, почему?
Сlarify сам написан на MFC использует стороний компонет ObjectivGrid (тоже MFC) многие методы которого возвращают СString. Чтобы поиметь какую-то информацию от этого грида я внедряю свою MFC дллку в Сlarifу, получаю указатель на грид и начинаю работать с его методами используя родной для этого грида СString. В данном случае никакой дотнетовский интероп не будет работать более эффективно( Проверяно на практике, коллеги пытались это сделать на C#).
Я очень рад что шарп интероперирует с COM, только вот я в многих случаях могу работая из плюсов с СОМ могу избежать ненужного мне маршаллинга, в дотнете это у вас не получиться.

_>>Про замечательный интероп шарпа c CОМ на примере ВНО, я полагаю замнем
S>Можно и замять — мне всё равно. В принципе, на текущем фреймворке реализация in-proc COM серверов для unmanaged хостов — не лучший способ скрасить себе жизнь. А вот в обратную сторону интероп работает просто прекрасно.
Как я говорил так уж и прекрасно

На собственном опыте вижу что ВНО написанный на плюсах работает бодрее, жрет меньше cpu, на порядок потребляет меньше памяти чем BHO написанный на шарпе с аналогичной функциональностью.

S>>>Покажите код на С++, который делает это злое волшебство. Тот самый, который никак-никак не заработает в шарпе. Я даже за деньги не буду выкачивать PowerBuilder 6 и искать в нём объект называемый DataWindow.
_>>Не могу я код показать, но он есть и работает
S>А что, стеснительность не позволяет?
Да
_>>Возможно что подобный код какой нибудь гений может написать и на шарпе , но вряд-ли он будет короче и понятней.
S>При чём тут гений — это вопросы примитивной технической реализации. В принципе, ничего страшнее platform invoke нам всё равно не светит.
Конечно, все в конце-концов сводится к вопросам примитивной технической реализации, но согласитесь что писать инжектируемую в
чюжой unmanaged процесс дллк на дотнете удовольствие сомнительное, а выгода не очевидна.

_>>Да чего там PowerBuilder, набросайте VB6 апликацию с MSFlexGlig и попробуйте получить из этого грида пару строчек или хотя-бы текст какого нибудь Label тоже из VB6. К сожалению ( или к счастью) мир пока не весь еще дотнет, с дотнетом кстати интегрировться легко.
S>Я не буду качать себе VB6 и MSFlexGrid — зачем? Приведите код на С++, который это делает, и по-вашему, невоспроизводим на шарпе.
Нет не покажу . Если интересно пробуйте сами. Дело даже не в том что код невоспроизводим на шарпе, дело в целесообразности этого воспроизведения. Зачем?

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну признаться , я не очень пойму, почему граф нельзя, а дерево можно. Но не в этом дело. Я просто хочу сказать, что это не так просто, и именно поэтому ИМХО их нет в языке, и я не могу создать иммутабл объект сам.
Можешь. В дотнете много иммутабл объектов помимо строк.

PD>А если не секрет, почему все же. Я упорно не могу понять, чем такое на легальном C#
PD>Операции будут те же и в этом моем псевдо-C#. Почему дороже ?
Потому, что твой код небезопасен. Как только ты начнешь делать его потокобезопасным, стоимость сразу станет совсем другой.

Выделение памяти в хипе — очень дешево. Стоимость чтения и записи в один и тот же short не слишком отличается от чтения из одного short и записи в другой short. А именно этим отличаются inplace ToUpper от копирующего ToUpper. На длинных строках начнут сказываться эффекты cache locality — но для коротких строк стоимость блокировки запросто сожрёт цену от дублирования лишнего килобайта. Посмотри на внутреннее устройство StringBuilder — там явно видна разница между "иммутабл" строкой, и "безопасной мутабл" строкой.


PD>Ява, Антон, Ява . Это не к MS, это к Sun. MS просто не решилась все это серьезно изменить — боялись оттолкнуть программистов на Яве.
Такие вещи, как System.String, подвергаются очень тщательному дизайну на предмет очень-очень многих противоречивых требований. Так что не думаю, что боязнь оттолкнуть жавистов была основным мотивом.
Ну и, конечно же, невозможно сделать всё-всё правильно с первого раза. Вон, в яве только в 1.2 допёрли, что Thread.Pause нужно запретить.

PD>Я так полагаю, кусок из short . Можно и посмотреть, но лень. Но какое отношение это имеет к росту числа строк (строк!) о котором ты пишешь ?

[Serializable, ComVisible(true)]
public sealed class StringBuilder : ISerializable
{
    // Fields
    private const string CapacityField = "Capacity";
    internal const int DefaultCapacity = 16;
    internal IntPtr m_currentThread;
    internal int m_MaxCapacity;
    internal volatile string m_StringValue;
...

Не угадал

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

PD>А до них Sun в Java тоже не освоила, так ? Не осваивается оно...
А тебя в гугле забанили?
Я же даже название одной из структур данных упоминал...

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

_>Сlarify сам написан на MFC использует стороний компонет ObjectivGrid (тоже MFC) многие методы которого возвращают СString. Чтобы поиметь какую-то информацию от этого грида я внедряю свою MFC дллку в Сlarifу, получаю указатель на грид и начинаю работать с его методами используя родной для этого грида СString. В данном случае никакой дотнетовский интероп не будет работать более эффективно( Проверяно на практике, коллеги пытались это сделать на C#).
Это правда. Дотнет не рассчитан на внедрение в адресное пространство чужого неуправляемого процесса.
Это не столько интероп, сколько хак. Опять же, вы путаете причину и следствие. То, что вам приходится компилировать DLL с той версие CString, которая у хоста — это не возможность, это необходимость. Вызванная ровно тем, что в С++ нет двух одинаковых классов строк. Если бы в стандарте с самого начала была приличная строка, вы бы и не знали о том, что могут потребоваться какие-то QString.
_>Я очень рад что шарп интероперирует с COM, только вот я в многих случаях могу работая из плюсов с СОМ могу избежать ненужного мне маршаллинга, в дотнете это у вас не получиться.
А, ну это уж конечно недостаток из недостатков.

_>Как я говорил так уж и прекрасно
_>

_>На собственном опыте вижу что ВНО написанный на плюсах работает бодрее, жрет меньше cpu, на порядок потребляет меньше памяти чем BHO написанный на шарпе с аналогичной функциональностью.

Вы невнимательно читаете. Для девелопера это очень плохо.
BHO — это та самая реализация inproc COM server, о которой я говорил абзацем выше.

_>Да
В таком случае давайте не будем обсуждать этот код.
_>Конечно, все в конце-концов сводится к вопросам примитивной технической реализации, но согласитесь что писать инжектируемую в
_>чюжой unmanaged процесс дллк на дотнете удовольствие сомнительное, а выгода не очевидна.
Я согласен. Но согласитесь, что разработка DLL для инжектирования в чужой процесс никак не назовешь мейнстримом. Так я могу сходу еще назвать тонну областей, куда управляемая среда подойдет плохо.

S>>Я не буду качать себе VB6 и MSFlexGrid — зачем? Приведите код на С++, который это делает, и по-вашему, невоспроизводим на шарпе.
_>Нет не покажу . Если интересно пробуйте сами. Дело даже не в том что код невоспроизводим на шарпе, дело в целесообразности этого воспроизведения. Зачем?
Ну, например чтобы показать наглядную разницу.

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

PD>Что такое иммутабельность, в конце концов ? Грубо говоря, это порождение констант в рантайме. С++ этого не умеет. Java и C# умеют, но только для типа string. Как только мы попробуем развить идею иммутабельности для любых классов, так мы сразу придем к задаче, примерно эквивалентной работе GC — проверке на каждой операции, не достижим ли данный объект из какого-нибудь иммутабельного объекта. string слишком прост, поэтому для него такое возможно, в нем нет вложенных объектов.
Это же просто феерия.
Я просто балдею.
И как вся функциональщина то живет?

PD>С другой стороны, необходимо ответить на вопрос — насколько часто придется все же менять эти иммутабельные объекты. Я не оговорился, слово "менять" я понимаю здесь в широком смысле, то есть создавать их измененные версии, независимо от того, как именно. Если объекты не являются иммутабельными, то во многих случаях эти изменения можно делать inplace (примеры — преобразование к иному регистру, замена символа на другой, реверс). Если объект является иммутабельным, то эти действия приходится выполнять с помощью создания нового объекта, нового string в конечном счете, опять же иммутабельного.
И как часто такие действия нужны?
Плюс опять же не забывай про то что внутреннее представление строк может быть очень разным.
http://www.ibm.com/developerworks/java/library/j-ropes/index.html
Посмотри картинки. Они весьма позновательны...

PD>Отсюда ясно, что эффект от иммутабельности может быть как существенным и положительным, так и существенным и отрицательным.
Особенно если не знать матчасть.

PD>Если генерировать набор строк, не меняя длины исходной строки, а только заменяя в ней символы, то без иммутабельности эта задача решается на одной строке, одном буфере. С иммутабельностью мы рискуем захватить мегабайты, прежде чем проснется GC и уничтожит всю эту иммутабельную кунсткамеру.
А если разработчик ВМ осилил реализацию region inference то бедет тоже самое...

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


PD>Операции будут те же и в этом моем псевдо-C#. Почему дороже ?
Потому что они не могут узнать использует ли этот буфер кто-то ещё...

Здравствуйте, Игoрь, Вы писали:

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

И>Нет, не помогало. Сначала убрали вектора, а позже вообще перешли на пул выделенных буферов.
И что за задача?

И>Да, оказывается я этот rope несколько лет назад реализовывал, только не знал как оно называется. Но вопрос был по С#, String + StringBuilder не покрывают даже вполне распространенных сценариев, в частности элементарного редактирования текста средних и более размеров.
Но ропы это покрывают.

И>Вон в той же Java (откуда, я так понимаю, и были слизаны String+StringBuilder), таки появился Rope. Вот тебе и зоопарк реализаций. То, что иммутабельные строки могут быть полезны — согласен, но и должна быть возможность для нормального редактирования строк хотя бы средних размеров (нормального редактирования, а не с помощью обрубка вроде StringBuilder). И здесь иммутабельность не особо и нужна.
Пойми в чем прикол. Нужны только ропы.
Их редактирование вполне дешево.
Если бы в жабе строки изначально были бы ропами то никакого зоопарка бы не было. И StringBuilder'а тоже.

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

S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Ну признаться , я не очень пойму, почему граф нельзя, а дерево можно. Но не в этом дело. Я просто хочу сказать, что это не так просто, и именно поэтому ИМХО их нет в языке, и я не могу создать иммутабл объект сам.
S>Можешь. В дотнете много иммутабл объектов помимо строк.

Я са могу создать иммутабл тип ? Есть такие средства в языке ?

PD>>А если не секрет, почему все же. Я упорно не могу понять, чем такое на легальном C#
PD>>Операции будут те же и в этом моем псевдо-C#. Почему дороже ?
S>Потому, что твой код небезопасен. Как только ты начнешь делать его потокобезопасным, стоимость сразу станет совсем другой.

Ладно, оставим твои аппеляции к потокобезопасности в стороне. Не всегда она нужна, и уж тебе ли не знать, что большинство классов .Net не являются потокобезопасными, а значит, эту безопасность придется делать вне. Также и здесь можно было бы поступить. Но я даже и это обсуждать не хочу. Допустим, у меня вообще один всего поток — почему я должен платить за эту самую потокобезопасность, если она мне не нужна.


S>Выделение памяти в хипе — очень дешево. Стоимость чтения и записи в один и тот же short не слишком отличается от чтения из одного short и записи в другой short. А именно этим отличаются inplace ToUpper от копирующего ToUpper. На длинных строках начнут сказываться эффекты cache locality — но для коротких строк стоимость блокировки запросто сожрёт цену от дублирования лишнего килобайта. Посмотри на внутреннее устройство StringBuilder — там явно видна разница между "иммутабл" строкой, и "безопасной мутабл" строкой.

Слушай, не наводи тень на плетень. Хоть какие вргументы приводи — не докажешь, что не выполнять лишних действий лучше, чем их выполнять И потом — а скорость уборки GC всей этой кунсткамеры тоже пренебрежимо мала ?


PD>>Я так полагаю, кусок из short . Можно и посмотреть, но лень. Но какое отношение это имеет к росту числа строк (строк!) о котором ты пишешь ?
S>

S>[Serializable, ComVisible(true)]
S>public sealed class StringBuilder : ISerializable
S>{
S>    // Fields
S>    private const string CapacityField = "Capacity";
S>    internal const int DefaultCapacity = 16;
S>    internal IntPtr m_currentThread;
S>    internal int m_MaxCapacity;
S>    internal volatile string m_StringValue;
S>...
S>

S>Не угадал

Да нет, в общем-то, угадал. В сущности этот самый m_StringValue и есть кусок из short, точнее, ссылка на него . Я же специально употребил нечеткий термин, я же тебя знаю, скажи я "массив из short" — что тут началось бы...

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

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


PD>>Операции будут те же и в этом моем псевдо-C#. Почему дороже ?
E>Потому что они не могут узнать использует ли этот буфер кто-то ещё...

А оно таки всегда надо ? Строки, конечно, могут быть в кэше, кэш доступен из разных потоков, тут нужна потокобезопасность и другие случаи есть. Но если я в своей C/C++ функции завел локальную auto переменную (хоть std::string, хоть char[N]), то к ней все равно никто добраться не может, и почему я должен платить за эту потокобезопасность ? Ну а если уж она нужна, кто мешает обертку в виде thread_safe_string соорудить ?

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

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

S>Это не столько интероп, сколько хак. Опять же, вы путаете причину и следствие. То, что вам приходится компилировать DLL с той версие CString, которая у хоста — это не возможность, это необходимость. Вызванная ровно тем, что в С++ нет двух одинаковых классов строк. Если бы в стандарте с самого начала была приличная строка, вы бы и не знали о том, что могут потребоваться какие-то QString.

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

_>>Я очень рад что шарп интероперирует с COM, только вот я в многих случаях могу работая из плюсов с СОМ могу избежать ненужного мне маршаллинга, в дотнете это у вас не получиться.
S> А, ну это уж конечно недостаток из недостатков.
Для меня — да.
S>Вы невнимательно читаете. Для девелопера это очень плохо.
Для девлопера хаков сгодится . Вот начну всерьез на шарпе писать — исправлюсь.
S>BHO — это та самая реализация inproc COM server, о которой я говорил абзацем выше.
Да, конечно. Ну так здесь плюс победил (пока) или нет?
S>Я согласен. Но согласитесь, что разработка DLL для инжектирования в чужой процесс никак не назовешь мейнстримом. Так я могу сходу еще назвать тонну областей, куда управляемая среда подойдет плохо.
Респект. Я как раз в тех самых областях. Вот бы мне еще удалось убедить в этом неразумных колег — энтузиастов дотнета. Им даже бенчмарки не указ
S>>>Я не буду качать себе VB6 и MSFlexGrid — зачем? Приведите код на С++, который это делает, и по-вашему, невоспроизводим на шарпе.
_>>Нет не покажу . Если интересно пробуйте сами. Дело даже не в том что код невоспроизводим на шарпе, дело в целесообразности этого воспроизведения. Зачем?
S>Ну, например чтобы показать наглядную разницу.
Да ладно оставим это, в этом коде те самые хаки о которых Вы говорили.

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

S>

S>[Serializable, ComVisible(true)]
S>public sealed class StringBuilder : ISerializable
S>{
S>    ...
S>    internal volatile string m_StringValue;
S>...
S>

Забавно. А с какой целью String/StringBuilder сделаны именно так, а не на базе char[] (который мог бы так же передаваться в String без копирования в StringBuilder.ToString())? Для того, чтобы убрать косвенность String->char[]->данные и сделать так, чтобы данные сразу в объекте «строка» хранились?

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

WH>Пойми в чем прикол. Нужны только ропы.
WH>Их редактирование вполне дешево.
WH>Если бы в жабе строки изначально были бы ропами то никакого зоопарка бы не было. И StringBuilder'а тоже.

И что, даже на коротких строках (очень частый случай) «верёвки» будут эффективнее String/StringBuilder?