Здравствуйте, Cyberax, Вы писали:
>> Строка должна быть неизменяемым классом. C>Не согласен, но пока пусть будет так.
Твои проблемы, жрать кактусы тоже кому-то надо.
>> Хэш рассчитываться при создании или первом обращении. C>А как он может рассчитываться, если объект неизменяем?
Неизменяемость объекта != константности. Неизменяемость означает невозможность изменения его инварианта. То есть сколько бы ты не вызвал его методы с одними и теми же параметрами ты всегда должен получать один и тот же результат. Рассчет хэш-значения не меняет инваринта объекта. Так что его можно как вычислять каждый раз, так и закэшировать при первом обращении.
C>Следовательно, неизменяемым должно быть его поведение в ответ на события C>(aka "инвариант"), но внутреннее состояние должно при этом изменится.
Неверные следствия. Поведение не меняется, состояние стало быть тоже. А то что делает объект в своих потрахах — это его личные трудности. Нас от них защищает инкапсуляция. Нам важно, что не возникает никаких побочных эффектов, а на остальное чехать.
>> Защита при этом обеспечивается средстами ООП, а константровсть >> вообще как бы не причем. C>Константность в С++ — это простейшее средство проверки правильности C>использования модели.
Как не трудно понять в данном случае это неверное использование возможности. К тому же константность в С++ настолько легко снимается, что пологаться на нее я бы не стал.
В немерле есть понятие неизменяемой переменной, но нет понятия константности для классов или методов.
>> Вот только есть одна проблема. Данный подход отлично работает в >> безопасных языка. C>Не работает. Создатели Java и C# посчитали, что нагружать мозги бедных C>индусов понятиями о константности не стоит. Вот и сделели ее бедную C>эмуляцию в виде иммутабельных sealed классов.
Снова аргументы о индусах. И снова мы отправляем их в лес за несостоятельностью, так как это все домыслы. К тому же эти домыслы входят в конфликт с тем что существуют языки явно не предназначенные для индусов (тот же Немерле), превосходящие С++ по мощьности, в которых тоже нет константности для объектов.
Кстати та безграмотность с которой в С++ оперируют термином константность в очередной раз наводит на мысль о слабой теоритической подготовке его авторов. Изменяемая константа — это натуральный оксюморон.
>> Но в языках где есть приведения типов и указатели на >> любую защиту можно наплевать. C>Что все так на защите помешаны?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, IT, Вы писали:
IT>Вот и я говорю. Не комитет, а балаган. Технические писатели определяют стандарт языка. Теперь понятно почему в плюсах есть mutable и нет string.
Я думаю, что главное не то, что строки не в языке, а то, что они не удовлетворяют многих пользователей. Другими словами имеют плохой дизайн. Но тут мы быстро прийдем, что для хорошего дизайна хорошо бы иметь GC и безопасный язык.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Tcl как обоснование ненужности поддержки компонентно
WolfHound wrote: > C>Так в C# тоже нет строк в языке! > В C# ВСЕ встроеные типы находятся в библиотеке. И это неизбежно из-за > компонентной модели .НЕТ.
Вот! Значит в C# нет строки в языке. ЧТД.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[23]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, Cyberax, Вы писали:
C>IT wrote: >> Вот и я говорю. Не комитет, а балаган. Технические писатели определяют >> стандарт языка. Теперь понятно почему в плюсах есть mutable и нет string. C>Так в C# тоже нет строк в языке!
Не только в C# есть строки, но и в CIL, да и вообще они являются неотъемлемой частью CLR.
Вообще с такими заявлениями можно договориться до того, что в C++ нет например dynamic_cast и typeid,в Nemerle нет функциональных типов, кортежей и списков, а в D нет динамических и ассоциативных массивов, GC и тех же динамических кастов, да еще и кучи других вещей.
Дело в том, что язык это одно дело, а его рантайм это совсем другое дело. В C#, Nemerle и даже в D рантайм просто реализован более умно и дальновидно, и является более самостоятельной частью(практически частью стандартной библиотеки), чем в компиляторах C++.
Нужно больше обращать внимание на то чем являются эти конструкции/типы во время компиляции. Для компилятора C++ например строковые литералы являются константными массивами char или wchar_t, а для любого языка .NET они являются строкой, так как и для CLR они являются строкой. Более того JIT в CLR очень хорошо осведомлен о таких типах как System.String и System.Text.StringBuilder и умеет специально оптимизировать работу с ними.
Re[23]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, VladD2, Вы писали:
IT>>Вот и я говорю. Не комитет, а балаган. Технические писатели определяют стандарт языка. Теперь понятно почему в плюсах есть mutable и нет string.
VD>Я думаю, что главное не то, что строки не в языке, а то, что они не удовлетворяют многих пользователей. Другими словами имеют плохой дизайн. Но тут мы быстро прийдем, что для хорошего дизайна хорошо бы иметь GC и безопасный язык.
std::string, как и весь std:: — это "компромис", консенсус, блин.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Tcl как обоснование ненужности поддержки компонентнос
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, FR, Вы писали:
FR>>Те кто пишет на фортране наверняка ближе к этому острию чем большинство пишущих на NET
IT>В IT? Сомневаюсь.
В науке. Да и в IT острие отнюдь не в майнстриме.
Re[12]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, VladD2, Вы писали:
VD>Это ты откровенно переверашь мои слова. Я гляжу и сужу. Вижу убогость, называю ее таковой. Вот полгядел на ссылку и увидил малый набор компонентов, кривейший внешний вид (даже иконки и те убогие). На вопрос о гриде получил ответ, что пиписка коротка. Какие мне еще делать выводы?
нормальные иконки, а то что коряво выглядит это вина linux'а под XP все нормально.
FR>>Ну и посмотрим на сколько неубогим станет NET если будет подерживать столько же платформ сколько и tcl/tk.
VD>А зачем мне столько платформ если для этого нужно обязательно мириться с убогостью? Ну, их в лес. Мне Виндовс за глаза хватит. Хотя конечно есть Ява с ее компонентным подходом. Там не все так здорово, видать многоплатформность дает знать, но все же куда лучше чем tcl. И компоненты сторонние есть, и ГУЙ приличный делается (смотрим на IDEA).
У tcl gui не хуже чем в java, и при этом работает шустрее.
VD>А вот где приличный ГУЙ на С++ и без подпорок? А? Я и на tcl то его не вижу.
А при чем тут C++?
FR>>Он может расширятся как и средствами языка на котором ведется разработка так и с помощью си — с++ FR>>На него достаточно много готовых контролов от других производителей.
VD>Ну, где среди них приличный грид? И почему его нет если все так шоколадное? Может быть кто-то выдает желаемое за дейсвительное?
Мне грид не нужен, так что все хорошо
VD>И все же если вспомнить, что tcl это очередная подпорка, то можно откинув ее объяснить что мешало встроить в С++ поддержку компонентного подхода? Почему в этом языке до сих пор единственным средством импорта чужих модулей являются допотопные #include-ы?
Какая подпорка, какой C++? Tcl совершенно самостоятельный язык, к C++ вообще никакого отношения ни имеет. Более того tk — gui часть tcl, легко используется из множества совершенно разных и не похожих на tcl языков.
Re[2]: Tcl как обоснование ненужности поддержки компонентнос
Здравствуйте, VladD2, Вы писали:
VD>Поправляю, tcl сюда был приплетен в опровдание тому факту, что на С++ без внешних подпорок нельзя создавать полноценный ГУЙ. Оправдание правда скорее является приговором, но многим фанатам этого устаревшего языка и оно сойдет.
TCL я приплел совершенно без всякого отношения к С++, только как пример языка заточенного на легкое построение GUI.
Re[18]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, FR, Вы писали:
FR>>Те кто пишет на фортране наверняка ближе к этому острию чем большинство пишущих на NET
IT>В IT? Сомневаюсь.
Если учесть, что фортран часто используется на высокопроизводительных машинах, то в IT многие из них должны соображать и не плохо (хотя бы с точки зрения распараллеливания алгоритмов)
P.S. Просьба не убеждать, что фортран — плохой, он просто г-но
Re[19]: Tcl как обоснование ненужности поддержки компонентно
VD>Ага! Нельзя! Ведь они компоненты. А компонентам нужна среда исполнения. Сцинтила в С++ выглядит как тип окна с сообщениями. О визуальных дизайнерах не может быть и речи. Если сравнить сложность и обхем работ требуемый для подключения Сцинтилы к проекту на С++ не сравним с тем же самым на C#. В C# я просто бросаю компонет на форму и настраиваю его свойства. А в С++ нет ни, формы, ни компонента, ни даже понятия свойства. Это закат солнца врнучную вместо работы. С гридом же еще смешнее. Его просто не написали для С++. Он есть для КОМ и дотнета. КОМ-варинт в сто раз проще использовать в ВБ6. А дотнет... да в нем есть МС++, но к С++ он никакого отношения не имеет.
Напомнило Дельфёвый TProgrammer... мдя...
kalsarikännit
Re[2]: Tcl как обоснование ненужности поддержки компонентнос
Здравствуйте, VladD2, Вы писали:
VD>Сри, а тебя сильно покоробило бы если бы эти вещи были бы в языке? Причем вместо делегатов лучше говорить о функциональном типе.
Нет, наличие чего-нибудь в стиле лямбд меня бы не покоробило. Но этого пока нет. Поэтому я не сильно переживаю об его отсутствии.
E>> Поэтому стандарт писался с опережением.
VD>Да, да. Всем очень интересны аспекты написания кривых решений. Рассказывайте моэстро...
Кому расказывать, тебе что-ли? Рассмешил. Ты уже приговорил C++, так что толку тебе что-нибудь рассказывать?
E>>А я не тебя имел в виду, а тех, кто изобрел COM и сделал программирование на C++ для COM там веселым занятем. У них-то точно выбор был.
VD>Серьезно? И какой? Ты бы чем говорить о том в чем не понимаешь (ты кажется любишь мне подобные вещи говорить) почитал бы труды Дона Бокса посвященные КОМ-у. Он там очень хорошо рассказывает как создавался КОМ, что за идеи легли в основу, на чем создавался КОМ, и почему КОМ получился таким как получился.
Нет уж, увольте. С меня хватило нескольких попыток поизучать OLE, OLE2 и того, что шло за ними.
VD>За одно можешь подумать почему биндинг для КОРБы получился "кривым" (с).
Потому, что биндинг CORBA -- результат работы комитета. Ребята из www.zeroc.com для своего Ice более удобное решение нашли. Потому что были кровно заинтересованы в результате.
VD> И почему 99% библитек для С++ выглядят запутанными и не удобны в испльзовании.
Очень сильно сомневаюсь, что тебе довелось познакомиться хотя бы с 0.1% C++ библиотек.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[39]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, VladD2, Вы писали:
VD>Неизменяемость объекта != константности. Неизменяемость означает невозможность изменения его инварианта. То есть сколько бы ты не вызвал его методы с одними и теми же параметрами ты всегда должен получать один и тот же результат. Рассчет хэш-значения не меняет инваринта объекта. Так что его можно как вычислять каждый раз, так и закэшировать при первом обращении.
Где хранить кэш. Внутри объекта или снаружи?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[23]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alexeiz, Вы писали:
A>>Почитай введение в этом документе. Может он тебя на счёт возможности/реальности/полезности свойств в C++ просветит.
IT>В их полезности меня не надо убеждать/отговаривать. Я ими реально пользовался в C++ несколько лет и находил их удобными.
Можно поговорить о практической полезности этой фичи в C++. Вот ты как её использовал, например?
Если нам не помогут, то мы тоже никого не пощадим.
