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

MK>Здравствуйте, 0xC0000005, Вы писали:

C>>Здравствуйте, criosray, Вы писали:
C>>...
C>>>Специально для Вас выделил ключевое.
C>>Вы так умело затёрли вашу цитату, выделю главное, и больше не мозольте эту тему, вы ПИСАЛИ:
C>>

C>>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.

C>>Потом вы пишете
C>>

C>>А никто и не утверждал, что интерфейс является полным контрактом класса

C>>Не будем углубляться в аспекты русского языка, но если к примеру колесо это неотьемлемая часть машины (давайте не разводить демагогию о том какие бывают машины), то нельзя написать:
C>>Колесо — это чисто машина.
MK>По такой логике criosray должен был написать, что интерфейс — это чисто класс. Вроде такого не было

Он написал что интерфейс это чисто контракт, а не класс, я продолжил логику показывая что связь Is Contained не является IS A

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


C>>>Не будем углубляться в аспекты русского языка, но если к примеру колесо это неотьемлемая часть машины (давайте не разводить демагогию о том какие бывают машины), то нельзя написать:
C>>>Колесо — это чисто машина.
MK>>По такой логике criosray должен был написать, что интерфейс — это чисто класс. Вроде такого не было

C>Он написал что интерфейс это чисто контракт, а не класс, я продолжил логику показывая что связь Is Contained не является IS A

Что за бред? При чем тут агрегирование?? Вы вообще понимате ЧТО пишете? А то меня начинают грызть смутные сомнения по этому поводу.

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


C>Вы так умело затёрли вашу цитату, выделю главное, и больше не мозольте эту тему, вы ПИСАЛИ:

C>

C>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.

C>Потом вы пишете

C>

C>А никто и не утверждал, что интерфейс является полным контрактом класса

Почему Вы упорно не желаете читать дальше первого предложения?

Читайте и перечитывайте пока до Вас не дойдет смысл сказанного:

Как минимум класс может реализовать множество интерфейсов и каждый из них является контрактом сам по себе

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

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


C>>Вы так умело затёрли вашу цитату, выделю главное, и больше не мозольте эту тему, вы ПИСАЛИ:

C>>

C>>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.

C>>Потом вы пишете

C>>

C>>А никто и не утверждал, что интерфейс является полным контрактом класса

C>Почему Вы упорно не желаете читать дальше первого предложения?

C>Читайте и перечитывайте пока до Вас не дойдет смысл сказанного:


C>

C>Как минимум класс может реализовать множество интерфейсов и каждый из них является контрактом сам по себе

Вы нагло увиливаете от прямого ответа, грубите итп, у меня закрадывается мнение что с вами лучше не вести такие беседы.
Вопрос:
Интерфейс это контракт сам по себе? (как вы писали)
Или интерфейс это только часть контракта? (как вы тоже писали)

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

И просьба — либо ответ на поставленный вопрос и потом ваши аргументы, либо не пишите вообще и будем считать что мы друг друга не понимаем.

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

C>Вы нагло увиливаете от прямого ответа, грубите итп, у меня закрадывается мнение что с вами лучше не вести такие беседы.
Нет, это Вы не способны прочитать один маленький абзац где я объясняю, что:
1. Интерфейс — это контракт класса.
2. Полный контракт класса состоит из совокупности всех контрактов класса — все интерфейсов-контрактов, всех код-контрактов.

Вам по прежнему не понятно? Тогда я умываю руки — если человек не может сложить в уме 2 и 2, и получить в результате 4, то что-то объяснять ему — пустая трата времени.

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

E>>Ну и так далее...
S>Ну, то, что нет предела совершенству — это как бы понятно. Но наука на месте не стоит. Пока что наиболее развитым формализмом для представления "просто строк" является уникодовская цепочка. В строках С++ сделано сразу несколько принципиальных ошибок:
S>0. Они не immutable.
S>1. Они слишком сильно сосредоточены на бинарном представлении.

Не стоит мерить С++ мерками С#. В С++ давным-давно есть встроенное в сам язык средство для shallow/deep immutability, а именно модификатор const. Соответственно, если тебе нужна immutable строка, то достаточно написать что-то такое:

const std::string &str = string(src);

А в С# для этого пришлось городить огород в виде двух классов: String и StringBuilder. Лично мне, как пользователю, больше нравится С++ подход, когда константный и не констатный интерфейсы реализуются в одном классе (для произвольного объекта), и доступность/недоступность того или иного интерфейса определяется спец модификатором при определении объекта. Хотя, конечно, здесь все тоже не очень гладко.

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

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

E>>>Ну и так далее...
S>>Ну, то, что нет предела совершенству — это как бы понятно. Но наука на месте не стоит. Пока что наиболее развитым формализмом для представления "просто строк" является уникодовская цепочка. В строках С++ сделано сразу несколько принципиальных ошибок:
S>>0. Они не immutable.
S>>1. Они слишком сильно сосредоточены на бинарном представлении.

