Здравствуйте, Игoрь, Вы писали:
И>Мы сейчас говорим о конкретных языках или "вообще"? Если говорить "вообще", то я могу согласиться, что в С++ константность — это сбоку бантик, который легко снимается конст-кастом. И это все дело можно было бы сделать намного лучше, делая сейчас и не думая об обратной совместимости.
Пока есть указатели в С++ никогда не сделать неснимаемый const.
Нельзя сделать напрямую — сделаем через память.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали: S>>В С++ по давней традиции, смешивают две эти сущности в одну. Итоговый результат одинаково плохо выполняет обе задачи. CC>Мы сейчас сравниваем вшитую в язык имплементацию, от которой в общем то никуда не деться и дефолтную библиотечную имплементацию, которой никто не заставляет пользоваться.
Хм. Мы сейчас сравниваем два фреймворка. В одном вшита реализация обоих примитивов — "строка как значение" и "конструктор текстов". Плюс, если рассматривать С#, есть еще и два синтаксиса строковых констант для разных случаев.
В другом фреймворке вшита одна реализация строковых констант и одна реализация класса строк. Обе вшитых вещи бесконечно убоги — я уже написал, почему.
Мало того, поскольку традиции разделения примитивов в С++ нет, то и "недефолтные" реализации в массе своей страдают от всех недостатков "дефолтных". Смотреть, например, в класс CString. К сожалению, этот подход обеспечивает бесполезность написания хороших "недефолтных" реализаций — они будут замкнуты в своём мирке. К примеру, нельзя опубликовать библиотеку строковых алгоритмов, оптимизированных под иммутабельные строки — они не будут нормально интероперировать с другими библиотеками.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, CreatorCray, Вы писали:
S>>Зато гарантированная константность позволяет использовать хеш строки в качестве части ключа. CC>Для этого не обязательно вообще все строки принудительно делать константными.
Обязательно. Еще раз: реализация строк в С++ — убожество с точки зрения архитектуры.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 0xC0000005, Вы писали:
C>Контракт класса? Сами термин придумали? В литературе по контрактному программированию ни слова о "Контрактах класса", можно разузнать что такое контракт класса с первоисточниками?
Сразу скажу, что всю ветку не читал, только это сообщение, так что прошу прощения за возможное "не в тему".
Контракт чего бы то ни было — это, по сути, требования к этому, ожидания, которым оно будет удовлетворять всегда, даже при смене реализации.
Если говорить о первоисточниках С++, то можно открыть стандарт и посмотреть, например, главу "Container requirements" — там как раз описываются контракты всех стандартных контейнеров, т.е. набор методов, их сложность, пре-пост-утверждения, смысл (!) каждого метода, а также, помимо методов, еще и типы (например, value_type), что, несомненно, шире интерфейса в понимании Java (просто набор виртуальных функций).
Здравствуйте, Sinclair, Вы писали:
ГВ>>Арифметику и логические операции можно добавить по вкусу. S>Кстати, там лифтинг заработает? S>Лифтинг — это когда все операторы, определенные для типа T, автоматически определяются для типа Nullable<T> — соответствующим образом, то есть возвращают Nullable<T>, который null, когда хотя бы один из операндов Null. S>Но если какого-то оператора у T нет, то ошибка будет только при попытке вызвать аналогичный оператор для Nullable<T>, а не при попытке сконструировать Nullable<T>.
Да, можно. Только нужно будет определить все операторы непосредственно в Nullable. Тогда ошибки (буде таковые возникнут) будут выбрасываться в месте вызова соответствующих операторов. Единственное, в чём я не уверен — в 100% переносимости.
Выглядит это приблизительно так:
// Оператор Nullable::operator ==template<typename U>
Nullable<bool> operator == (const U &rhs) const
{
if (isNull() || ::isNull(rhs))
return Nullable<bool>();
return val_ == (const T &)rhs;
}
// Пара свободных функций:template<typename T> inline bool isNull(const Nullable<T> &v)
{
return v.isNull();
}
template<typename T> inline bool isNull(const T &)
{
return false;
}
// Пример использования:struct X { int a; int b; };
void foo() {
Nullable<X> v1, v2; // Ошибки нетif (v1 == v2) // Здесь ошибка
{
}
}
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, CreatorCray, Вы писали:
WH>>Тут С++ мочат CC>Уже дофига лет... И всё никак
Эпическая битва, можно сказать.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Только нужно будет определить все операторы непосредственно в Nullable.
Или как набор свободных операторов, функций и т.п.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, CreatorCray, Вы писали: CC>>>Вот только какая может быть выгода от именно таких строк в С++ мне например неясно. S>>Очень простая. Например, иммутабельные строки могут быть ключами в хештаблицах. CC>Опять приходим к вопросу: если две одинаковые (в итоге) строки получены из разных источников, будут ли они ссылаться на одну и ту же область памяти?
[так в жабе, в шарпе — не помню]
Скажем так, они могут ссылаться на один и тот же буфер. Например, если одна из них ранее была получена методом substring другой. Так как этот метод не создает нового буфера. Он просто создает новый объект String на основе того же буфера чаров, но с другим индексом начала в этом буфере и другой длиной.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Eugeny__, Вы писали: E__>>Кстати, а что мешает и варианты "abc" и "abc2" хранить в одной области(имеется ввиду сами буфферы, объекты будут разными в любом варианте)? E__>>Длина заключена в объекте(а не определяется положением терминирующего символа), при этом строки никогда не будут изменены. E__>>Так ли это в реале, не знаю, но ничего не мешает так устроить. S>В Java именно так работает выделение подстроки.
Ну да, знаю. То есть, если "abc" получено из "abc2", то буфер они будут один использовать. А вот при создании, по ходу, нет, хотя и можно было бы так сделать.
У такого подхода есть как плюсы, так и минусы. Основной плюс в том, что несмотря на неизменяемость строк, если в программе много строк, которые созданы как подстроки, экономится память(а во многих задачах строки составляют большинство данных). Основной минус в том, что если есть хоть одна активная ссылка на махонькую подстроку, которая ранее была выделена из огромной(на которую ссылок уже нет), то GC не сможет освободить весь буфер.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Игoрь, Вы писали:
И>Не, ну хорошо, кто бы спорил. Раз подходит для каких-то задач, замечательно. Мне такое пока не нужно.
Нужно просто ты сам пока этого не понимаешь.
Дело в том что тут работает парадокс блаба
.
Те пока ты смотришь на мир с точки зрения С++ ты будешь видеть только более слабые языки и языки с не понятными заморочками.
И>Вот как раз с многопоточностью и строками я как-то никогда проблем не имел.
Я тоже но уж больно сильно это напрягает мою паранойю.
А мне она нужна для того чтобы задачу обсчитывать, а не поведение строк.
И>Иногда для оптимизации и не такое приходится делать, например выкидывать std::vector, из-за того, что тот свой буфер зануляет.
А что reserve + push_back не помогает?
А в случае с функциональным языком для которого не поленились сделать нормальный оптимизатор это вообще не вопрос.
Просто пишешь что-то вроде:
def arr = array(1000, i => i * i);
И получаешь массив заполненный тем чем тебе надо. Причем память не будет предварительно обнулена.
И>Например есть строки размером от 50КБ до 5МБ, надо найти и вырезать какие-то куски без лишних релокейшинов. Все что мне нужно — хоть простой набор алгоритмов над текстовым writable буфером.
Это решается умным представлением строк. Одна из возможных структур данных называется rope.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
S>Мало того, поскольку традиции разделения примитивов в С++ нет, то и "недефолтные" реализации в массе своей страдают от всех недостатков "дефолтных". Смотреть, например, в класс CString. К сожалению, этот подход обеспечивает бесполезность написания хороших "недефолтных" реализаций — они будут замкнуты в своём мирке. К примеру, нельзя опубликовать библиотеку строковых алгоритмов, оптимизированных под иммутабельные строки — они не будут нормально интероперировать с другими библиотеками.
1) IMHO, если бы от такого разделения на константные строки и фабрики строк была какая-то реальная польза, в C++ уже бы давно были бы популярны такие библиотеки. В книжках бы были кучи примеров, как это реализовать и т. п.
Тем более, что никаких принципиальных трудностей на этом пути нет...
2) Хотелось бы понять, чем строка отличается от числа. Почему числа могут представлять сами себя и иметь модифицирующие себя же операторы, а строки -- нет? Что этому препятствует? Эффективность? Какая-то особенность семантики строк? Что-то ещё?
3)Должны ли, кроме строк, ещё и массивы букв иметь иммутабельную семантику? Если да, то почему это не так в большинстве языков, во всяком случае? Если нет, то в чём принципиальная разница между массивом букв и строкой?
А то ты всё каким-то декларациями кидаешься, что что-то там убогое, а что-то не убогое. А это как-то не убеждает. Скорее похоже больше на то, что изменяемые строки в твоём любимом языке просто не смогли эффективно реализовать...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, criosray, Вы писали:
C>Я не сомневаюсь, что можно, но между можно и есть очень большая разница.
Эх, у старых, популярных, обременнённых годами истории велосипедостроительства языков "можно + нет =def= НЕ НУЖНО!!!"
Так как воспроизвести шарповую схему работы со строками на С++ проблемы никакой нет, но не пользуется оно популярностью, то это обозначает, что в данном случае преимущества не ясны, так скажем...
Может быть ты их понятно расскажешь? То, что на совпадение указателей, в случае идентичных строчек, рассчитывать нельзя мы уже выяснили... Что ещё "является" преимуществом иммутабельных строк?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, CreatorCray, Вы писали:
C>>Счетчик в буфере? Это как? Объясните на пальцах, если не сложно. CC> Ты точно на С или С++ писал? Или как работать с памятью и указателями уже забыл?
IMHO, он просто кушать хочет...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Sinclair, Вы писали:
S>Да-да, вы как раз вносите путаницу. Конечно же, алгоритм, заложившийся на константность объекта, никак не сможет работать с неконстантым. Например, из константности мы можем вывести возможность не делать блокировок при обращении; можем полагаться на то, что хеш будет неизменным; много на что еще можем полагаться. Неконстантность ничего этого не даёт, поэтому алгоритмы на С++ невозможно оптимизировать подобным образом.
Тем не менее в С++ именно так и делают...
Единственная проблема -- это разделяемая между нитями константная строка, которую иногда таки меняют...
Но такие же проблемы вызывают любые другие данные. Например, разделяемое между нитями число...
Для чисел же мы не нуждаемся в NumberBuildere? Чем строки так сильно отличаются?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, WolfHound, Вы писали:
И>>Не, ну хорошо, кто бы спорил. Раз подходит для каких-то задач, замечательно. Мне такое пока не нужно. WH>Нужно просто ты сам пока этого не понимаешь. WH>Дело в том что тут работает парадокс блаба
. WH>Те пока ты смотришь на мир с точки зрения С++ ты будешь видеть только более слабые языки и языки с не понятными заморочками.
Опять мозговедение?
"Парадокс блаба" апеллирует к зашоренности сознания и потому превосходно работает и в обратную сторону: если ты не научился усматривать необходимые конструктивные возможности в языке X, то ты их не усмотришь нигде, и хуже того — никогда не будешь уметь в полной мере использовать тот язык, которым располагаешь. В конце концов, какая разница, где именно находится тот пресловутый пунктик, которым ограничена мыслительная деятельность?
И>>Например есть строки размером от 50КБ до 5МБ, надо найти и вырезать какие-то куски без лишних релокейшинов. Все что мне нужно — хоть простой набор алгоритмов над текстовым writable буфером. WH>Это решается умным представлением строк. Одна из возможных структур данных называется rope.
Вот-вот. Возвращаемся к тому, с чего начали: к внутренней структуре строки.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
S>Еще раз: реализация строк в С++ — убожество с точки зрения архитектуры.
Знайте — истина в том,
Что повторено трижды подряд!
(c) Л. Кэррол, Охота на Снарка
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Sinclair, Вы писали:
S>>Мало того, поскольку традиции разделения примитивов в С++ нет, то и "недефолтные" реализации в массе своей страдают от всех недостатков "дефолтных". Смотреть, например, в класс CString. К сожалению, этот подход обеспечивает бесполезность написания хороших "недефолтных" реализаций — они будут замкнуты в своём мирке. К примеру, нельзя опубликовать библиотеку строковых алгоритмов, оптимизированных под иммутабельные строки — они не будут нормально интероперировать с другими библиотеками.
E>1) IMHO, если бы от такого разделения на константные строки и фабрики строк была какая-то реальная польза, в C++ уже бы давно были бы популярны такие библиотеки. В книжках бы были кучи примеров, как это реализовать и т. п. E>Тем более, что никаких принципиальных трудностей на этом пути нет...
Есть, причем офигеть какие.
1)Совместимость. Даже если сделать immutable-строки, все равно во многих местах понадобится передавать char*. Если этот char* отдавать из внутреннего буфера, то попа ибо от иммутабельности ничего не останется. Если копировать, то перфоманс просядет заничтельно.
2)Управление памятью. Если выполнить a = b + c для строк, то кто будет освобождать b и с? Повесить все это на shared_ptr — тормоза начнутся похлеще .net_овсих
E>2) Хотелось бы понять, чем строка отличается от числа. Почему числа могут представлять сами себя и иметь модифицирующие себя же операторы, а строки -- нет? Что этому препятствует? Эффективность? Какая-то особенность семантики строк? Что-то ещё?
Где такую траву берешь? Какие у чисел возожности по модификации себя? Ты разыве можешь написать 1.setBit(4)?
В том то и дело что в большинстве программ строкам нужна семантика значений, как у чисел. Только в малом проценте нужна семантика массива.
E>3)Должны ли, кроме строк, ещё и массивы букв иметь иммутабельную семантику? Если да, то почему это не так в большинстве языков, во всяком случае?
Не недо показвать свою безграмотность. В некоторых языках строки ассоциируются не с массивами, а с immutable списками. Ты же смотришь на строки только как на массивы байт. E>Если нет, то в чём принципиальная разница между массивом букв и строкой?
Огромная разница.
Здравствуйте, Erop, Вы писали: E>1) IMHO, если бы от такого разделения на константные строки и фабрики строк была какая-то реальная польза, в C++ уже бы давно были бы популярны такие библиотеки.
от этого есть реальная польза. И во фреймворках, разработанных после С++, такое разделение уже существует пятнадцать лет. E>В книжках бы были кучи примеров, как это реализовать и т. п. E>Тем более, что никаких принципиальных трудностей на этом пути нет...
Принципиальные трудности есть. Ты можешь ставить мне сколько угодно минусов, но от этого факты не перестанут быть фактами: сделать мало-мальски полезные иммутабельные строки в плюсах не получится. Из-за того, что с самого начала были допущены архитектурные просчёты.
E>2) Хотелось бы понять, чем строка отличается от числа. Почему числа могут представлять сами себя и иметь модифицирующие себя же операторы, а строки -- нет? Что этому препятствует? Эффективность? Какая-то особенность семантики строк? Что-то ещё?
Иммутабельная строка как раз ничем не отличается от числа. Числа не имеют модифицирующих себя операторов. Попробуй изменить число 47586.
E>3)Должны ли, кроме строк, ещё и массивы букв иметь иммутабельную семантику? Если да, то почему это не так в большинстве языков, во всяком случае? Если нет, то в чём принципиальная разница между массивом букв и строкой?
Принципиальная разница — в контракте. Массив — это абстракция хранения. Про сценарии использования строки мы знаем гораздо больше, благодаря чему можем выбрать более вменяемую реализацию. То, что в С/С++ вшитые в язык строки представлены массивами — это незначительная подробность. В Хаскеле строки устроены совершенно по-другому, в результате операция конкатенации, к примеру, стоит O(1). В отличие от вашего "суперэффективного" C++.
E>А то ты всё каким-то декларациями кидаешься, что что-то там убогое, а что-то не убогое. А это как-то не убеждает. Скорее похоже больше на то, что изменяемые строки в твоём любимом языке просто не смогли эффективно реализовать...
Изменяемые строки в моём любимом языке реализовали вполне эффективно — см StringBuilder.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Ты точно на С или С++ писал? Или как работать с памятью и указателями уже забыл?
