Здравствуйте, CreatorCray, Вы писали: CC>Доказательства решительной невозможности будут?
Давайте лучше вы опровержение приведете. А то я уже запарился объяснять что-то людям, которые не хотят ничего понять. CC>В С++ такие строки могут быть нужны "под задачу". А в этом случае весь интероп с окружающим кодом легко свести к присвоению начального значения.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
могу, оставаясь в рамках С++, обеспечить неизменность этой строки. CC>Дык этож C# подход, для С++ надо делать иначе.
Как именно? CC>Это средство называется головной мозг.
Спасибо, на этом всё.
CC>Мне почему-то в голову такую дурость на С++ утворить не приходит.
Да-да, не приходит. Это просто короткий пример. В более длинных примерах просто будет трудноуловимый баг, который станет проявляться только, к примеру, на многопроцессорной машине.
CC>>>Поэтому не надо тащить методы работы с C# в С++ где всё совсем по другому. S>>Я в курсе, как там что в С++. Я, вообще-то, не с С# работать начал. CC>Я понимаю. Но у тебя моск уже заражён шарпом, раз ты пытаешься писать на С++ как на шарпе.
Ты ничего не знаешь о том, как я пытаюсь писать на С++.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Serginio1, Вы писали:
S>В данном случае ты говоришь об эксклюзивном ключе. Здесь есть езменяемая и неизменяемая часть. S> разделение строк на 2 типа необходимо по нескольким причинам.
Как связанна эксклюзивность ключа с тем, что ключ -- строка, а не double, например?
S>1. Хэш неизменен, а значит хранение в хэштаблице в том числе для интернирования для скорости сравнения по указателям и экономии памяти.
Про экономию памяти не понял, так как в любых хэшах бывают коллизии. А вот про хранение кэша рядом со строкой -- не ивжу что мешает так делать в С++ подходе? Я регулярно так делаю, и ничего вроде...
S>2. Для мутабельной строки как в стрингбуилдере для скорости нужно иметь выделенную память больше чем размер строки на данный момент S>для быстрого изменния длины строки.
Это всего лишь подробности реализации той самой мутабелной строки. Мне, например, нравится реализация, которая содержит коллекцию пулов буферов. Размеры буферов в каждом из пулов подобраны так, чтобы каждый следующий пул хранил строки во сколько-то раз (например в полтора) большие, чем предыдущий. Аллокация -- быстрая, освобождение -- ещё более быстрое, работа с COW...
S>3. Отсутствие синхронизации при чтении строк.
При чтении любых константных данных синхронизация вроде как не нужна...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
PD>>Отсюда ясно, что эффект от иммутабельности может быть как существенным и положительным, так и существенным и отрицательным. Если генерировать набор строк, не меняя длины исходной строки, а только заменяя в ней символы, то без иммутабельности эта задача решается на одной строке, одном буфере. С иммутабельностью мы рискуем захватить мегабайты, прежде чем проснется GC и уничтожит всю эту иммутабельную кунсткамеру. Более того, на нелюбиом тобой массиве из char (ASCIIZ то есть) эти операции можно выполнять на одном буфере даже при изменении длины строки, лишь бы только за пределы буфера не выходить. S>Совершенно верно. К счастью, обычно автор программы достаточно хорошо себе представляет, какие операции он хочет делать с текстом и насколько часто. И если ему нужно часто вносить изменения в строку, он применяет StringBuilder.
Проблема в том, что StringBuilder не имеет полноценного интерфейса для редактирования строк. Например, там нет даже поиска подстроки. О каком редактировании может идти речь? StringBuilder вообще предназначен исключительно для конструирования строк, но не для их редактирования. И я думаю, что из-за этого в Java, которая применяет тот же принцип — String + StringBuffer, появилась альтернатива String — Rope, которая с одной стороны имеет интерфейс String, но оптимизирована под редактирование. В общем в MS хотели как лучше, а получилось как всегда.
Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>В бусте как раз есть optional<T> (и умные указатели здесь не причем), и его семантика ближе к Nullable в C#, чем к указателям в С++:
Он конечно есть, но, IMHO, не так чтобы совсем-совсем необходим.
Тем не менее, это ещё раз демонстрирует, что если концепция не является совсем уж бесполезной, то её обычно реализуют как-то и в С++ библиотеке какой-нибудь
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, alexey_ma, Вы писали: S>Это подростковые фантазии. В жизни не бывает "одной библиотеки", которая решает все нужные задачи. В плюсах шансы на то, что все библиотеки в проекте будут использовать одни и те же строки, приближаются к нулю очень быстро с ростом размера проекта.
Ну ну. Это не фантазии, идеала не бывает, но это не отменяет факта что к этому надо стремиться.
S>И какое отношение отсутствие документации на терминал имеет к языку программирования? Неужели при программировании на плюсах документация волшебным образом появится из ниоткуда?
Не появиться. Не в этом дело. Отсутствие вменяемого Api у аппликации серьзно затрудняет возможность ее интеграции c дотнет. На плюсах у меня просто возможностей больше. А эта задача с терминалом не без некоторого гиммороя решилась перехватом нескольких WinApi функций. Согласитесь что проще это сделать на С++/C ? S>Вы, наверное не догадываетесь, но COM — далеко не всё, с чем может интероперировать шарп.
Еще как догадиваюсь, мало того, даже знаю какой ценой, тот же СОМ доставляет иногда не мало веселья. На собственном опыте вижу что ВНО написанный на плюсах работает бодрее, жрет меньше cpu, на порядок потребляет меньше памяти чем BHO написанный на шарпе с аналогичной функциональностью. S>Покажите мне пример того, с чем вы интероперируете на С++, и что, по вашему, никак-никак не заработает в шарпе.
Ну для начала возьмем PowerBulder (это то с чем приходиться часто работать ). Для примера лучше взять версию постарше 6 или 7. Там есть такой обьект называемый DataWindow, попытайтесь получить из него значение какого нибудь поля, именно из gui, поскольку доступа к базе нет и не будет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хм. Ссылки на объекты своего собственного типа ?
PD>
PD>public class Name
PD>{
PD> Name anotherName;
PD> //...
PD>}
PD>
А какие проблемы? Иммутабельность же транзитивна.
PD>А во-вторых, это довольно серьезное ограничение.
Пока не вижу ограничений. Покажи мне реальный сценарий, где ты хотел сделать иммутабельный тип, ссылающийся на мутабельные.
PD>Вот тут я бы высказался по поводу реализации. Мне в свое время она доставила массу не слишком приятных впечатлений. Например, надо мне эту самую строчку в верхний регистр перебросить. Но у StringBuilder нет ToUpper. Выходит, надо его ToString, а потом новый StringBuilder на основе этой строки. Или можно как-то обойтись и сделать все же inplace ?
PD>char szString[N]; PD>gets(szString); PD>strupr(szString);
PD>и ни одного лишнего байта. Можно такое сделать ?
Можно, но обычно незачем. Массовый ToUpper обычно применяется к коротким строкам, там дешевле сделать копию, чем делать inplace. Но если очень-очень хочется, то банально
static class StringBuilderHelper
{
public static void Transform(this StringBuilder sb, Func<char, char> transform)
{
for (int i = 0; i < sb.Length; i++)
sb[i] = transform(sb[i]);
}
public static void ToUpper(this StringBuilder sb)
{
sb.Transform(Char.ToUpper);
}
}
При этом мы сэкономим память ценой просада в производительности — внутри сеттера StringBuilder.this[int] происходит та самая злая магия межпоточной синхронизации, которая убивает производительность мутабл-строк.
Вообще, если профайлер тебе не показал проблемы с быстрым ростом количества строк, то искусственно продлять их время жизни в управляемой среде (в частности, внося изменения вместо создания копии) крайне не рекомендуется. Получишь обратный эффект.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
S>>В данном случае ты говоришь об эксклюзивном ключе. Здесь есть езменяемая и неизменяемая часть. S>> разделение строк на 2 типа необходимо по нескольким причинам. E>Как связанна эксклюзивность ключа с тем, что ключ -- строка, а не double, например?
Эксклюзивность связана с неизменяемостью не зависимо от типа.
Если ты хочешь найти в хэштаблице сначало по Хэшу, то и Хэш должен соответствовать значению,
если в сортированном списке ты меняешь строку, то должен изменить ее местоположение в списке.
S>>1. Хэш неизменен, а значит хранение в хэштаблице в том числе для интернирования для скорости сравнения по указателям и экономии памяти. E>Про экономию памяти не понял, так как в любых хэшах бывают коллизии. А вот про хранение кэша рядом со строкой -- не ивжу что мешает так делать в С++ подходе? Я регулярно так делаю, и ничего вроде...
Экономия при интернировании, т.к. не хронятся дубли. Если хэш лежит рядом, то и строка должна быть неизменяема, смоьри выше.
S>>2. Для мутабельной строки как в стрингбуилдере для скорости нужно иметь выделенную память больше чем размер строки на данный момент S>>для быстрого изменния длины строки. E>Это всего лишь подробности реализации той самой мутабелной строки. Мне, например, нравится реализация, которая содержит коллекцию пулов буферов. Размеры буферов в каждом из пулов подобраны так, чтобы каждый следующий пул хранил строки во сколько-то раз (например в полтора) большие, чем предыдущий. Аллокация -- быстрая, освобождение -- ещё более быстрое, работа с COW...
У меня было аналогично такому http://www.rsdn.ru/forum/philosophy/2449781.1.aspx
Но удвоение размеров при полном заполнение очень эффективное решение. S>>3. Отсутствие синхронизации при чтении строк. E>При чтении любых константных данных синхронизация вроде как не нужна...
Ну в нативе мы если захотим можем изменить любой участок памяти
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>>В бусте как раз есть optional<T> (и умные указатели здесь не причем), и его семантика ближе к Nullable в C#, чем к указателям в С++:
E>Он конечно есть, но, IMHO, не так чтобы совсем-совсем необходим.
Необходимость — это дело другое, просто я не видел что в споре Nullable vs pointer были озвучены основные различия оных. Имхо, это довольно разные вещи с частично совпадающими возможностями.
E>Тем не менее, это ещё раз демонстрирует, что если концепция не является совсем уж бесполезной, то её обычно реализуют как-то и в С++ библиотеке какой-нибудь
+1.
Здравствуйте, alexey_ma, Вы писали: _>Ну ну. Это не фантазии, идеала не бывает, но это не отменяет факта что к этому надо стремиться.
Вы говорите про обратное стремление. Вы довольны тем, что у вас есть зоопарк строк для работы с зоопарком библиотек.
А я говорю, что стремиться нужно к наличию одной-двух вменяемых реализаций строк и отсутствию проблем с интеропом, по крайней мере на таком уровне.
_>Не появиться. Не в этом дело. Отсутствие вменяемого Api у аппликации серьзно затрудняет возможность ее интеграции c дотнет. На плюсах у меня просто возможностей больше. А эта задача с терминалом не без некоторого гиммороя решилась перехватом нескольких WinApi функций. Согласитесь что проще это сделать на С++/C ?
Какое отношение это имеет к зоопарку строк? Постарайтесь сосредоточиться и отделить мух от котлет — проблемы отсутствия документации и задачи перехвата WinAPI никак не решаются ни при помощи std::string, ни CString, ни их отсутствия.
S>>Покажите мне пример того, с чем вы интероперируете на С++, и что, по вашему, никак-никак не заработает в шарпе. _>Ну для начала возьмем PowerBulder (это то с чем приходиться часто работать ). Для примера лучше взять версию постарше 6 или 7. Там есть такой обьект называемый DataWindow, попытайтесь получить из него значение какого нибудь поля, именно из gui, поскольку доступа к базе нет и не будет.
Покажите код на С++, который делает это злое волшебство. Тот самый, который никак-никак не заработает в шарпе. Я даже за деньги не буду выкачивать PowerBuilder 6 и искать в нём объект называемый DataWindow.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
PD>>Хм. Ссылки на объекты своего собственного типа ?
PD>>
PD>>public class Name
PD>>{
PD>> Name anotherName;
PD>> //...
PD>>}
PD>>
S>А какие проблемы? Иммутабельность же транзитивна.
Я не совсем пойму, как ты этой ссылке значение будешь присваивать, например, если Name A ссылается на Name B, а в том — обратно. В конструкторе такое не сделаешь, а после — это уже не будет иммутабельность.
PD>>А во-вторых, это довольно серьезное ограничение. S>Пока не вижу ограничений. Покажи мне реальный сценарий, где ты хотел сделать иммутабельный тип, ссылающийся на мутабельные.
Не понял. Как я могу такое сделать в принципе, это же бессмыслица.
PD>>Вот тут я бы высказался по поводу реализации. Мне в свое время она доставила массу не слишком приятных впечатлений. Например, надо мне эту самую строчку в верхний регистр перебросить. Но у StringBuilder нет ToUpper. Выходит, надо его ToString, а потом новый StringBuilder на основе этой строки. Или можно как-то обойтись и сделать все же inplace ?
PD>>char szString[N]; PD>>gets(szString); PD>>strupr(szString);
PD>>и ни одного лишнего байта. Можно такое сделать ? S>Можно, но обычно незачем. Массовый ToUpper обычно применяется к коротким строкам, там дешевле сделать копию, чем делать inplace.
Вот это по крайней мере звучит странно. Почему дешевле сделать копию, если ее можно не делать ?
Но если очень-очень хочется, то банально
<skipped>
Ну вручную все , что угодно можно сделать. Я же писал — вопрос о реализации. Дальше будем вручную дописывать прочие методы от string (CompareTo, Contains, IndexOf...)
S>При этом мы сэкономим память ценой просада в производительности — внутри сеттера StringBuilder.this[int] происходит та самая злая магия межпоточной синхронизации, которая убивает производительность мутабл-строк. S>Вообще, если профайлер тебе не показал проблемы с быстрым ростом количества строк, то искусственно продлять их время жизни в управляемой среде (в частности, внося изменения вместо создания копии
Это как ? Не понял. В string ??? Или в StringBuilder все же ?
Здравствуйте, Игoрь, Вы писали:
И>Проблема в том, что StringBuilder не имеет полноценного интерфейса для редактирования строк. Например, там нет даже поиска подстроки. О каком редактировании может идти речь? StringBuilder вообще предназначен исключительно для конструирования строк, но не для их редактирования. И я думаю, что из-за этого в Java, которая применяет тот же принцип — String + StringBuffer, появилась альтернатива String — Rope, которая с одной стороны имеет интерфейс String, но оптимизирована под редактирование. В общем в MS хотели как лучше, а получилось как всегда.
там есть реализация RStdingBuilder.
Так или иначе ни один класс не может реализовать все, что от него нужно, но у StringBuildera внутренности закрыты, поэтому
и пользователскую реализация сделать нельзя или сложно.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Если ты хочешь найти в хэштаблице сначало по Хэшу, то и Хэш должен соответствовать значению, S>если в сортированном списке ты меняешь строку, то должен изменить ее местоположение в списке.
Это-то понятно. Но в С++ нет никаких проблем не давать менять содержимое подобного контейнера...
S> Экономия при интернировании, т.к. не хронятся дубли. Если хэш лежит рядом, то и строка должна быть неизменяема, смоьри выше.
Так всё равно в шпрпе можно в ту же переменную другое значение присвоить... Нельзя только "на месте" поменять...
S>Ну в нативе мы если захотим можем изменить любой участок памяти
Ну пока комп внутри нативный это всегда будет можно...
Тут есть таки принципиальное, IMHO, отличие в подходах плюсов и шарпа. В одном случае предполагается вменяемость разработчика, поэтому ему предоставляется значительный контроль над тем, что и как делает его программа на самом деле. Ну да если при этом накосячил, то и сам дурак.
А в шарпе, насколько я понимаю, изначально ставилась задача возможности разработки не очень квалифицированными разработчиками, так скажем, что бы индусов не обижать
Собственно в этом состоит принципиальное отличие. А дальше уже частности идут...
Собственно говоря что тебе важнее: контроль или возможность нанимать кого попало...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>А в шарпе, насколько я понимаю, изначально ставилась задача возможности разработки не очень квалифицированными разработчиками, так скажем, что бы индусов не обижать E>Собственно в этом состоит принципиальное отличие. А дальше уже частности идут... E>Собственно говоря что тебе важнее: контроль или возможность нанимать кого попало...
Ну никто же не запрещает тебе создавать пользователькие классы и делать с ними, что хошь, так или иначе под определенные задачи все равно не хватит существующего функционала.
Просто в 90 с лишним процентов за глаза хватает существующего функционала, и глаза не разбегаются.
Много информации тоже плохо, поэтому лучше сосредоточится на глобальных проблемах.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я не совсем пойму, как ты этой ссылке значение будешь присваивать, например, если Name A ссылается на Name B, а в том — обратно. В конструкторе такое не сделаешь, а после — это уже не будет иммутабельность.
Я не совсем пойму, для чего тебе это потребовалось. В чём смысл этого? Можно иметь иммутабл дерево, можно иметь иммутабл стек. Иметь произвольный иммутабл граф иммутабл объектов — трудно, почти что невозможно. И, на первый взгляд, ненужно.
Опять же, пойми, что мы не пытаемся перехватывать все изменения и бросать исключение. Задача — описать иммутабл при помощи системы типов, так, чтобы изменить значение было просто невозможно.
PD>Не понял. Как я могу такое сделать в принципе, это же бессмыслица.
Ну вот раз бессмыслица — значит никаких проблем.
S>>Можно, но обычно незачем. Массовый ToUpper обычно применяется к коротким строкам, там дешевле сделать копию, чем делать inplace. PD>Вот это по крайней мере звучит странно. Почему дешевле сделать копию, если ее можно не делать ?
Потому, что работа над оригиналом — дорогая.
PD>Ну вручную все , что угодно можно сделать. Я же писал — вопрос о реализации. Дальше будем вручную дописывать прочие методы от string (CompareTo, Contains, IndexOf...)
Да, тут ты прав. Всё это нужно было сархитектурить по-другому.
PD>Это как ? Не понял. В string ??? Или в StringBuilder все же ?
А внутри стрингбилдера по-твоему что?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
a> M>Угу, потом пытаешься скрестить QString с bt_str и материшься трехэтажным матом
a> Угу. Бывает конечно и такое. Если самому можно определять какую библиотеку использовать то вопросы межвидового взаимодействия как правило не стоят, или решаются административным порядком. Но дело в том что я довольно много занимаюсь вопросами интеграции и взаимодействия с сторонними аппликациями ( иногда весьма старыми и экзотическими) и здесь "окружающая среда" имеет решающее значение. Я далеко не всегда могу выбирать то что мне нравиться ( в том числе иногда и сам язык),часто приходиться мириться с тем что есть. . В этом плане С++ с его многообразием библиотек более универсален чем С#.
Да ничего он не универсален. Весь этот «внешний» мир и появился из-за такой вот «универсальности». В идеальном мире, где строка была бы встроена в язык С++, броблемы QString <-> bt_str просто не появилось бы. А так, создали кучу проблем, миллион несовместимых классов строк, активно с тим все боремся, но при этом гордо: «а посмотрите, какой С++ универсальный»
Здравствуйте, jazzer, Вы писали:
J>Ну, если ориентироваться только на нормальные компиляторы, то костыли эти достаточно прямые и простые,
Да хоть на какие ориентируйся. Все равно все страшно.
Я как бы сам все видел и даже писал.
J>Но главное то, что все это внутри библиотеки и пока тебе не понадобилось туда нырнуть, пользоваться библиотекой легко и приятно и зоопарка под капотом не видно. И, имхо, то, что на таком старом языке можно написать библиотеки уровня Boost.Fusion и Boost.Proto, говорит только в пользу этого языка.
Почитал. Но так и не понял на кой черт это нужно.
Что оно может такого что не может нормальный функциональный язык с нормальным оптимизатором?
J>Но метаинформации в С++ не было изначально, просто потому что он — наследник С, а там это чуждая концепция.
Каким местом она чуждая?
Какие проблемы дать пройтись по классу во время компиляции?
J>Сам понимаешь, в язык с таким наследием добавлять новые фичи нужно очень аккуратно, иначе С++ кончит как D, который сам с собой не совместим.
Их проблема в том что они изначально толком не проектировались.
Ковбойский подход "ЙО! Я тут классную фичу придумал! Айда добавим!" никогда ни к чему хорошему не приводил.
J>Конечно, она в том или ином виде будет добавлена в язык, но в каком именно — это большой вопрос, которым нужно заниматься, а на это у комитета банально нету времени, потому что гораздо больше народу требуют многопоточности и сборки мусора (последнюю так и не успели вставить в С++0х).
Многопоточность это полезно.
А вот сборка мусора нет. Ибо мусорщик должен быть либо точным либо никаким. А в С++ точный не сделаешь. Ибо прямой доступ к памяти и прочие радости.
J>Так она и есть, или я тебя не так понял. J>Плюс контракт — это гораздо более широкое понятие, чем интерфейс. И в этом смысле класс С++ подходит для выражения концепции контракта лучше, чем просто интерфейс, потому что интерфейс редуцирует контракт до набора (причем фиксированного!) функций, что не всегда оправдано.
Чтобы задать контракт в широком смысле этого слова нужна система типов с зависимыми типами.
А это уже мягко говоря другой уровень проектирования языка. http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Main.Documentation
J>В С++ наследование — это не только наследование в классическом понимании ООП. J>Там, например, наследуются типы/тайпдефы, и тому подобное. Вспомни CRTP хотя бы.
Тем хуже для С++.
J>Это можно и сейчас dynamic_cast-ом сделать.
Что это?
WH>>К миксину привести нельзя. J>Почему? В чем смысл такого ограничения?
По тому что SRP никто не отменял.
Реализация отдельно. Контракт отдельно.
Интерфейсы это контракт. По крайней мере та его часть которую дает формализовать язык.
Миксины это чистая реализация которую в конкретном классе можно использовать, а можно и нет.
J>А чем тебя не устраивает подход ATL/WTL? J>Он, кстати, позволяет частичную реализацию интерфейса — как насчет твоих миксинов? Они должны реализовывать интерфейс полностью или частично тоже сойдет?
А нахрена?
В любом случае можно перекрыть реализацию конкретного метода в конкретном классе.
J>И если да и если ты хочешь собрать свой класс из вот таких вот частичных реализаций, ты разве не поимеешь все проблемы множественного наследования, которые есть сейчас?
Нет.
Проблемы множественного наследования исходят из нарушения SRP в дизайне языка.
У меня нарушения SRP нет.
Я могу все собрать из миксинов, могу реализовать контракты руками, могу написать свои альтернативные миксины и могу использовать различные комбинации перечисленного.
А все по тому что контракты отделены от реализации.
J>А если нет — так уж ли оно полезно, если вспомнить про какой-нть интерфейс OLE-объекта с 53 функциями?
Я таких не видел. Но в любом случае за такое нужно отрывать руки и отлучать от программирования навсегда.
J>О чем и речь
О чем?
J>Так просто наскоком такую подсистему в язык не добавить — цена ошибки слишком велика.
Просто ее нужно проектировать более серьезными силами чем пара студентов.
J>А вот когда обкатают и будет наработана достаточно большая база решений и, что более важно, граблей, тогда можно думать и о встраивании концепции в промышленные языки.
Грабля там ровно одна: Отсутствие формализации.
WH>>Но не до конца. .NET собака такая под ногами со своей кривостью путается. J>Прям как в С++
Ага. .NET как и С++ тоже никто не проектировал, а чисто навояли как придется.
J>Ну, в общем, как я и говорил энтузиастам дотнета сколько-то там лет назад ("У вас тяжкое наследие, а у нас все свежее и необремененное" — "Ничего, поговорим лет через 10"), как мы скрипим от унаследованных недостатков С++, так и явисты/дотнетчики заскрипят, когда осознают, что их новые свежие языки-платформы неидеальны, и не упрутся в их пределы и в никуда не девшиеся требования совместимости с существующим кодом (а в случае явы/дотнета — еще и с существующим байт-кодом).
Не осознают также как и С++ники.
Для того чтобы это понять нужно знать намного больше чем собственную песочницу.
J>А особенно когда еще через лет появится какая-нть модная технология, про которую все будут говорить: "Это must have, она должна быть в любом нормальном языке по умолчанию, все остальные на помойку!"
Появится может разве что виртуальная машина которую не забыли спроектировать. Вот только массы этого оценить не смогут.
Все остальное будет таким же топтанием на месте.
Ибо ни .NET ни жаба ничего нового не принесли.
Просто перепев старых идей + куча бабла на пиар.
J>(как сейчас с рефлексией, сериализацией и т.п.) а явисты/дотнетчики будут чесать репу, понимая, что на их языках невозможно по-человечески эту фичу реализовать, потому что она не будет ни с чем совместима и сломает язык.
Ты удивишься что можно реализовать на .NET'е и жабе.
Там же код во время исполнения можно генерировать... а значит можно реализовать ВСЕ!
J>Так что у С++ есть свой хорошо известный набор проблем, есть не менее хорошо известный (и зачастую вполне удобный) набор средств по их устранению/недопущению/предупреждению, и профессиональные программисты вполне комфортно себя чувствуют, хотя это и не значит, что они не будут приветствовать усилия комитета по уменьшению этого набора.
Проблемы С++ столь ужасны что их можно решить только выкинув С++ на свалку.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>"Парадокс блаба" апеллирует к зашоренности сознания и потому превосходно работает и в обратную сторону: если ты не научился усматривать необходимые конструктивные возможности в языке X, то ты их не усмотришь нигде, и хуже того — никогда не будешь уметь в полной мере использовать тот язык, которым располагаешь. В конце концов, какая разница, где именно находится тот пресловутый пунктик, которым ограничена мыслительная деятельность?
Если ты намекаешь на то что я не знаю С++ то ты мягко говоря не на того напал.
Можешь заглянуть в топ форума по С++... и это при том что я там уже не первый год почти не появляюсь.
ГВ>Вот-вот. Возвращаемся к тому, с чего начали: к внутренней структуре строки.
И как грамотная реализация строки относится к тому что строк должно быть много?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, alexey_ma, Вы писали: _>>Ну ну. Это не фантазии, идеала не бывает, но это не отменяет факта что к этому надо стремиться. S>Вы говорите про обратное стремление. Вы довольны тем, что у вас есть зоопарк строк для работы с зоопарком библиотек. S>А я говорю, что стремиться нужно к наличию одной-двух вменяемых реализаций строк и отсутствию проблем с интеропом, по крайней мере на таком уровне.
У _>>Не появиться. Не в этом дело. Отсутствие вменяемого Api у аппликации серьзно затрудняет возможность ее интеграции c дотнет. На плюсах у меня просто возможностей больше. А эта задача с терминалом не без некоторого гиммороя решилась перехватом нескольких WinApi функций. Согласитесь что проще это сделать на С++/C ? S>Какое отношение это имеет к зоопарку строк? Постарайтесь сосредоточиться и отделить мух от котлет — проблемы отсутствия документации и задачи перехвата WinAPI никак не решаются ни при помощи std::string, ни CString, ни их отсутствия.
Ясень пень что не решают, но иногда помогают. Разговор вроде был о возможности выбора оптимальной реализации строк в зависимости от задачи и о проблемах интеграции. Так вот, когда я из хука лезу в Сlarify11 (он почему-то написан на MFC 7.0) чтобы прочитать там пару строчек из ObjectivGrid я использую СString ( мало того я вынужден компилировать хук с той же версией MFC что и Сlarify — иначе не работает), если работаю с CОМ — использую BSTR и т.п — так понятно? S>>>Покажите мне пример того, с чем вы интероперируете на С++, и что, по вашему, никак-никак не заработает в шарпе.
Про замечательный интероп шарпа c CОМ на примере ВНО, я полагаю замнем _>>Ну для начала возьмем PowerBulder (это то с чем приходиться часто работать ). Для примера лучше взять версию постарше 6 или 7. Там есть такой обьект называемый DataWindow, попытайтесь получить из него значение какого нибудь поля, именно из gui, поскольку доступа к базе нет и не будет. S>Покажите код на С++, который делает это злое волшебство. Тот самый, который никак-никак не заработает в шарпе. Я даже за деньги не буду выкачивать PowerBuilder 6 и искать в нём объект называемый DataWindow.
Не могу я код показать, но он есть и работает Возможно что подобный код какой нибудь гений может написать и на шарпе , но вряд-ли он будет короче и понятней. Да чего там PowerBuilder, набросайте VB6 апликацию с MSFlexGlig и попробуйте получить из этого грида пару строчек или хотя-бы текст какого нибудь Label тоже из VB6. К сожалению ( или к счастью) мир пока не весь еще дотнет, с дотнетом кстати интегрировться легко.
. В этом плане С++ с его многообразием библиотек более универсален чем С#.
