adontz wrote:
> A>>malloc и fopen умрут как категория. По большому счёту разве они ещё > кому-то нужны? > E>Ещё как нужны. > При программировании на Си++? Значит вы один из тех, кому я хочу дать > по рукам
А вы предлагаете работать с файлами при помощи этих &^#%$#&^%$ С++ных
потоков? Ну уж нет, ни за что.
Файловые потоки в С++ — самая отстойно спроектированная часть. Не
верите? Тогда "вопрос на засыпку": как открыть файл с unicode'ным именем
с помощью потоков?
Здравствуйте, Cyberax, Вы писали:
C>А вы предлагаете работать с файлами при помощи этих &^#%$#&^%$ С++ных потоков? Ну уж нет, ни за что. C>Файловые потоки в С++ — самая отстойно спроектированная часть. Не верите? Тогда "вопрос на засыпку": как открыть файл с unicode'ным именем с помощью потоков?
Согласен — стандартные потоки полный отстой, много чего просто нету (например чёткого разделения на random access и forward only потоки). Давно пользуюсь своими. Но любой поток лучше fopen. А использование malloc в Си++ коде это то за что надо нещадно убивать Потому что потом приходят .Net'овцы и говорят — вот у вас в Си++ память течёт. А я сижу и думаю с чего бы? А оказывается это и не Си++ вовсе, а так... Си
adontz wrote:
> C>А вы предлагаете работать с файлами при помощи этих &^#%$#&^%$ > С++ных потоков? Ну уж нет, ни за что. > C>Файловые потоки в С++ — самая отстойно спроектированная часть. Не > верите? Тогда "вопрос на засыпку": как открыть файл с unicode'ным > именем с помощью потоков? > Согласен — стандартные потоки полный отстой, много чего просто нету > (например чёткого разделения на random access и forward only потоки). > Давно пользуюсь своими.
Мне свои лень писать.
> Но любой поток лучше fopen.
Чем? Для бинарного ввода-вывода не особо важно что использовать: fwrite
или stream.write. Закрытие файлов у меня делается автоматически
(использую shared_ptr с перегруженным deleter'ом).
Для текстового вывода ничего удобнее fprintf'а пока еще не придумали
(плевать даже на его типонебезопасность), вот для чтения данных fscanf
уже не так удобен.
> А использование malloc в Си++ коде это то за что надо нещадно убивать > Потому что потом приходят .Net'овцы и говорят — вот у вас в Си++ > память течёт. А я сижу и думаю с чего бы? А оказывается это и не Си++ > вовсе, а так... Си
А чем malloc принципиально от new отличается для POD-типов?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, execve, Вы писали:
A>>>malloc и fopen умрут как категория. По большому счёту разве они ещё кому-то нужны? E>>Ещё как нужны.
A>При программировании на Си++? Значит вы один из тех, кому я хочу дать по рукам
Попробуй.
Только сначала покажи в стандартной библиотеке C++ аналог vprintf и ещё кучи других функций из libc.
Или хотя бы возможность получить FILE* из std::fstream. Или создать std::fstream из FILE*.
Только не надо рассказывать, что это никому (т.е. тебе) не нужно.
Здравствуйте, Cyberax, Вы писали:
C>Мне свои лень писать.
Правильно, я их тебе напишу
C>Чем? Для бинарного ввода-вывода не особо важно что использовать: fwrite C>или stream.write. Закрытие файлов у меня делается автоматически C>(использую shared_ptr с перегруженным deleter'ом).
Плохо. Поток это не только файлы. Это и пайпы и сокеты и просто кусок памяти. Универсальности при использовании fopen нету. Если у меня есть код который пишет BMP файл в поток, то передать BMP файл пос ети для меня не проблема, просто подсовываю другой поток. Хочу шифрование или сжатие? Делаю прокси-поток в который когда пишешь, он данные шифрует и пишет в другой поток. В fopen всей этой гибкости нету.
C>Для текстового вывода ничего удобнее fprintf'а пока еще не придумали (плевать даже на его типонебезопасность)
Опять ошибка. В библиотечке которой я поделился с шахтёром у класса строки есть метод Format аналогичный по синтаксису .Net-оскому. ИМХО
string.Format("You have used {0} megabytes of {1} aviable", 5, 17);
лучше чем
string.Print("You have used %d megabytes of %d aviable", 5, 17);
И дело даже не в типобезопасности, хотя она очень важна и не в возможности повторного использования параметров, а в расшиямости. Я могу передать методу Format любой класс для которого функция _result<string> string_format(const MyType &) определена. Никакой printf не предоставляет таких возможностей.
C>А чем malloc принципиально от new отличается для POD-типов?
Принципиального отличия нету, но и голый new использовать тоже преступление.
Здравствуйте, execve, Вы писали:
E>А что у Вас, извиняюсь, внутри этих потоков? E>CreateFile/(Read|Write)File?
Не только. Может быть и connect если речь о сокетах. А сделать memory mapped files потоком очень важно, но увы средствами стандартной библиотеки никак.
Я знаю два более простых способа решить твои задачи.
1. Используй для написания программ MC++/C++/CLI и из полученных метаданных генерируй нэйтивный код. Реализовать чтение формата дотнетных сборок и темболее генерацию такой кучи кода будет не просто. Но есе же хоть рельно. То что ты описал не захотела поднимать даже МС.
2. Используй C# или MC++ и не морочь людям голуву. Если нужно будет оптимизаций на уровне машинных команд, то воспользуешся тем же МС++ и прагмой заставляющей его генерировать нэйтив-код.
А то что ты написал — это утопия про волшебный костыль которая сделает из С++ серебренную пулю.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Я небуду тебе отвечать словами (всё равно это выльется в 34 страницы бесполезных споров), я лучше суну тебе под нос готовый проект
Отличное решение. Зайти на этот форум через 10 лет? Или свисниш когда будет готово?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>-------------------------------- A>Ограничения A>-------------------------------- A>Язык: Си++ A>Компилятор: Microsoft Visual C++ 7.1 (и 8.0 когда будет релиз) A>Среда разработки: Microsoft Visual Studio
...Жесткая привязка к компилятору и платформе. Некошерно.
A>-------------------------------- A>Введение A>-------------------------------- A> A> Возможность использовать конструкции языка Си, делающие код менее надёжным.
Низзя. Как правило С++ный код активно использует сишные библиотеки. Legacy и не очень.
Примеры: zlib, libpng, expat, pcre и прочая. Так что FILE* malloc и memcpy будут жить вне зависимости от.
Впрочем, никто тебе не запрещает воспользоваться "#pragma deprecated" чтобы заанноить "любителя старины" до самых печенок.
A> Отсутствие поддерживаемых языком свойств и событий.
Что по поводу __declspec(property) а также __event и __hook?
Если уж мы определились с компилятором, а на ISO C++ нам ложить с прибором, то не использовать возможности компилятора на полную катушку есть глупость великая.
A> Отсутствие стандартной библиотеки для создания пользовательского интерфейса.
MFC? WTL? QT, наконец?
Опять-таки: мы определились с компилятором. Он существует только под Windows. Ergo, любую гуёвую для них библиотеку мы спокойно можем обьявлять "стандартной" и не изобретать велосипед о пяти колесах.
A> Отсутствие средств сериализации.
Согласен.
A> Отсутствие метапрограммирования и их замена малопонятными и трудноотлаживаемыми конструкциями из шаблонов и макросов.
Согласен, но. Метапрограммирование как правило окупается только в повторно используемом коде.
В коде конечного приложения, заточенного под решение конкретной задачи, потребность в нем минимальна.
A> Отсутсвие СОМ Interop
#import? __interface?
A>
Резюме: Если опираться только на MSVC, то проект по большому счету не имеет смысла — почти все из перечисленного поддерживается. Если же на MSVC не опираться, то какой-то смысл прослеживается, но без четко сформулированных задач проекта, он выглядит как куча достаточно несерьезных "хотелось бы".
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
A>>Среда разработки: Microsoft Visual Studio DEA>...Жесткая привязка к компилятору и платформе. Некошерно.
Это скорее простой способ всё автоматизировать, чем использование особенностей компилятора.
DEA>Впрочем, никто тебе не запрещает воспользоваться "#pragma deprecated" чтобы заанноить "любителя старины" до самых печенок.
Эти библиотеки могут компоноватся с стандартной CRT. Ркчь идёт только о новом коде.
DEA>Что по поводу __declspec(property) а также __event и __hook?
__declspec(property) не использует неявные приведения типов. Например если свойство принимает какой-то COleString и передаётся BSTR, то вызывать конструктор COleString придётся вручную. В результате больше хлопот, чем пользы.
__event и __hook это здорово, но этого мало, чтобы прозрачно связывать свойства. Например когда я пишу obj1.prop1.bind(obj2.prop2) я хочу чтобы prop1 подписывалось на событие prop2.OnChange и изменяло свой значение соответственно. Причём чтобы это событие (так же как скажем, OnDestroy и проч.) было частью ствойства.
DEA>Если уж мы определились с компилятором, а на ISO C++ нам ложить с прибором, то не использовать возможности компилятора на полную катушку есть глупость великая.
Как раз на компилятор мне вообще прлевать. Мне куда важнее была среда разработки, где определённую последовательность операций можно легко автоматизировать. В принципе я нежу причин, почему не сделать тоже самое для GCC, но всё то что для MSVC хорошо документированно в GCC практически тайна, разгадывать которую можно по исходникам.
DEA>Согласен, но. Метапрограммирование как правило окупается только в повторно используемом коде. DEA>В коде конечного приложения, заточенного под решение конкретной задачи, потребность в нем минимальна.
A>> Отсутсвие СОМ Interop DEA>#import? __interface?
Здравствуйте, adontz, Вы писали:
A>>>Среда разработки: Microsoft Visual Studio DEA>>...Жесткая привязка к компилятору и платформе. Некошерно. A>Это скорее простой способ всё автоматизировать, чем использование особенностей компилятора.
DEA>>Впрочем, никто тебе не запрещает воспользоваться "#pragma deprecated" чтобы заанноить "любителя старины" до самых печенок.
A>Эти библиотеки могут компоноватся с стандартной CRT. Ркчь идёт только о новом коде.
Проблема не в компоновке, а в том, как эту библиотеку юзать. Ведь она-то Сишная. Следовательно, проблемы очистки ее ресурсов никуда не денутся т.е. если я вызвал CreateSomething, то должен озаботиться вызвом DestroySomething. Та же проблема что и с malloc/free и fopen/fclose — вид сбоку.
Единственное вменяемое решение здесь — предоставить SmartHandle (Handle — это все что нуждается в уничтожении, но не память) в чем-то аналогичный SmartPtr. Причем этот SmartHandle должен поддерживать достаточно широкий набор моделей владения, чтобы не повторилась история с std::auto_ptr
DEA>>Что по поводу __declspec(property) а также __event и __hook? A>__declspec(property) не использует неявные приведения типов.
Прискорбно. Но, по крайней мере, это единственный способ добавить пропертя без оверхеда по размеру класса.
Что же касается реализации пропертей которую ты приводил (афаик это самая лучшая реализация), то она обладает прегадостным свойством — генерирует оверхед 1 байт на пропертю. В принципе, не так уж и много, но если пропертей несколько десятков... Жаба душит.
Тем более, что любая реализация пропертей потребует вторжения в определение класса — хотя бы для того чтобы пропертю эту добавить. Немногим программистам это понравится.
Лично я бы от них отказался.
A>__event и __hook это здорово, но этого мало, чтобы прозрачно связывать свойства. Например когда я пишу obj1.prop1.bind(obj2.prop2) я хочу чтобы prop1 подписывалось на событие prop2.OnChange и изменяло свой значение соответственно. Причём чтобы это событие (так же как скажем, OnDestroy и проч.) было частью ствойства.
Еще неплохо бы их приспособить для варки кофе, уборки в квартире и танцев живота
Впрочем, какие бы еще навороты не потребовались, это дело выливается в одно и тоже — ручная реализация пропертей и, как следствие, вышеописанные проблемы, если не больше.
DEA>>Если уж мы определились с компилятором, а на ISO C++ нам ложить с прибором, то не использовать возможности компилятора на полную катушку есть глупость великая.
A>Как раз на компилятор мне вообще прлевать. Мне куда важнее была среда разработки, где определённую последовательность операций можно легко автоматизировать.
Лично я бы не полагался на парсинг C++ предоставляемый студией. Он весьма глюкав.
A>В принципе я нежу причин, почему не сделать тоже самое для GCC, но всё то что для MSVC хорошо документированно в GCC практически тайна, разгадывать которую можно по исходникам.
GCC достаточно плотно следует стандарту. Особенно последние несколько лет. Все девиации (а их не так уж и много) описаны в сопроводительной документации. Если есть место куда ее можно выложить на RSDN в .CHM — давай выложу. Будет полезно и тебе и другим.
Впрочем, существуют еще Borland, Metrowerks, Comeau, aCC и прочая. Если делать, то делать надо без привязки к какому бы ни было диалекту. Следовательно — стандарт — настольная книга.
A>>> Отсутсвие СОМ Interop DEA>>#import? __interface? A>Это для использования. А для создания объектов?
__interface В смысле Attributed ATL. Средств для создания COM-обьектов — вагон и маленькая тележка груженая по самые борта.
ЗЫ. Еще _очень_ хотелось бы увидеть детальный список задач который данный "Visual Generator" призван решить...
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
A>>Эти библиотеки могут компоноватся с стандартной CRT. Ркчь идёт только о новом коде. DEA>Проблема не в компоновке, а в том, как эту библиотеку юзать. Ведь она-то Сишная. Следовательно, проблемы очистки ее ресурсов никуда не денутся т.е. если я вызвал CreateSomething, то должен озаботиться вызвом DestroySomething. Та же проблема что и с malloc/free и fopen/fclose — вид сбоку.
Эту проблему никто никогда не уберёт. Библиотеку надо будет просто переписать на Си++. Другое дело, что давать по рукам при написании нового кода ИМХО надо. Большинство тех, кто думает, что пишет на Си++, на самом деле пишут на смеси Си++ и Си.
DEA>Прискорбно. Но, по крайней мере, это единственный способ добавить пропертя без оверхеда по размеру класса. DEA>Что же касается реализации пропертей которую ты приводил (афаик это самая лучшая реализация), то она обладает прегадостным свойством — генерирует оверхед 1 байт на пропертю. В принципе, не так уж и много, но если пропертей несколько десятков... Жаба душит.
Вот — постараюсь сделать так, чтобы не было этого 1 байта
DEA>Тем более, что любая реализация пропертей потребует вторжения в определение класса — хотя бы для того чтобы пропертю эту добавить. Немногим программистам это понравится.
Ну а куда от этого деватся?
DEA>Лично я бы не полагался на парсинг C++ предоставляемый студией. Он весьма глюкав.
В 7.1? Да ну...
DEA>GCC достаточно плотно следует стандарту. Особенно последние несколько лет. Все девиации (а их не так уж и много) описаны в сопроводительной документации. Если есть место куда ее можно выложить на RSDN в .CHM — давай выложу. Будет полезно и тебе и другим.
DEA>Впрочем, существуют еще Borland, Metrowerks, Comeau, aCC и прочая. Если делать, то делать надо без привязки к какому бы ни было диалекту. Следовательно — стандарт — настольная книга.
Дело не в компиляторе, а в том насколько его можно использовать в сторонних целях.
DEA>__interface В смысле Attributed ATL.
А ну да, это как раз самый что ни на есть Си++
DEA>ЗЫ. Еще _очень_ хотелось бы увидеть детальный список задач который данный "Visual Generator" призван решить...
Потому что потом приходят .Net'овцы и говорят — вот у вас в Си++ память течёт. А я сижу и думаю с чего бы? А оказывается это и не Си++ вовсе, а так... Си
