Здравствуйте, criosray, Вы писали:
C>Здравствуйте, MxKazan, Вы писали:
MK>>Интересно как на С++, например, реализовать второй пункт для четвертого. Идея проста: перед генерацией события INotifyPropertyChanged.PropertyChanged при помощи Рефлексии проверяется, что свойство с заданным именем действительно есть в классе. Тем самым при отладке мы защищаемся от кривого указания имени в аргументах события.
C>Кстати, единственное чего не хватает в С# — макроподстановки имени свойства:
C>
C>public int Height
C>{
C> get { return _height; }
C> set {
C> _height = value;
C> OnPropertyChanged("Height");
C> }
C>}
C>
C>Есть конечно вариант решения с лямбдой и рефлексией: OnPropertyChanged(o => o.Height); C>Но очевидный перформанс хит в данном случае делает такое решение часто недопустимым...
C>Конечно генерация кода с помощью T4-шаблонов ликвидирует возможность опечатки, но хотелось бы все-таки макроподстановку. Тем более, что это совсем не сложно сделать, имхо.
C>>Конечно генерация кода с помощью T4-шаблонов ликвидирует возможность опечатки, но хотелось бы все-таки макроподстановку. Тем более, что это совсем не сложно сделать, имхо.
G>Особенно в Nemerle
Здравствуйте, MxKazan, Вы писали:
MK>Ну, оставим compile-time, я даже не обратил на это внимание, т.к. за последнее время привык, что под корректностью именования подразумевают именно ту процедуру, которую описал. Так как оно на С++?
Очевидно руками, т.е. проперти будут выглядеть как некий шаблонный класс вида property<T>, который будет хранить всю необходимую для рантайма-проверок информацию
Здравствуйте, dmitry_npi, Вы писали:
_>Да нет, я-то сам его люблю. Случайно наткнулся на статью здесь. _>Он не просто его, не любит, он его ненавидит. И других заразить пытается.
Слишком эмоционально и слишком просвечивает отсутствие опыта разработки/поддержки приложений сколько-нибудь существенной сложности и объема — иначе бы претензии были бы совсем другими...
Если попытаться прогрызться через поток каши и не обращать внимания на места, где автор откровенно привирает, то аргументы сводятся к:
1. А сколько ж здесь способов убиться ап стену.
2. Метаинформацию приходится вносить ручками.
3. В языке нет фичи N (не, лучше M, M — больше).
Ну ответ на это опять же классический.
1. Да, чистая правда — можно при желании. Любая серьезная разработка в итоге ведется не на С++, а на некотором подможножестве языка и надмножестве библиотек, подкрепленном внутренними стандартами. Так что говорить о
2. То же правда, размер декларации данных при этом раздувается в разных пропорциях — от двухкратной (при рукопашном биндинге) до двух строк на класс — при реализации как макроса среды разработки. Большим минусом будет что при этом разные реализации несовместимы между собой.
3. Нельзя объять необъятное, значительная часть запрошенных фичей эмулируется либо 1:1 (что чаще), либо с потерями в объеме кода ну максимум в два раза. Есть конечно вещи, которые толково не реализуются ну никак. Ну дык никто не будет спорить что язык придавлен грузом легаси и в общем-то на данный момент устарел. Но! Это еще не повод его демонизировать.
PS: наш сериализатор дает 1.2 гигабайта/секунду потоковую производительность (собственно упираемся в скорость чтения/записи памяти) на данных умеренно-сложной структуры (поддерживая при этом возможность частичной десериализации кстати, что совсем нелишнее), как там с этим дело у опирающихся на рантайм-метаинформацию сериализаторов Java или, zomg, Питона? =)
PPS: а вот на шарпе аккуратное освобождение ресурсов приходится эмулировать жуткими костылями, дискасс
_>Вот, думаю, тролль Отличная приманка для священной войны.
Да как-то тухло пока — неужели к С++ .vs. весь мир можно добавить что-то новое?
Здравствуйте, doarn, Вы писали:
D>1. Да, чистая правда — можно при желании. Любая серьезная разработка в итоге ведется не на С++, а на некотором подможножестве языка и надмножестве библиотек, подкрепленном внутренними стандартами. Так что говорить о
Так что говорить следует о совсем-совсем разных примерах использования. И при должной аккуратности в построении окружения — количество способов отстрелить ногу сокращается до вполне приемлимого.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Сериализация почти всегда нужна в контексте решения задач наподобие построения протокола обмена данными
НС>Это называется взгляд через замочную скважину.
Раскрыть можешь?
У нас в старом проекте (игровой движок) через сериализацию решалось:
— сохранение/восстановление в хмл/нативный формат
— клонирование графа
— конвертация графа в нативный формат
Здравствуйте, doarn, Вы писали:
D>3. Нельзя объять необъятное, значительная часть запрошенных фичей эмулируется либо 1:1 (что чаще), либо с потерями в объеме кода ну максимум в два раза. Есть конечно вещи, которые толково не реализуются ну никак. Ну дык никто не будет спорить что язык придавлен грузом легаси и в общем-то на данный момент устарел. Но! Это еще не повод его демонизировать.
C++ подвергался "демонизации" добрых 10 лет тому назад. Его жестко критиковали даже такие личности, как небезызвестный Линус Торвальдс.
D>PS: наш сериализатор дает 1.2 гигабайта/секунду потоковую производительность (собственно упираемся в скорость
чтения/записи памяти) на данных умеренно-сложной структуры (поддерживая при этом возможность частичной десериализации
Эта цифра абсолютно ни о чем не говорит. Да и сериализация-то у Вас поди бинарная?
D>кстати, что совсем нелишнее), как там с этим дело у опирающихся на рантайм-метаинформацию сериализаторов Java или, zomg, Питона? =)
Конкретно на нащих проектах — более чем достаточная (речь о С#, но Java тоже где-то там).
D>PPS: а вот на шарпе аккуратное освобождение ресурсов приходится эмулировать жуткими костылями, дискасс
Ну уж точно менее жуткими, чем С++ с зоопарками shared_ptr<> auto_ptr<> и прочих костылей. Да и что такого жуткого в операторе using? Вы можете предложить лучшее решение?
Тем более, что в автобилд встроен fxcop, энфорсящий вызов Dispose для объектов, реализующих IDisposable.
Здравствуйте, criosray, Вы писали:
C>C++ подвергался "демонизации" добрых 10 лет тому назад. Его жестко критиковали даже такие личности, как небезызвестный Линус Торвальдс.
10 лет назад, С++ несколько другой был, как и сознание о способах использования. + альтернативы ему в мейнстриме — не существовало в принципе, так что в 1999м наезды на С++ были разговорами в пользу бедных. Когда там Java 1.5 вышла, где-то в районе 2003-2004го? А второй шарп?
D>>PS: наш сериализатор дает 1.2 гигабайта/секунду потоковую производительность (собственно упираемся в скорость C>чтения/записи памяти) на данных умеренно-сложной структуры (поддерживая при этом возможность частичной десериализации C>Эта цифра абсолютно ни о чем не говорит. Да и сериализация-то у Вас поди бинарная?
Эта цифра например позволяет в терминах сериализации описывать внутренний ABI, не плодя сущностей для перевода сервиса в distributed состояние с сублинейной масшатабируемостью.
Цифра для бинарного варианта, в XML понятное дело помедленнее будет, да и используется только что бы веб-морде данные выплевывать. ORM на наших задачах использовать не только бессмысленно, но и вредно.
D>>PPS: а вот на шарпе аккуратное освобождение ресурсов приходится эмулировать жуткими костылями, дискасс C>Ну уж точно менее жуткими, чем С++ с зоопарками shared_ptr<> auto_ptr<> и прочих костылей.
Стандартизованный костыль перестает быть костылем. Стандартизованный языковым комитетом или внутренним стандартом кодирования — то не суть важно при сколько-нибудь существенных масштабах. ГОСТ — хорошо, но на безрыбье и ТУ сгодится =)
C>Да и что такого жуткого в операторе using?
Ничего, только вот сам по себе, кроме как в примитивных случаях — задачу не решает.
Я вообще мирный человек, на людей не бросаюсь
C>Вы можете предложить лучшее решение?
Последовательное применение концепции владения и времени жизни + инструментальные средства реализации. Второе зависит от языка/платформы, первое — дело сугубо дизайна и дает одинаковый результат будучи реализованных хоть на С++, хоть на Java, хоть другими средствами.
Здравствуйте, NikeByNike, Вы писали:
НС>>Это называется взгляд через замочную скважину.
NBN>Раскрыть можешь?
Могу. Я видел много крупных проектов на шарпе, сериализация в них применялась много и плотно, и с разнообразнейшими целями, среди которых протоколы обмена данными были далеко не на первом месте.
NBN>- сохранение/восстановление в хмл/нативный формат NBN>- клонирование графа NBN>- конвертация графа в нативный формат
Здравствуйте, doarn, Вы писали:
C>>Да и что такого жуткого в операторе using? D>Ничего, только вот сам по себе, кроме как в примитивных случаях — задачу не решает.
А можно парочку примеров непримитивных случаев ?
C>>Вы можете предложить лучшее решение? D>Последовательное применение концепции владения и времени жизни + инструментальные средства реализации. Второе зависит от языка/платформы, первое — дело сугубо дизайна и дает одинаковый результат будучи реализованных хоть на С++, хоть на Java, хоть другими средствами.
Ой, как много умных слов... Давайте Вы всё-таки лучше код покажете, особенно интересует участок, коий "зависит от языка/платформы". И мы сравним с "примитивизмом using'а".
Здравствуйте, drol, Вы писали:
D>Здравствуйте, doarn, Вы писали:
C>>>Да и что такого жуткого в операторе using? D>>Ничего, только вот сам по себе, кроме как в примитивных случаях — задачу не решает. D>А можно парочку примеров непримитивных случаев ?
Когда ресурс (скажем read лок объекта) сохраняется в процессах неизвестного в точке вызова количества с непрогнозируемым временем жизни.
А если время жизни самого ресурса ограниченно?
А если ресурс нужно версионировать? =)
D>Ой, как много умных слов... Давайте Вы всё-таки лучше код покажете, особенно интересует участок, коий "зависит от языка/платформы". И мы сравним с "примитивизмом using'а".
Не хочу
А слова только выглядят умными, реально все сводиться к простейшему принципу — "выстраивай иерархию владения и не передавай владение ресурсом, которым владаеешь, вниз по иерархии". Универсально, практически серебрянная пуля
Здравствуйте, criosray, Вы писали:
ГВ>>Я уж не знаю, почему так складывается, но как только кто-то выступает с резкой критикой C++, так такую пургу нести начинает — уши вянут. C>Такой, как эта?
[...]
Да нет, такой как в топикстарте.
ГВ>>Любая. В твоем мире — если сериализация не встроена в платформу, то её нет, я уже понял. В моём — если какой-то фишки нет, то это означает, что она может быть любой. C>Я еще раз прошу показать универсальный С++ сериализатор XML или Json для любого графа объектов. Двунаправленный. Дженерик (шаблонный).
Сериализовать можно всё, что угодно, только не всякий раз это становится показателем здравого ума и трезвой памяти.
C>Покажете или будете продолжать разводить демагогию и фанатичную чушь без единого факта по теме?
Ты мне сначала покажи такую систему, где нужна сериализация любого графа любых объектов и где эта самая сериализация предварительно не спланирована. А потом — тебе сколько фактов ни дай, тебе всё индифферентно.
C>PS: Правильно тут кто-то недавно заметил, что те, кто хаят С# знают его на уровне чайника...
Как это давно замечено всеми, громче всех хают C++ те, у кого 15 лет опыта — это 15 раз по году, а больше похоже на 30 раз по 6 месяцев.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Ночной Смотрящий, Вы писали:
ГВ>>Сериализация почти всегда нужна в контексте решения задач наподобие построения протокола обмена данными НС>Это называется взгляд через замочную скважину.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Ночной Смотрящий, Вы писали:
CC>>В сравнении с тутошними срачами "C++ vs *" — статья детский лепет и обидки. НС>Да тутошние срачи тоже так себе в плане профессионализма, особенно свеженькие.
Да, оппоненты стали уже не те.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, dmitry_npi, Вы писали:
_>Да нет, я-то сам его люблю. Случайно наткнулся на статью здесь. _>Он не просто его, не любит, он его ненавидит. И других заразить пытается. _>Вот, думаю, тролль Отличная приманка для священной войны.
Сложилось ощущение, что автор долго искал баг, дооолго искал, но не нашел и свалил все на язык.
Вобщем очень многое утрировано.
Как передача в функцию по значению и по ссылке например. Ну что за бред.
Это если я не ошибаюсь в Дейтеле, в 5 главе написано. Делать из этого грабли просто глупо.
Откройте почти любую серьезную книгу (а не С++ за 24 часа) по С++ — о чем там написано ?
Как НЕ НАДО делать.
Scott Meyers: Effective C++, More Effective C++.
Книги о том как НАДО делать.
Да имхо действительно хороших книг по С++, таких как книги Мейерса, не очень то и много.
В связи с довольно частым упоминанием различия между ссылкой и указателем можно сделать смелый однако субъективный вывод что автор
за 15 лет работы понял истинное значение только на седьмом году.
Не так давно я узнал, когда именно г-ну Степанову пришла идея библиотеки STL — когда он находился в отделении интенсивной терапии (после отравления рыбой) в, как он сам написал, "delirium state", по-просту — в состоянии БРЕДА.
Здравствуйте, Antikrot, Вы писали: A>а собственно, и что с того? в чем разница между "нарисовать костыль с operator= " и определить set/get?
В чём разница?
Есть более-менее стандартные вещи, типа "известить об изменении свойства".
Вот, допустим, как-то так:
public class Test
{
public event Action<Test> OnChanged;
private int _a;
public int A
{
get {return _a;}
set
{
if (value == a)
return;
_a = a;
if (OnChanged!=null)
OnChanged(this);
}
}
}
Покажи мне аналог этого кода на C++. И мы поймем разницу невооруженным мозгом.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Геннадий Васильев, Вы писали: ГВ>Ну знаешь, если любую библиотеку так называть, то библиотеки вообще не стоит разрабатывать.
Не, не любую. Но если самая-пресамая библиотека всё еще требует для использовании некоторого паттерна писать кучу кода руками — то это однозначно костыль.
Если посмотреть на linq, то всё становится ясным. Код, который он генерирует для случая linq-to-sql, при конверсии обратно в C#2.0 просто взрывается. Потому что простейшие выражения превращаются в рутинный код порождения метаданных для разнообразных Expression<...>.
Что можно сделать в языке, где нет linq? Правильно, библиотеку для порождения Expression<...>. Увы — многословность будет зашкаливать.
ГВ>Никто и не говорил, что в самом языке C++ есть "свойства".
Да это не проблема. Проблема — в том, что их туда и вставить-то нельзя.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Отличная приманка для священной войны.
