Здравствуйте, alexeiz, Вы писали:
A>Можно поговорить о практической полезности этой фичи в C++. Вот ты как её использовал, например?
Началось всё с #import. Там без свойств никак. Поначалу было странно, потом привык, понравилось. Подсмотрел реализацию и начал в своём коде использовать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alexeiz, Вы писали:
A>>
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.
VD>То есть обоснованием для отсуствия одной фичи является отсуствие другой фичи в сочетании с которой полезность первой повышается?
Не просто повышается, а приобретает смысл, как часть языка. На уровне простого синтаксического сахара свойства делаются легко с помощью библиотечного решения, что и продемонстрировано в статье.
>А что мешало ввести вторую фичу? По этому поводу тоже есть огромные притензии. Отсуствие механизма на подобии рефлексии являетвя главным припятствием не позволяющим упростить решение огромного класса задач.
Может быть да, а может быть и нет. Было бы это так нужно большому количеству людей, которые без рефлексии страдают, нашёлся бы среди них один, который написал бы достаточно детальное предложение о включении рефлексии в стандарт. Пока этого не произошло.
Re[19]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, FR, Вы писали:
VD>>Поправляю, tcl сюда был приплетен в опровдание тому факту, что на С++ без внешних подпорок нельзя создавать полноценный ГУЙ. Оправдание правда скорее является приговором, но многим фанатам этого устаревшего языка и оно сойдет.
FR>TCL я приплел совершенно без всякого отношения к С++, только как пример языка заточенного на легкое построение GUI.
То есть ты занялся злосным офтопиком, а я тебя просто не правильно понял? Если, так, то скажи... Тебя забаним на дене, а ветку в помойку отправим.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, eao197, Вы писали:
VD>>Сори, а тебя сильно покоробило бы если бы эти вещи были бы в языке? Причем вместо делегатов лучше говорить о функциональном типе.
E>Нет, наличие чего-нибудь в стиле лямбд меня бы не покоробило. Но этого пока нет. Поэтому я не сильно переживаю об его отсутствии.
Лямбда — это возможность создать анонимный метод. А чтобы на нее можно былопередать ссылку нужен функциональный стиль. Вот делегат это их разновидность. Не лучшее решение, на самом деле, но уж точно лучше его отсуствия или указателей на члены в С++.
Вот об этом и идет речь.
Понимаеш, я спокойно отношусь к тому, что эта возможность может быть не нужна какой-то части аудитории языка. Но так как она не мешает, и так как она нужна другой части, то не вижу причин почему не ввести в язык поддержку функционального типа и лямбды (ака анонимного метода с поддержкой замыканий).
И что же мы слышим в ответ? "Язык надо развивать библиотеками..." Но позвольте, реализация функционального типа и лямбды средствами С++ жутко сложное занятие и не приводящее к удовлетворительному для всех результату. За 20 лет существования языка было сделано множество попыток, но все они имели те или иные недостатки. А уж их сложность, объемность и тормоза при компиляции стали христоматийными.
Так с чем собственно борьба?
E>Нет уж, увольте. С меня хватило нескольких попыток поизучать OLE, OLE2 и того, что шло за ними.
Раз ты изучал данные технологии, то должен знать главное отличие ОЛЕ от ОЛЕ2. В чем оно заключается?
Ну, ладно, раз читать ты про КОМ не хочешь, то в предь не говори про него не чего. А то групость получается. Поверь просто на слово, что КОМ делали именно на С++. С++ и С — это два языка на которых можно разрабатывать КОМ-объекты без поддержки со стороны компилятора. Причем на С это выглядит просто ужасно, так как при этом эмулируются такие вещи как VTBL C++.
VD>>За одно можешь подумать почему биндинг для КОРБы получился "кривым" (с).
E>Потому, что биндинг CORBA -- результат работы комитета. Ребята из www.zeroc.com для своего Ice более удобное решение нашли. Потому что были кровно заинтересованы в результате.
Согласен. Но комитета по плюсам, так как на Яве и дотнете биндинг выглядит отлично.
VD>> И почему 99% библитек для С++ выглядят запутанными и не удобны в испльзовании.
E>Очень сильно сомневаюсь, что тебе довелось познакомиться хотя бы с 0.1% C++ библиотек.
Это твои личные проблемы. Мало ли в чем сомневаюсь я...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, alexeiz, Вы писали:
A>Не просто повышается, а приобретает смысл, как часть языка. На уровне простого синтаксического сахара свойства делаются легко с помощью библиотечного решения, что и продемонстрировано в статье.
Лично я (и я уверен, что не один в этом мнении) приветствовал бы свойства и сами по себе. Но согласен с тем, что конечно в современном языке обязана быть и рефлексия. Это еще один упрек тем кто разрабатывал стандарт С++. Они попросту просиживают штаны и не отвечают требованиям времени.
A>Может быть да, а может быть и нет. Было бы это так нужно большому количеству людей, которые без рефлексии страдают, нашёлся бы среди них один, который написал бы достаточно детальное предложение о включении рефлексии в стандарт. Пока этого не произошло.
МС сделала даже реализацию С++-компилятора поддерживающего рефлексию. Борланд для своей VCL тоже кое что сделал. Обратились бы к ним если у самих мозгов не хватает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, eao197, Вы писали:
VD>>Что я в данном случае не знаю? Статью я твою о нем прочел. И вывода было два. 1. Очередной велосипед.
E>Это никогда не скрывалось. Так что америку ты не открыл.
Причем тут америка? Я спросил — что я не знал?
VD>> 2. Средство разработки явно выбрано не верно.
E>До тех пор пока на C++ пишут код и создают реальные системы инструменты для C++ будет иметь смысл создавать.
E>Так что твой вывод, скорее, можно выразить так: "Для меня приговором явился выбор C++ вместо C#".
Не для меня, а с моей точки зрения. И не вместо C#, а вобще в корне не верно. Собственно результаты ты и пожинашь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, eao197, Вы писали:
VD>>Неизменяемость объекта != константности. Неизменяемость означает невозможность изменения его инварианта. То есть сколько бы ты не вызвал его методы с одними и теми же параметрами ты всегда должен получать один и тот же результат. Рассчет хэш-значения не меняет инваринта объекта. Так что его можно как вычислять каждый раз, так и закэшировать при первом обращении.
E>Где хранить кэш. Внутри объекта или снаружи?
Без разницы. Это проблемы реализации.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, eao197, Вы писали:
VD>>Но тут мы быстро прийдем, что для хорошего дизайна хорошо бы иметь GC и безопасный язык.
E>Еще раз -- C++ не задумывался как безопасный язык.
Страуступ постоянно говорит обратное.
E> Вокруг него всегда было достаточно как безопасных языков, так и языков со сборкой мусора.
А сборка мусора в данном случае нужна не для безопасности. Просто он сильно пуростил бы реализацию и избавил бы от таких дурацких решений как метод возвращающий указатель на char.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Tcl как обоснование ненужности поддержки компонентно
FR>>TCL я приплел совершенно без всякого отношения к С++, только как пример языка заточенного на легкое построение GUI.
VD>То есть ты занялся злосным офтопиком, а я тебя просто не правильно понял? Если, так, то скажи... Тебя забаним на дене, а ветку в помойку отправим.
Да можешь забанить.
Наверно это будет первый случай когда тут банят за офтопик
Re[21]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, FR, Вы писали:
FR>Да можешь забанить. FR>Наверно это будет первый случай когда тут банят за офтопик
Тут банят за офтопик не редко. Нужно просто часто им заниматься. Ну, и я за это действительно не баню. И вообще я тебя подкалываю. Но как известно в каждой шутке...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, VladD2, Вы писали:
VD>О. Вот об этом и тема. Давно пора сменить язык.
Зависит от задач. Где Java/.NET рулят (server-side) там на них во многом и перешли.
А в number crunching что-то не видно.
VD> С++ морально устарел.
Ну немолод
VD> Не имеет ни одного приемущества.
Основное преимущество — быстрый код, сравнимый с C.
И существенная экономия памяти по сравнению с Java/.NET
(не говоря уже про то, что хорошая реализация .NET пока есть только в Windows).
Впрочем все это уже 100 раз обсуждалось.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[26]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, VladD2, Вы писали:
VD>> Не имеет ни одного приемущества.
Да, и еще добавлю что у него есть нормальная поддержка обобщенного программирования на шаблонах,
чего не видно в других распространенных языках (урезанные genericи совершенно не рулят).
Конечно, Nemerle способен предложить кое-что покруче, посмотрим что из этого выйдет...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[27]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Зависит от задач. Где Java/.NET рулят (server-side) там на них во многом и перешли. АХ>А в number crunching что-то не видно.
Там рулят фортраны. Впрочем, если не сложно, дай ссылку на такой алгоритм перемалывания.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[47]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, VladD2, Вы писали:
C>>2. Всего символов 130 тысяч. VD>Вот эти подробности меня никогда не волновали.
C>>3. Все символы в два байта не вместятся. VD>Да. Есть набор символов которые представляются в UTF-16 двубайтовыми сочетаниями.
Может всетаки 4 байтами? В UTF-16 вроде символы восновном 2 байтовые.
VD>Огромная редкость и обычно их просто нет в шрифтах, но формально есть.
Ну если всего символов 130 тыс. то не такая уж и редкость каждый второй символ
C>>6. И как теперь нормально использовать quadchar'ы в CLR? VD>Так в чем проблема то?
Действительно как? Мне просто интересно (врятли хоть раз использую...)
... << RSDN@Home 1.2.0 alpha rev. 648>>
Re[24]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, eao197, Вы писали:
E>Еще раз -- C++ не задумывался как безопасный язык.
Откуда такие подробности? Ты свечку держал когда он задумывался? У меня вот, например, как у жителя эрии где непосредственно разрабатывался C++ есть про его создателя некоторые интимные подробности. Но про безопасный язык я что-то не слышал
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Tcl как обоснование ненужности поддержки компонентно
IT wrote: > A>Можно поговорить о практической полезности этой фичи в C++. Вот ты как > её использовал, например? > Началось всё с #import. Там без свойств никак. Поначалу было странно, > потом привык, понравилось. Подсмотрел реализацию и начал в своём коде > использовать.
Берем Comet (генерирует чистый С++, даже на GCC работает) — и видим, что
свойства совсем и не нужны на самом деле.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[47]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, VladD2, Вы писали:
C>>А я что-то про IT говорил??? VD>Значит все же про себя? К чему тут фраза про любого чайника?
Это общая фраза, про некого абстрактного чайника.
C>>1. Размер символа в CLR — два байта. VD>Неверная фрмулировка. Верная звучит так — для хранения строк .Net предпологает использование UTF-16.
Вот только 99.99% программистов на .NET используют строки как UCS-2.
C>>2. Всего символов 130 тысяч. VD>Вот эти подробности меня никогда не волновали.
Ага. Ведь это разрушает картину идеальности CLR и непогрешимости их создателей.
C>>3. Все символы в два байта не вместятся. VD>Да. Есть набор символов которые представляются в UTF-16 двубайтовыми сочетаниями. Огромная редкость и обычно их просто нет в шрифтах, но формально есть.
Из-за этой огромной редкости нельзя адресоваться к символам в строке напрямую по индексу.
C>>4. Нельзя использовать прямую индексную адресацию для работы символами в C>>строке. VD>Смотря для каких целей.
Практически для любых.
C>>5. И нафига была затевать всю возню с двухбайтовыми символами??? VD>Что использовать UTF-32?
Да. Или не парить мозги и взять UTF-8.
VD>UTF-16 является разумным компромисом. Программы для 99.9% применений можно писать так как будто символ всегда 16 бит. А если что есть возможность и повыпердиваться.
Кто-то в соседней ветке падал в обморок от sprintf'а. Ведь если int будет размером более 256бит, то будет ПЕРЕПОЛНЕНИЕ БУФФЕРА!
А реально существующие проблемы считаются несущественными.
Интересная логика.
C>>6. И как теперь нормально использовать quadchar'ы в CLR? VD>Так в чем проблема то?
Как мне с ним регекспы, например, использовать?
Sapienti sat!
Re[48]: Синтаксический сахар или C++ vs. Nemerle :)
Дьяченко Александр wrote: > VD>Огромная редкость и обычно их просто нет в шрифтах, но формально есть. > Ну если всего символов 130 тыс. то не такая уж и редкость каждый второй > символ
Там большая часть — символы мертвых или искусственных языков (типа
Линейного-B и Клингонского).
Но есть и реально нужные символы нотной грамоты и нескольких
экзотических (но существующих) языков.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[41]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, VladD2, Вы писали:
E>>Где хранить кэш. Внутри объекта или снаружи?
VD>Без разницы. Это проблемы реализации.
Это уход от ответа. Если хеш хранится в объекте в виде атрибута, то как этот атрибут будет изменяться константным методом объекта для константного же объекта?
Это та же самая задача, словесную формулировку которой вы с IT просили у меня. Только в моем случае был не хеш (с которым возможны коллизии), а уникальная двоичная последовательность.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[39]: Синтаксический сахар или C++ vs. Nemerle :)
Если нам не помогут, то мы тоже никого не пощадим.