И>Не стоит мерить С++ мерками С#. В С++ давным-давно есть встроенное в сам язык средство для shallow/deep immutability, а именно модификатор const. Соответственно, если тебе нужна immutable строка, то достаточно написать что-то такое:
И>

И>const std::string &str = string(src);
И>

Это совсем не то. В данном случае запрещено вызывать методы над этой строкой.
В С# разрешено:

var str = "abc";
var str2 = str.Replace('a','b'); // тут создается новая строка


И>А в С# для этого пришлось городить огород в виде двух классов: String и StringBuilder. Лично мне, как пользователю,

То, как сделано в С# — ГОРАЗДО лучше. Строки обязаны быть immutable по той причине, что:
var str = "abc";
var str2 = "abc2";
ссылаются на один и тот же участок памяти str == str2 true.
Но это НИ В КОЕМ случае не должно запрещать операций над строками, как это происходит в С++ с const std::string...

StringBuilder представляет строку в виде полноценного связного списка char`ов, позволяя тем самым модифицировать ее за линейное время (в отличии от std::string).

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


C>То, как сделано в С# — ГОРАЗДО лучше. Строки обязаны быть immutable по той причине, что:
C>var str = "abc";
C>var str2 = "abc2";
C>ссылаются на один и тот же участок памяти str == str2 true.

Опечатка. str2 = "abc" конечно же.

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

C>Это совсем не то. В данном случае запрещено вызывать методы над этой строкой.
Неа. Запрещено вызывать методы, меняющие эту строку.

C>Но это НИ В КОЕМ случае не должно запрещать операций над строками, как это происходит в С++ с const std::string...
Подходы разные. В std::string все заточено на изменение этой же строки.
В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.
Вот только какая может быть выгода от именно таких строк в С++ мне например неясно.

C>То, как сделано в С# — ГОРАЗДО лучше. Строки обязаны быть immutable по той причине, что:
C>var str = "abc";
C>var str2 = "abc2";
C>ссылаются на один и тот же участок памяти str == str2 true.
Эээээ....

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

C>>Это совсем не то. В данном случае запрещено вызывать методы над этой строкой.
CC>Неа. Запрещено вызывать методы, меняющие эту строку.
Именно то, о чем я и говорил.

C>>Но это НИ В КОЕМ случае не должно запрещать операций над строками, как это происходит в С++ с const std::string...
CC>Подходы разные. В std::string все заточено на изменение этой же строки.
CC>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.
CC>Вот только какая может быть выгода от именно таких строк в С++ мне например неясно.
Конечно никакой — ведь std::string не могут использовать общий буффер, как это делается в дотнет.

C>>То, как сделано в С# — ГОРАЗДО лучше. Строки обязаны быть immutable по той причине, что:
C>>var str = "abc";
C>>var str2 = "abc2";
C>>ссылаются на один и тот же участок памяти str == str2 true.
CC>Эээээ....
Да, опечатка.

var str = "abc";
var str2 = "abc";

Вот так они будут ссылаться на один и тот же буфер. Тем самым будет использовано всего 6 байт под буфер вместо 12, как это было бы в С++ (впрочем, std::string даже не юникодный, так что там было бы 3+3).

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

C>>Но это НИ В КОЕМ случае не должно запрещать операций над строками, как это происходит в С++ с const std::string...
CC>Подходы разные. В std::string все заточено на изменение этой же строки.
CC>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.
Кстати, хотел бы я посмотреть как бы это работало без дикого оверхеда в виде shared_ptr.

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

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


C>>>Целые числа и числа с плавающей запятой это разные понятия.

ГВ>>Почему? И то, и другое суть "число".
C>Число это слишком обобщенное понятие. Даже школьники знают, что числы бывают целыми, дробными, с плавающей запятой, комплексными.
C>А строки "они и в африке" строки.
гм... неужто это говорит программист???
неее, не верю. Он прикалывается.

ГВ>>"В общем" — одно. А вот с точки зрения компьютера (то есть — реализаций) этих самых "строк" может быть великое множество. А для человека все они будут выражать одну и ту же абстракцию — строку.
C>Нет, не может их быть великое множество. Заканчивайте фантазировать.

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

C>>>>Целые числа и числа с плавающей запятой это разные понятия.

ГВ>>>Почему? И то, и другое суть "число".
C>>Число это слишком обобщенное понятие. Даже школьники знают, что числы бывают целыми, дробными, с плавающей запятой, комплексными.
C>>А строки "они и в африке" строки.
M_>гм... неужто это говорит программист???
M_>неее, не верю. Он прикалывается.

Нет, не прикалываюсь. Фундаментальный тип строка — один единственный. Реализации могут различаться.

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

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

C>>Вы нагло увиливаете от прямого ответа, грубите итп, у меня закрадывается мнение что с вами лучше не вести такие беседы.
C>Нет, это Вы не способны прочитать один маленький абзац где я объясняю, что:
C>1. Интерфейс — это контракт класса.
C>2. Полный контракт класса состоит из совокупности всех контрактов класса — все интерфейсов-контрактов, всех код-контрактов.

C>Вам по прежнему не понятно? Тогда я умываю руки — если человек не может сложить в уме 2 и 2, и получить в результате 4, то что-то объяснять ему — пустая трата времени.

Контракт класса? Сами термин придумали? В литературе по контрактному программированию ни слова о "Контрактах класса", можно разузнать что такое контракт класса с первоисточниками?

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

E>>Ну и так далее...
S>Ну, то, что нет предела совершенству — это как бы понятно. Но наука на месте не стоит. Пока что наиболее развитым формализмом для представления "просто строк" является уникодовская цепочка. В строках С++ сделано сразу несколько принципиальных ошибок:
S>0. Они не immutable.
S>1. Они слишком сильно сосредоточены на бинарном представлении.

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

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

E>>>Ну и так далее...
S>>Ну, то, что нет предела совершенству — это как бы понятно. Но наука на месте не стоит. Пока что наиболее развитым формализмом для представления "просто строк" является уникодовская цепочка. В строках С++ сделано сразу несколько принципиальных ошибок:
S>>0. Они не immutable.
S>>1. Они слишком сильно сосредоточены на бинарном представлении.

S>>Строки дотнета тоже не лишены недостатков, но об этих недостатках дефолтным строкам стандартной библиотеки плюсов еще приходится только мечтать.
M_>было бы странно, если в дотнете недостатки были бы хуже
M_>учитывая, когда кто из них появился.

Да это просто очень сложно — почти не возможно сделать хуже, чем тот зоопарк, что есть в С++.

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

C>Это проблема языка или IDE? Я работал под расширениями емакса, которые производят все операции проверки шаблона в редакторе, так что это далеко не проблема языка, а среды разработки.
пожалуйста, ткни пальцем где на ЭТО можно посмотреть! Воткну себе в емакс!
Давно что-то подобное хочу.

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

И>Не стоит мерить С++ мерками С#. В С++ давным-давно есть встроенное в сам язык средство для shallow/deep immutability, а именно модификатор const. Соответственно, если тебе нужна immutable строка, то достаточно написать что-то такое:
И>

И>const std::string &str = string(src);
И>

И>А в С# для этого пришлось городить огород в виде двух классов: String и StringBuilder.
Не стоит мерить дотнет мерками C++.
String и StringBuilder имеют принципиально разное поведение, которое не сводится к запрету вызова неконстантных мемберов. В частности, у них разная трактовка идентичности.
Иммутабельность строк позволяет делать крайне эффективными различные алгоритмы.
И>Лично мне, как пользователю, больше нравится С++ подход, когда константный и не констатный интерфейсы реализуются в одном классе (для произвольного объекта), и доступность/недоступность того или иного интерфейса определяется спец модификатором при определении объекта. Хотя, конечно, здесь все тоже не очень гладко.
Совершенно верно. Не очень гладко — это еще слабо сказано.

Здравствуйте, CreatorCray, Вы писали:
CC>Вот только какая может быть выгода от именно таких строк в С++ мне например неясно.
Очень простая. Например, иммутабельные строки могут быть ключами в хештаблицах.
Вообще, многие алгоритмы шибко выигрывают от того, что иммутабельность известна заранее.

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

C>>>Но это НИ В КОЕМ случае не должно запрещать операций над строками, как это происходит в С++ с const std::string...
CC>>Подходы разные. В std::string все заточено на изменение этой же строки.
CC>>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.
CC>>Вот только какая может быть выгода от именно таких строк в С++ мне например неясно.
C>Конечно никакой — ведь std::string не могут использовать общий буффер, как это делается в дотнет.
Какая в этом выгода?
Не, ну если у тебя в проге есть куча одинаковых строк, раскиданных по всему коду то да, на спичках сэкономить можно.
А так смысла особого не видно.
Кстати, если у тебя в коде будут две одинаковые строки, но одна прочитана из файла а вторая собрана из кусочков то они тоже на один и тот же буфер ссылаться будут?

C>Вот так они будут ссылаться на один и тот же буфер. Тем самым будет использовано всего 6 байт под буфер вместо 12, как это было бы в С++
В С++ для кода:

const char* str = "abc";
const char* str2 = "abc";

в случае включения опции Enable string pooling тоже будет str == str2

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

Кроме того, сталкивался с реализацией STL в которых basic_string сделан через COW с подсчетом ссылок.

C> (впрочем, std::string даже не юникодный, так что там было бы 3+3).
Базовой реализации строк в STL на это вообще пофигу — хоть UTF32 на них реализуй.