Здравствуйте, kedik, Вы писали:
K>>>1) Какой стандарт "строк" т.е. кодировки текста возмем за основу? UTF-8? UTF-16? UTF-32? а как на счет остальных? IT>>Юникод вполне подойдёт. K>Какой Юникод? 2.x? 3.x? — UTF-8? UTF-16? UTF-32?
Юникодный юникод. Пойми простую вещь. Я без понятия кокой юникод у китайцев и японцев. Я даже разбираться не хочу. Но вот на этом сайте one hundred percent работает мой код, в котором такой проблемой, я тебя уверяю, я не озабачивался.
K>С++ — это язык системного уровня — и в нем все быты и байты. Если при разработке это напрягает, значит С++ явно не нужен...
Это не так. По крайней мере это было не так 5-10 лет назад. Сегодня eao197 нас убеждает в том, что якобы C++ все последние 20 лет использовался не по назначению. Я в это не верю. Более того, я протестую! В своё время я принял плюсы как ману и делал на них примерно те же задачи, которые я делаю и сейчас. И делал я это не день и не два, а более 10 лет (в сумме вместе с C примерно лет 14), методично, практически каждый день.
K>Взглянуть то на System.String и System.DateTime я могу, только как они решат мои задачи на Sun и HP например при хиром алгоритме обработки фалов на диске, к примеру?
Тогда взгляни на Java.
K>PS. Решение абстрактых проблем это конечно интересно и увлекательно... только за решения таких проблем платят исключительно абстрактные деньги... котороый можно потратить на все что угодно... чисто абстрактно конечно
Практика, друг мой, только практика, циничная практика.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[31]: Tcl как обоснование ненужности поддержки компонентности в С++
Это примерно как слово художник от слова "худо", так и std::string — это стандарт от слова "консенсус". Ну вот надо было всех удовлетворить. Удовлетворили, получили std::string.
C>А как ты думаешь комитет поступил? Они как раз взяли за пример строки из других языков, в результате в интерфейсе std::string сейчас 84 публичных метода. При правильном проектировании их число уменьшается до пары десятков, а остальное становится алгоритмами (см. flex_string у Александреску).
Здесь мне даже комментировать не хочется
C>А самого идеального решения не существует. Например, refcount-строки часто неэффективны в многопоточных приложениях, а SSO может приводить к сильному замедлению в дегенеративных случаях.
Самая эффективная реализация строки, которая мне попадалась как раз была сделана на рефкаунтерах — CString из MFC. Может меня, конечно, не сильно проблемы многозадачности волновали, а может в многозадачной версии библиотеки CString была специально под это заточена... но меня это никогда не волновало.
C>Да, примерно так и есть. Комитет попытался найти золотую середину — получилось... средне.
Получился у комитета, как всегда, консенсус.
C>Но это не так важно — в С++ есть все средства, чтобы это компенсировать.
Я понимаю. Закат солнца вручную, впрочем как и возможность валить лобзиком Беловежскую пущу ещё никто не отменял.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[23]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, Cyberax, Вы писали:
C>Стандартный пример для mutable — кэши и счетчики ссылок. Там mutable как раз очень нужен и вполне логичен — так как изменение членов объекта не приводит к изменению его инварианта.
А зачем данные, не влияющие на изменение инварианта, вообще хранить в объекте. Никогда не задумывался, что в этом есть некоторое противоречие?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[32]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, IT, Вы писали:
E>>Стандарт C++ был принят в 1998 году. С тех пор прошло всего восемь лет.
IT>1998 — 13 = 1985.
Ну давай тогда для справедливости скажем, что работа по стандартизации C++ началась в 1989 году. Т.е. спустя четыре года после выхода первой коммерческой версии компилятора C++. Для C# ANSI/ISO стандарта нет. Для Java так же.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[32]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, IT, Вы писали:
IT>Это не так. По крайней мере это было не так 5-10 лет назад. Сегодня eao197 нас убеждает в том, что якобы C++ все последние 20 лет использовался не по назначению.
Точную цитату пожалуйста.
IT> Я в это не верю. Более того, я протестую!
Я тоже, ибо такой муры не говорил.
Я говорил, что C++ умудрились применить там, где не следовало, за что и получили. Но это совсем не означало что "все последние 20 лет" язык использовался не по назначению.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, IT, Вы писали:
IT>Особенно вот это порадовало:
IT>
E>> В комитет по C++ входят люди с разными интересами, ожиданиями и подготовкой. ... Одни используют C++, другие -- нет.
IT>Что можно сказать? Очень важно иметь в комитете людей, которые даже не используют язык, который взялись стандартизировать.
Очень может быть, что избавиться от них не было никакой возможности. Кроме того, в комитете могли быть, например, маркетологи компаний, занимающиеся разработкой компиляторов C++. Или технические писатели, отвечающие за создание документации к компилятору/библиотеке/инструментальному средству.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[26]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, IT, Вы писали:
E>>Видишь ли, понятие нормальности меняется не только в зависимости от области использования языка, но и от времени. То, что было нормально в 1986, тебе сейчас кажется не нормальным.
IT>Я же ясно написал, что понимаю под нормальным дизайном.
Свойства и делегаты?
Боюсь, что очень многие (в том числе и я) не разделяю твою точку зрения по этому вопросу.
E>>И уж тем более сохранять совместимость с ранее написанным кодом.
IT>А это тут при чём? Все компиляторы развиваются, включая C++ и тем не менее остаются совместимы с легаси кодом.
Тем не менее кроме C я не могу припомнить другого языка с таким же возрастом, как C++, для которого было столько же компиляторов на стольком количестве платформ, как для C++. Так что очень вероятно, что ты просто не подозреваешь масштаба задачи.
E>>А потом объясняешь, почему еще в двадцати (или сколько их там сейчас) компиляторах C++ нет никаких свойств или делегатов. И пытаешься заставить разработчиков этих компиляторов добавить их в свои творения.
IT>Давай мы будем говорить о реальных вещах.
Я тебе о реальных вещах и говорю. К моменту принятия C++ стандарта не было ни одного компилятора, который бы поддерживал стандарт. Поэтому стандарт писался с опережением. С расчетом на то, что со временем разработчики компиляторов подтянуться. Практически так и вышло, но 100% поддержки стандарта нет все равно. А ты говоришь о том, чтобы в то время в стандарт засунули еще несколько фич, про которые в то время никто не задумывался.
E>>К тому же рассуждать о том, что C++ динозавр и не соответствует современным требованиям действительно проще, чем признать, что нафиг не нужно было на C++ COM-ы писать.
IT>А были альтернативы? Как только мне предоставилась другая возможность, я поднапрягся, сжал силу воли в кулак и расстался с пережитками прошлого И, поверь мне на слово, ни капельки не жалею. Даже наоборот, чувствую, что прошёл один level и перешёл на следующий.
А я не тебя имел в виду, а тех, кто изобрел COM и сделал программирование на C++ для COM там веселым занятем. У них-то точно выбор был.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[26]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, IT, Вы писали:
E>>Да уж... Имхо, описание было довольно конкретным.
IT>Это не постановка. Это приглашение отрефакторить твой код. Этого я делать не собираюсь. Если ты объяснишь мне задачу (на словах, а не в коде), я попробую её решить без mutable. Но пытаться выкрутится в ситуации, когда без них уже никуда мне не интересно.
Все, вопрос закрыт.
Без обид, но мы с тобой на одном проекте не работали, квалификации друг друга не знаем. Поэтому не будем сейчас учить друг друга правильному проектированию или доказывать что кто-то чего-то не понимает или делает не так.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, VladD2, Вы писали:
NB>>наверно это очень увлекательно, бороться с ветряными мельницами...
VD>Что касается темы... Я конечно пнимаю, что разговор уже ушел очень далего от нее и надо было останавливать все разглагльствования о tcl еще на зачаточной стадии, но все же не думаю, что тяжело поднять голову в верх и прочесть тему,
во-первых, не я поднял тему tcl.
во-вторых, вас, кажется, исходная тема никогда не останавливала от перевода разговора с сторону немерле.
VD>а потом вернуться на десяток сообщений вверх по ветке...
уж не поленитесь, пожалуйста.
Re[18]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, VladD2, Вы писали:
NB>>поправь если ошибаюсь. мне казалось что в этой ветке мы тикл обсуждали
VD>Поправляю, tcl сюда был приплетен в опровдание тому факту, что на С++ без внешних подпорок нельзя создавать полноценный ГУЙ. Оправдание правда скорее является приговором, но многим фанатам этого устаревшего языка и оно сойдет.
IT wrote: > K>Какой Юникод? 2.x? 3.x? — UTF-8? UTF-16? UTF-32? > Юникодный юникод. Пойми простую вещь. Я без понятия кокой юникод у > китайцев и японцев. Я даже разбираться не хочу. Но вот на этом сайте > <http://www.tiffany.jp> one hundred percent работает мой код, в котором > такой проблемой, я тебя уверяю, я не озабачивался.
Так вот, это типичный подход MS. Любой чайник может попрыгать на
клавиатуре — и это будет даже как-то работать.
Вот только как что-то потребуется серьезное сделать — начинаются проблемы.
Текущий Unicode определяет примерно 130 тысяч символов. В два байта они
не входят, поэтому требуется использовать суррогаты в UTF-16. Вот только
никто их обычно не поддерживает в C#.
В число суррогатных символов входят, например, нотные символы. И иногда
они действительно бывают важны.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[18]: Tcl как обоснование ненужности поддержки компонентности в С++
IT wrote: > C>Стандартный пример для mutable — кэши и счетчики ссылок. Там mutable > как раз очень нужен и вполне логичен — так как изменение членов объекта > не приводит к изменению его инварианта. > А зачем данные, не влияющие на изменение инварианта, вообще хранить в > объекте. Никогда не задумывался, что в этом есть некоторое противоречие?
А где их еще хранить без потерь скорости?
Стандартный пример для mutable — это строка, в которой хранится ее хэш.
Хэш вычисляется при необходимости.
Покажи как это сделать без mutable, const_cast и сохраняя при этом
const-correctness.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[33]: Tcl как обоснование ненужности поддержки компонентности в С++
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, IT, Вы писали:
E>>>Стандарт C++ был принят в 1998 году. С тех пор прошло всего восемь лет.
IT>>1998 — 13 = 1985.
E>Ну давай тогда для справедливости скажем, что работа по стандартизации C++ началась в 1989 году. Т.е. спустя четыре года после выхода первой коммерческой версии компилятора C++. Для C# ANSI/ISO стандарта нет. Для Java так же.
11.2.3 The string type
The string type is a sealed class type that inherits directly from
object. Instances of the string class
represent Unicode character strings.
Values of the string type can be written as string literals (§9.4.4). The keyword string is simply an alias for the predefined class
System.String.
И это почти все, что есть про string в стандарте языка.
Из С++:
21 Strings library [lib.strings]
1 This clause describes components for manipulating sequences of
“characters,” where characters may be of
any POD (3.9) type. In this clause such types are called char-like
types, and objects of char-like types are
called char-like objects or simply “characters.”
2 The following subclauses describe a character traits class, a string
class, and null-terminated sequence utilities,
as summarized in Table 36
...
А это С++ — по сути тоже самое написано.
Так что с формальной точки зрения оба языка имеют одинаковую поддержку
строк.
> Это примерно как слово художник от слова "худо", так и std::string — это > стандарт от слова "консенсус". Ну вот надо было всех удовлетворить. > Удовлетворили, получили std::string.
Ну да, а как ты еще хотел? В C# точно так же получили System.String. И я
не вижу чем оно лучше.
> Самая эффективная реализация строки, которая мне попадалась как раз была > сделана на рефкаунтерах — CString из MFC.
Фига. В ней нет SSO (Small String Optimization), так что в куче задач
она проиграет std::string'ам (так как благодаря SSO отпадает
необходимость в динамическом распределении памяти для маленьких строк).
> Может меня, конечно, не сильно > проблемы многозадачности волновали, а может в многозадачной версии > библиотеки CString была специально под это заточена... но меня это > никогда не волновало.
А тех кто пишет критичный по скорости код — волнует.
> C>Да, примерно так и есть. Комитет попытался найти золотую середину — > получилось... средне. > Получился у комитета, как всегда, консенсус.
На то он и комитет. Я не вижу в этом ничего плохого.
> C>Но это не так важно — в С++ есть все средства, чтобы это компенсировать. > Я понимаю. Закат солнца вручную, впрочем как и возможность валить > лобзиком Беловежскую пущу ещё никто не отменял.
Ага. У меня есть свои велосипедные строки (а еще вектора и списки),
которые на большинстве задач эффективнее стандартных.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[10]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
VD>Проблема в том, что порождение идеального решения для предикатной логики это насколько я знаю NP-задача, то есть не факт, что закончится при этой жизни.
Насколько мне известно, Пролог работает с более узким языком, чем предикатная логика плюс есть правила разрешения неопределенностей (что-то вроде не сумели доказать — значит выдаем отрицательный ответ). Так что где NP-полнота я не понял Либо я не понял, в чем заключается идеальность
Re[20]: Tcl как обоснование ненужности поддержки компонентности в С++
IT wrote: > E> В комитет по C++ входят люди с разными интересами, ожиданиями и > подготовкой. ... Одни используют C++, другие -- нет. > Что можно сказать? Очень важно иметь в комитете людей, которые даже не > используют язык, который взялись стандартизировать.
Можно вопрос? Все ли менеджеры в MS, участвующие в разработке языка,
владеют C#ом?
Если нам не помогут, то мы тоже никого не пощадим.
Это примерно как слово художник от слова "худо", так и std::string — это стандарт от слова "консенсус". Ну вот надо было всех удовлетворить. Удовлетворили, получили std::string.
