Здравствуйте, IT, Вы писали:
IT>Это всё отговорки. Ничто не мешает ввести в язык современные конструкции вроде свойств и делегатов. Но проще, конечно же, рассуждать об отсутствии воды.
Почитай введение в этом документе. Может он тебя на счёт возможности/реальности/полезности свойств в C++ просветит.
Советую обратить внимание на следующий фрагмент, из которого понятно, что введение свойств в язык C++ приносит в лучшем случае очень ограниченную выгоду, так как C++ не может гарантировать сопутствующей инфраструктуры, наподобие той, что есть в .NET:
My impression is that the main benefit of properties is not their syntactic sleight-of-hand but (1)
their ability to be discovered through introspection/reflection and manipulated nonprogrammatically
by some sort of RAD tool, and (2) their ability to be stored (I think "pickled" is
the term used with Java Beans) in this configured state, so that they can be loaded at runtime,
already configured.
Re[36]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, eao197, Вы писали:
E>Бым-га-га. Наглядная демонстрация того, что в большинстве случаев ты говоришь о том, чего не знаешь.
Что я в данном случае не знаю? Статью я твою о нем прочел. И вывода было два. 1. Очередной велосипед. 2. Средство разработки явно выбрано не верно.
Скорее это ты наглядно демонстрируешь, что единственным "аргументом" в споре у тебя является необоснованное сомнение в словах оппонента. Ну, дык такие аргументы идут лесом в месте с теми кто ими пытается оперировать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, Cyberax, Вы писали:
C>А где их еще хранить без потерь скорости?
C>Стандартный пример для mutable — это строка, в которой хранится ее хэш. C>Хэш вычисляется при необходимости.
C>Покажи как это сделать без mutable, const_cast и сохраняя при этом C>const-correctness.
Нда, и эти люди тут еще спорить пытаются о чем-то .
Строка должна быть неизменяемым классом. Хэш рассчитываться при создании или первом обращении. Защита при этом обеспечивается средстами ООП, а константровсть вообще как бы не причем.
Вот только есть одна проблема. Данный подход отлично работает в безопасных языка. Но в языках где есть приведения типов и указатели на любую защиту можно наплевать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, night beast, Вы писали:
NB>во-первых, не я поднял тему tcl.
Ты в нее влез в середине. Думаешь, это что-то меняет?
NB>во-вторых, вас, кажется, исходная тема никогда не останавливала от перевода разговора с сторону немерле.
Ты голову то подними, и прочти название темы. Может тогда прийдет просветление.
VD>>а потом вернуться на десяток сообщений вверх по ветке...
NB>уж не поленитесь, пожалуйста.
Нда, полная дезориентация в пространстве. Это я тебе сказал.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
Здравствуйте, kaer, Вы писали:
K>Насколько мне известно, Пролог работает с более узким языком, чем предикатная логика плюс есть правила разрешения неопределенностей (что-то вроде не сумели доказать — значит выдаем отрицательный ответ). Так что где NP-полнота я не понял Либо я не понял, в чем заключается идеальность
Почитай любую научную работу о Прологе. Пересказывать подобные вещи тут нет ни желания, ни возможности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, Cyberax, Вы писали:
C>Так вот, это типичный подход MS. Любой чайник может попрыгать на C>клавиатуре — и это будет даже как-то работать.
Как ты думшь, кто из вас двоих для окружающих чайник? Ты или IT?
C>Вот только как что-то потребуется серьезное сделать — начинаются проблемы.
Может быть за серьезное должны быраться не чайники? И тогда проблемы не начнутся...
C>Текущий Unicode определяет примерно 130 тысяч символов. В два байта они C>не входят, поэтому требуется использовать суррогаты в UTF-16. Вот только C>никто их обычно не поддерживает в C#.
Эти слова я уже слышал. На них я тебе уже отвечал. Приведи, плиз, ссыкли доказывающие ущербность поддержки юникода в дотнете. А если не можешь, то не повторяй глупость снова и снова. От этого она рузумными словами не становится.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, night beast, Вы писали:
VD>>Поправляю, tcl сюда был приплетен в опровдание тому факту, что на С++ без внешних подпорок нельзя создавать полноценный ГУЙ. Оправдание правда скорее является приговором, но многим фанатам этого устаревшего языка и оно сойдет.
NB>цитату не затруднит? могу даже помочь
Меня как-то пугает полная неадекватность оппонентов. Ты же сам привел ссылку в которой видно, что tcl появился совершенно от балды, в подветке где обсуждалась проблема построения гуи на С++? Одну подпорку (генераторы кода в QT) подменили второй подпоркой tcl. Причем вторая имеет еще меньшее отношение к С++.
VD>>ЗЫ
VD>>Ты хоть смотри к чему присоеденяешся.
NB>и вам того-же
Извини, но тратить время на борьбу с полной неадекватностью мне не хочется. Слудующие твои сообщения построенные в таком же идут с моей стороны в дев/нал.
NB>PS: может вам все-таки стоит ознакомится с языком tcl. хотя-бы поверхностно.
Это как-то поможет встраиванию в С++ средств построения ГУИ? Если нет, то спасибо. Я знаю куда более удобные для меня пути построения качественного ГУИ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, alexeiz, Вы писали:
A>Почитай введение в этом документе. Может он тебя на счёт возможности/реальности/полезности свойств в C++ просветит.
В их полезности меня не надо убеждать/отговаривать. Я ими реально пользовался в C++ несколько лет и находил их удобными.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re: Tcl как обоснование ненужности поддержки компонентности
Здравствуйте, eao197, Вы писали:
E>Свойства и делегаты? E>Боюсь, что очень многие (в том числе и я) не разделяю твою точку зрения по этому вопросу.
Сри, а тебя сильно покоробило бы если бы эти вещи были бы в языке? Причем вместо делегатов лучше говорить о функциональном типе.
E>Я тебе о реальных вещах и говорю. К моменту принятия C++ стандарта не было ни одного компилятора, который бы поддерживал стандарт.
... к сегодняшнему момент есть один такой компилятор...
Прогресс однако.
E> Поэтому стандарт писался с опережением.
Да, да. Всем очень интересны аспекты написания кривых решений. Рассказывайте моэстро...
E>А я не тебя имел в виду, а тех, кто изобрел COM и сделал программирование на C++ для COM там веселым занятем. У них-то точно выбор был.
Серьезно? И какой? Ты бы чем говорить о том в чем не понимаешь (ты кажется любишь мне подобные вещи говорить) почитал бы труды Дона Бокса посвященные КОМ-у. Он там очень хорошо рассказывает как создавался КОМ, что за идеи легли в основу, на чем создавался КОМ, и почему КОМ получился таким как получился.
За одно можешь подумать почему биндинг для КОРБы получился "кривым" (с). И почему 99% библитек для С++ выглядят запутанными и не удобны в испльзовании.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Tcl как обоснование ненужности поддержки компонентно
A>My impression is that the main benefit of properties is not their syntactic sleight-of-hand but (1)
A>their ability to be discovered through introspection/reflection and manipulated nonprogrammatically
A>by some sort of RAD tool, and (2) their ability to be stored (I think "pickled" is
A>the term used with Java Beans) in this configured state, so that they can be loaded at runtime,
A>already configured.
То есть обоснованием для отсуствия одной фичи является отсуствие другой фичи в сочетании с которой полезность первой повышается? А что мешало ввести вторую фичу? По этому поводу тоже есть огромные притензии. Отсуствие механизма на подобии рефлексии являетвя главным припятствием не позволяющим упростить решение огромного класса задач.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, eao197, Вы писали:
IT>>Это не постановка. Это приглашение отрефакторить твой код. Этого я делать не собираюсь. Если ты объяснишь мне задачу (на словах, а не в коде), я попробую её решить без mutable. Но пытаться выкрутится в ситуации, когда без них уже никуда мне не интересно.
E>Все, вопрос закрыт. E>Без обид, но мы с тобой на одном проекте не работали, квалификации друг друга не знаем. Поэтому не будем сейчас учить друг друга правильному проектированию или доказывать что кто-то чего-то не понимает или делает не так.
Да, действительно. На лицо полный слив, так как на просьбу дать описание задачи на раговорном языке пошли рассуждения о квалификации оппонента.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, Cyberax, Вы писали:
C>И это почти все, что есть про string в стандарте языка.
Я в курсе что такое string. Могу ещё раз повторить специально для тебя. C# без фреймворка не является полноценным языком и System.String был в нём с самого начала и пусть через алиан, но выглядит как часть языка. В C++ std::string появился 10 лет спустя и за последующие 10 лет так и не стал стандартной строкой.
C>Так что с формальной точки зрения оба языка имеют одинаковую поддержку строк.
А с практической, в C#... даже не так, в .NET одна строка на всех, а C++ целый зверинец, в котором std::string как стандарт выглядит мягко говоря не очень убедительно.
>> Самая эффективная реализация строки, которая мне попадалась как раз была сделана на рефкаунтерах — CString из MFC. C>Фига. В ней нет SSO (Small String Optimization), так что в куче задач она проиграет std::string'ам (так как благодаря SSO отпадает необходимость в динамическом распределении памяти для маленьких строк).
Тем хуже для плюсов
>> Получился у комитета, как всегда, консенсус. C>На то он и комитет. Я не вижу в этом ничего плохого.
Здесь консенсус надо взять в кавычки.
>> C>Но это не так важно — в С++ есть все средства, чтобы это компенсировать. >> Я понимаю. Закат солнца вручную, впрочем как и возможность валить лобзиком Беловежскую пущу ещё никто не отменял. C>Ага. У меня есть свои велосипедные строки (а еще вектора и списки), которые на большинстве задач эффективнее стандартных.
У меня тоже были. Строки, коллекции, работа с датами. Было жалко всё это вот так выкидывать. Сейчас я о них даже не вспоминаю.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[21]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, eao197, Вы писали:
E>Очень может быть, что избавиться от них не было никакой возможности. Кроме того, в комитете могли быть, например, маркетологи компаний, занимающиеся разработкой компиляторов C++. Или технические писатели, отвечающие за создание документации к компилятору/библиотеке/инструментальному средству.
Вот и я говорю. Не комитет, а балаган. Технические писатели определяют стандарт языка. Теперь понятно почему в плюсах есть mutable и нет string.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[37]: Синтаксический сахар или C++ vs. Nemerle :)
VladD2 wrote: > Строка должна быть неизменяемым классом.
Не согласен, но пока пусть будет так.
> Хэш рассчитываться при создании или первом обращении.
А как он может рассчитываться, если объект неизменяем?
Следовательно, неизменяемым должно быть его поведение в ответ на события
(aka "инвариант"), но внутреннее состояние должно при этом изменится.
> Защита при этом обеспечивается средстами ООП, а константровсть > вообще как бы не причем.
Константность в С++ — это простейшее средство проверки правильности
использования модели.
> Вот только есть одна проблема. Данный подход отлично работает в > безопасных языка.
Не работает. Создатели Java и C# посчитали, что нагружать мозги бедных
индусов понятиями о константности не стоит. Вот и сделели ее бедную
эмуляцию в виде иммутабельных sealed классов.
> Но в языках где есть приведения типов и указатели на > любую защиту можно наплевать.
Что все так на защите помешаны?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[45]: Синтаксический сахар или C++ vs. Nemerle :)
VladD2 wrote: > C>Так вот, это типичный подход MS. Любой чайник может попрыгать на > C>клавиатуре — и это будет даже как-то работать. > Как ты думшь, кто из вас двоих для окружающих чайник? Ты или IT?
А я что-то про IT говорил???
> C>Текущий Unicode определяет примерно 130 тысяч символов. В два байта они > C>не входят, поэтому требуется использовать суррогаты в UTF-16. Вот только > C>никто их обычно не поддерживает в C#. > Эти слова я уже слышал. На них я тебе уже отвечал. Приведи, плиз, ссыкли > доказывающие ущербность поддержки юникода в дотнете.
1. Размер символа в CLR — два байта. Ты согласен или ссылки на спеку дать?
2. Всего символов 130 тысяч.
3. Все символы в два байта не вместятся.
4. Нельзя использовать прямую индексную адресацию для работы символами в
строке.
5. И нафига была затевать всю возню с двухбайтовыми символами???
6. И как теперь нормально использовать quadchar'ы в CLR?
Что здесь не так?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[22]: Tcl как обоснование ненужности поддержки компонентно
IT wrote: > Вот и я говорю. Не комитет, а балаган. Технические писатели определяют > стандарт языка. Теперь понятно почему в плюсах есть mutable и нет string.
Так в C# тоже нет строк в языке!
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[23]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, Cyberax, Вы писали:
C>Так в C# тоже нет строк в языке!
В C# ВСЕ встроеные типы находятся в библиотеке. И это неизбежно из-за компонентной модели .НЕТ.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[46]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, Cyberax, Вы писали:
>> C>Так вот, это типичный подход MS. Любой чайник может попрыгать на >> C>клавиатуре — и это будет даже как-то работать. >> Как ты думшь, кто из вас двоих для окружающих чайник? Ты или IT? C>А я что-то про IT говорил???
Значит все же про себя? К чему тут фраза про любого чайника?
>> C>Текущий Unicode определяет примерно 130 тысяч символов. В два байта они >> C>не входят, поэтому требуется использовать суррогаты в UTF-16. Вот только >> C>никто их обычно не поддерживает в C#. >> Эти слова я уже слышал. На них я тебе уже отвечал. Приведи, плиз, ссыкли >> доказывающие ущербность поддержки юникода в дотнете. C>1. Размер символа в CLR — два байта.
Неверная фрмулировка. Верная звучит так — для хранения строк .Net предпологает использование UTF-16.
C> Ты согласен или ссылки на спеку дать?
Я не согласен с формулировкой.
C>2. Всего символов 130 тысяч.
Вот эти подробности меня никогда не волновали.
C>3. Все символы в два байта не вместятся.
Да. Есть набор символов которые представляются в UTF-16 двубайтовыми сочетаниями. Огромная редкость и обычно их просто нет в шрифтах, но формально есть.
C>4. Нельзя использовать прямую индексную адресацию для работы символами в C>строке.
Смотря для каких целей.
C>5. И нафига была затевать всю возню с двухбайтовыми символами???
Что использовать UTF-32?
UTF-16 является разумным компромисом. Программы для 99.9% применений можно писать так как будто символ всегда 16 бит. А если что есть возможность и повыпердиваться.
C>6. И как теперь нормально использовать quadchar'ы в CLR?
Так в чем проблема то?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
Это я тебе сказал.
Если нам не помогут, то мы тоже никого не пощадим.
