Comments 129
А как же дотнет?
Не managed единым. Сейчас я не вижу нормальных инструментов для разработки GUI-шных приложений под native api. А ведь писать различные мелкие трояны утилиты на дотнете — это просто издевательство над пользователем.
Qt&C++ отличное решение.
Qt — набор костылей для стремительно устаревающего С++
недаром Qt сползает в сторону QML, WebKit и JavaScript
недаром Qt сползает в сторону QML, WebKit и JavaScript
Я вам ооочень рекомендую продолжать думать так же, мне будет гораздо легче искать работу.
рекомендовать это ваше право, я сам на Qt разрабатываю коммерческий проект, понимаю о чем говорю
>понимаю о чем говорю
Вот у меня как-то не сложилось такого впечатления, но вы это не теряйтесь и не обращайте на меня внимания, кто я такой что бы что-то вам советовать, вы ведь разрабатываете, подумать только, аж коммерческий проект, не то что я тут на хабр зашел пописать, убедите все свое руководство перейти на что-нить «новое», «современное» ruby, там erlang отличное решение, ещё F# можно, ну подумаешь в несколько раз медленнее, кадров не найдешь, но ведь зато как прогрессивно то будет, а скорость разработки ну совсем не такая как на этом дохлом С++.
Вот у меня как-то не сложилось такого впечатления, но вы это не теряйтесь и не обращайте на меня внимания, кто я такой что бы что-то вам советовать, вы ведь разрабатываете, подумать только, аж коммерческий проект, не то что я тут на хабр зашел пописать, убедите все свое руководство перейти на что-нить «новое», «современное» ruby, там erlang отличное решение, ещё F# можно, ну подумаешь в несколько раз медленнее, кадров не найдешь, но ведь зато как прогрессивно то будет, а скорость разработки ну совсем не такая как на этом дохлом С++.
Qt выбран не от большой любви и прогрессивности, а как действительно кроссплатформенный фреймворк. Альтернатив-то практически нет. Все остальное или не дотягивает по функциональности или малопопулярно
Ну суть в чем, с++ не устаревает и не устареет никогда, или когда изменятся базовые принципы программирования, но это судя по всему не случится никогда. Другое дело что для спец задач придумать спец язык гораздо лучше. Это мы как раз и видим в QML. Глупо ведь описывать на с++ запрос к данным, гораздо лучше это сделать через sql, то же самое и с задачами где требуется активная манипуляция нетипизированными данными, например web, я очень смутно себе представляю как на с++ можно сделать автоматический мапинг данных с http запроса в структуры данных. Никто же не говорит что с изобретением скейтборда велосипеды устареют, так и тут. Видел как писали свои предметно-ориентированные языки, но никто не говорил что с++ устареет.
GUI действительно проще писать, а может даже скорее описывать, на каком либо DSL языке, но это никак не связанно с с++. Есть другая причина перехода на SDL, а именно: когда есть ограниченный легкий и понятный интерфейс для манипуляции чем либо гораздо сложнее разбить себе лоб неправильными действиями и легче найти более дешевые кадры для этого. Ведь программирование GUI и это достаточно скучная рутинная работа.
GUI действительно проще писать, а может даже скорее описывать, на каком либо DSL языке, но это никак не связанно с с++. Есть другая причина перехода на SDL, а именно: когда есть ограниченный легкий и понятный интерфейс для манипуляции чем либо гораздо сложнее разбить себе лоб неправильными действиями и легче найти более дешевые кадры для этого. Ведь программирование GUI и это достаточно скучная рутинная работа.
Суть в том что спектр задач, решаемых на С++ неуклонно сужается, и из универсального языка он превращается в узко специализированный, как это случилось с ассемблером. Именно это я и понимаю под устареванием
До узко специализированного ему ещё ох как далеко, но в общем да, круг задач становится меньше, точнее как его сначала начали пихать везде где надо и где нет, а потом сделали специализированные решения, скорее так дело было. Но в любом случае это не устаревание. Специализация что ли. Мы же не говори что второй закон Ньютона устарел после открытия СТО.
А я как-то не вижу, что сужается. Вернее в одном месте сужается (его всё реже используют как… хм… клей), но в другом расширяется — всё больше пишут библиотек/модулей, которые между собой связываются другим языком или просто биндятся к нему.
P.S. Я про C/C++ как про одно говорю.
P.S. Я про C/C++ как про одно говорю.
Для троянов есть консольный компилятор, winapi и майкрософтовский(!) make.
Наработки товарищей из microsoft research по языкам программирования к сожалению используют только в managed.
Наработки товарищей из microsoft research по языкам программирования к сожалению используют только в managed.
зато любое .NET приложение уместится в 640 Кб на диске. Гейтс таки прав был :)
Вообще неэффективность расходования памяти дотнетом меня жутко бесит. Такое чувство, что сколько ему ядер, гигагерц и гигабайт не давай — сожрет всё и не подавится. Изоляцию кода необязательно делать через managed-исполнение, мы же в защищенном режиме работаем…
На хабре были статьи про оптимизацию приложений как в потреблении памяти, так и производительности.
Может просто стоит научиться пользоваться интструментом сначала?
Может просто стоит научиться пользоваться интструментом сначала?
Вы просто не умеете его готовить.
Для embeded систем — возможно и да, но для совсем харкорных решений на чипах и то, там и с++ жирен, в почете голый с.
Managed (.net, java) — давно уже обосновался и на телефонах, и на серверах финансовых бирж. И уже лет 10 я не слышал притензий по прожорливости при разработке корпоративных приложений.
Managed (.net, java) — давно уже обосновался и на телефонах, и на серверах финансовых бирж. И уже лет 10 я не слышал притензий по прожорливости при разработке корпоративных приложений.
Гейтс никогда не говорил про 640 кб памяти.
Многие удивятся, но делфи (ныне RAD Studio) до сих пор жив и на нем развиваются вполне современные реальные проекты. Даже вот пару лет назад Юникод появился ;-) Одна беда x64 пока в бета-тестировании, обещают к осени. Это действительно до сих пор удобный инструмент для быстрого создания native приложений.
хотелось бы видеть в новом языке простоту С# и скорость С++
Если взять Visual C++ 6.0, немножко подобновить, чтобы работала без проблем на современных системах, то можно выпускать ее в составе Visual Studio 2012. И опытные программисты будут рады (так как вернется ТА САМАЯ система), и новички (так как увидят скорость и стабильность среды). А если еще и MSDN тех времен выпустить…
Допилили бы MFC до юзабельного уровня. А то он застрял в лихих девяностых.
Это похоже и собираются сделать.
Это макросовое безумие уже невозможно допилить, только закопать )))
В идеале что-то вроде старого доброго VCL. C компиляцией в native-код и поддержкой пары-тройки популярных языков. Что-то такое было у Borland Codegear Embarcadero, но сейчас оно как-то слабоюзабельно.
Установленная vc 6.0 до сих пор не редкость.
В статье упоминаются «новые разработки в языке C++». А как же стандарты?? Они хотят язык переделать/доделать или это неточный перевод и имелось в виду «разработки НА языке С++»? Кто-нибудь может уточнить? Или это будет новый язык, который не С++, но похож, а посему и стандарту следовать не надо?
Нативные инструменты разработки MS давно не обновляла и ничего нового и удобного не предлага, чтоб на C++ написать нормальное приложение во вменяемый срок надо тянуть с собой какой-нибудь фреймворк и соответствущие либы. Я так понял речь идет о создании аналога некоего Objective C, но для Win платформы. Я только за.
UFO just landed and posted this here
UFO just landed and posted this here
WinC++ звучит как термин из 90-х.
компания прилагает определенные усилия, чтобы поднять оборот продаж Visual Studio с текущей отметки в 1 с лишним миллиард долларов до 2 миллиардов.
У меня есть революционная идея которую я готов бесплатно им предложить для достижения вышеозначенной цели: взять 10% от денег которые они тратят на раскрутку и нанять вменяемого юзабилити-специалиста.
VS2010 хоть и стал лучше, но всё равно остался средненьким херопродуктом с точки зрения удобства использования. И, по моему, ещё не существует таких конфигураций железа на которых он мог бы работать с вменяемой скоростью.
У меня есть революционная идея которую я готов бесплатно им предложить для достижения вышеозначенной цели: взять 10% от денег которые они тратят на раскрутку и нанять вменяемого юзабилити-специалиста.
VS2010 хоть и стал лучше, но всё равно остался средненьким херопродуктом с точки зрения удобства использования. И, по моему, ещё не существует таких конфигураций железа на которых он мог бы работать с вменяемой скоростью.
По поводу скорости люто бешено плюсую, очень уж раздражает временами…
а мы то дураки даже под Qt на студии разрабатываем, а оно вон чё оказывается
А я каждый день на метро езжу. Наверное питерское метро идеально.
А кто говорил про идеальность? Или в Питере есть другое метро?
я тоже не говорю что для разработки под C++ и Windows есть что-то лучше (но не возьмусь утверждать что нет). Только описываю своё видиние UI VS сравнивая её решения с решениями в других desctop приложениях.
ну так сравнивайте. В ваших коментах не упомянута ни одна другая IDE
Почему именно IDE? IDE объядиняет в себе множество компонентов которые используются и в других продуктах. Мне не приходилось много пользоваться другими IDE, т.е. здесь мне сравнивать не с чем.
Но мне и не нужно ни с чем сравнивать, чтобы понять что окошко свойств, в котором может быть много текста должно уметь растягиватся, а edit-combo не должно менять своё значение на какое-то другое* когда я пытаюсь выделить текущее значение двойным кликом.
Ну я не знаю сколько ещё примеров нужно привести чтобы вы поверили что юзабилити тестирование MS проводило на инопланетянах.
Но мне и не нужно ни с чем сравнивать, чтобы понять что окошко свойств, в котором может быть много текста должно уметь растягиватся, а edit-combo не должно менять своё значение на какое-то другое* когда я пытаюсь выделить текущее значение двойным кликом.
Ну я не знаю сколько ещё примеров нужно привести чтобы вы поверили что юзабилити тестирование MS проводило на инопланетянах.
у меня работает нормально VS2010 + Resharper 5 + пару плагинов. Core 2 Duo 2400Mhz, 4GB RAM
Солюшены 6+ проектов, строк кода не мало
Солюшены 6+ проектов, строк кода не мало
VS2010 SP1+ Resharper 5. Core 2 Duo (не помню какой), 4GB RAM
Солюшен 1 проект.
Я вижу задержку между нажатием клавиши и её появлением на экране.
Солюшен 1 проект.
Я вижу задержку между нажатием клавиши и её появлением на экране.
На Acer ноуте с 1 гигом оперативки и WinXP стоит CS2010 SP1 Ultimate.
У меня открывается и работает все отлично и быстро. Задержек между нажатием и появлением на экране не наблюдаю.
Дальше письками меряться будем?
У меня открывается и работает все отлично и быстро. Задержек между нажатием и появлением на экране не наблюдаю.
Дальше письками меряться будем?
Похожая конфигурация у меня на лаптопе (Lenovo N300), солюшн из 20 проектов летает, никаких задержек.
Мне кажется, в решарпере проблема. У меня студия летала, пока я себе не поставил его.
какой то адский ксенон с 16 ядрами, 12 гигов ddr3 оперативки, как комментатор сверху «я вижу задержку между нажатием клавиши и её появлением на экране.»
Сам сижу и не понимаю, откуда блин?
Сам сижу и не понимаю, откуда блин?
Значит что-то в фоне работает тяжелое.
Обычо студия через 10-15 секунд выдает сообщение о загрузке.
Если этого нет, то это может быть ReSharper что-то там большое индексирует.
Проблема с «задержкой» у меня появляется только при добавлении к проекту больших (больше 3-5 Мб) XML файлов данных, которые почему-то начинает ииндексировать ReSharper. Но это всегда можно увидеть по индикатору в левом нижнем углу и там же остановить.
Обычо студия через 10-15 секунд выдает сообщение о загрузке.
Если этого нет, то это может быть ReSharper что-то там большое индексирует.
Проблема с «задержкой» у меня появляется только при добавлении к проекту больших (больше 3-5 Мб) XML файлов данных, которые почему-то начинает ииндексировать ReSharper. Но это всегда можно увидеть по индикатору в левом нижнем углу и там же остановить.
Я ещё могу понять что мой коментарий минусуют, но mephisto?!
Люди из MS, палитесь.
Люди из MS, палитесь.
Ну накидайте явные ляпы, а не просто языком молите, а?
Это тема для статьи.
Один пример: MSVS это единственный известный мне текстовый редактор который умеет копировать пустую строчку.
Один пример: MSVS это единственный известный мне текстовый редактор который умеет копировать пустую строчку.
В чём бага?
Это не бага, а издевательство:
1. Копируешь строчку (Ctrl+C), прокручиваешь на несколько экранов, ставишь курсор на место вставки, жмёшь Ctrl+V. — Ой, случайно нажал на Ctrl+C (они рядом), в буфере пустая строка.
Прокручиваешь назад, goto 1
1. Копируешь строчку (Ctrl+C), прокручиваешь на несколько экранов, ставишь курсор на место вставки, жмёшь Ctrl+V. — Ой, случайно нажал на Ctrl+C (они рядом), в буфере пустая строка.
Прокручиваешь назад, goto 1
Ну не знаю, я за несколько лет ни разу не сталкивался.
Ещё есть?
Ещё есть?
Есть конечно :) Напирмер такая мелочь: не все окна свойств растягиваются. Двадцать первый век блин!
Злит то, что большинство недостатков легко фиксятся, но похоже всем пофиг.
Ну а вашей хорошей моторике можно только позавидовать :)
Впрочем о не идеальной моторике многих людей было известно все создателям текстовых редакторов, поэтому они добавили один if в обработчик копирования.
— Как эту проблему решили в MS: они сделали настройку(!)* «Не копировать пустую строчку» — это вместо того чтобы сделать сразу нормально.
*К сожалению о существовании этой опции я узнал только год назад,
Злит то, что большинство недостатков легко фиксятся, но похоже всем пофиг.
Ну а вашей хорошей моторике можно только позавидовать :)
Впрочем о не идеальной моторике многих людей было известно все создателям текстовых редакторов, поэтому они добавили один if в обработчик копирования.
— Как эту проблему решили в MS: они сделали настройку(!)* «Не копировать пустую строчку» — это вместо того чтобы сделать сразу нормально.
*К сожалению о существовании этой опции я узнал только год назад,
> Есть конечно :) Напирмер такая мелочь: не все окна свойств растягиваются. Двадцать первый век блин!
Хм, приведите пример, если можно.
— Как эту проблему решили в MS: они сделали настройку(!)* «Не копировать пустую строчку» — это вместо того чтобы сделать сразу нормально
А Вам не кажется, что стоило бы потратить пару-тройку часов на изучение IDE в которой Вы работаете, прежде чем предъявлять такие претензии.
Я регулярно веду курсы по Visual Studio и в течение первых полутора-двух часов прохожу все основные комбинации клавиш и базовые настройки. И после этого у большинства не возникает никаких вопросов.
Хм, приведите пример, если можно.
— Как эту проблему решили в MS: они сделали настройку(!)* «Не копировать пустую строчку» — это вместо того чтобы сделать сразу нормально
А Вам не кажется, что стоило бы потратить пару-тройку часов на изучение IDE в которой Вы работаете, прежде чем предъявлять такие претензии.
Я регулярно веду курсы по Visual Studio и в течение первых полутора-двух часов прохожу все основные комбинации клавиш и базовые настройки. И после этого у большинства не возникает никаких вопросов.
На сайтах майкрософта пробовали жаловаться?
Там разработчики вполне себе отвечают.
Там разработчики вполне себе отвечают.
Вот ещё яркий пример: содержимое большинства окон (например список файлов проекта) не прокручивается колёсиком пока на него не переведёшь фокус. Меня как-то слабо волнует что это стандартное поведение ListView, это не удобно.
Зачем прокручивать назад? Есть же Ctrl + "-" для перемещения на одну из предыдущих позиций курсора, и Ctrl + Shift + "-" для обратного перемещения.
Это здорово (без сарказма). Я вот про них не знал.
Но наличие расширенного способа навигации не решает проблему, а маскирует её.
Но наличие расширенного способа навигации не решает проблему, а маскирует её.
То, что вы не знали про настройку и про шорткаты — это не проблема IDE, а проблема чисто ваша. Оно конечно понятно, что не барское это дело маны читать, но IDE то, строго говоря, ни при чём.
Откройте для себя Ctrl-Shift-Insert (вставляет по очереди предыдущие состояния буфера обмена).
Дополнительные возможности это хорошо, но зачем ломать привычки пользователей?
Собственно см. мой комментарий выше.
Собственно см. мой комментарий выше.
Ну, для того, чтобы не ломать привычки и сделали флажок в настройке. Я, к примеру, часто копирую строку, не выделяя её, и думаю, что не одинок в этом.
На счёт привычки спорить бесполезно.
Но вот за создание таких привычек нужно отрывать руки, и вот почему:
Новое поведение (вроде нигде больше оно не используется):
1) Обманывает ожидания тех, кто привык к старому.
2) Провоцирует ошибки (при промахе V<->C)
3) Вообще не очевидно (проводится операция над невыделенным текстом).
Будь они умнее они бы или не стали делать такую фичу вообще (уверен, никто бы не расстроился). А будь ещё умнее, сделали бы её Word-like (выделение строки по тройному клику) — длиннее но самоочевидно.
Но вот за создание таких привычек нужно отрывать руки, и вот почему:
Новое поведение (вроде нигде больше оно не используется):
1) Обманывает ожидания тех, кто привык к старому.
2) Провоцирует ошибки (при промахе V<->C)
3) Вообще не очевидно (проводится операция над невыделенным текстом).
Будь они умнее они бы или не стали делать такую фичу вообще (уверен, никто бы не расстроился). А будь ещё умнее, сделали бы её Word-like (выделение строки по тройному клику) — длиннее но самоочевидно.
Это не новое поведение, оно для Вас является новым.
Я вообще не использую мыши при работе с IDE и мне вот очень удобно именно такой способ брать строку в буфер, не пытаясь наживать всякие Ctrl-Home + Shift-End.
Я вообще не использую мыши при работе с IDE и мне вот очень удобно именно такой способ брать строку в буфер, не пытаясь наживать всякие Ctrl-Home + Shift-End.
И вообще, что мешает Вам поставить вот этот плагин:
visualstudiogallery.msdn.microsoft.com/59ca71b3-a4a3-46ca-8fe1-0e90e3f79329/
У меня он, например, стоит :)
visualstudiogallery.msdn.microsoft.com/59ca71b3-a4a3-46ca-8fe1-0e90e3f79329/
У меня он, например, стоит :)
Студия тем и отличается от блокнота, что в ней есть дополнительные возможности. Если бы их не было — её бы никто не покупал.
UFO just landed and posted this here
Это не баг, это фича!!! :)
Пишу с нетбука и Студии нет под рукой, но в Options -> Text Editor есть настройка «Do not copy empty text into clipboard» (как-то так примерно), включив которую Вы больше не сможете скопировать пустой текст в буфер обмена.
Причем эта настройка еще с 2005 студии есть :)
Пишу с нетбука и Студии нет под рукой, но в Options -> Text Editor есть настройка «Do not copy empty text into clipboard» (как-то так примерно), включив которую Вы больше не сможете скопировать пустой текст в буфер обмена.
Причем эта настройка еще с 2005 студии есть :)
А выпустим ка свой С++, только с блекжеком и шлюхами COM+'ами и XAML'ами :)
Недошли. У меня в 2004 году было такое ощущение, что Майкрософт перестали обновлять unmanaged среду разработки, только потому, что в очень скором времени появится полностью managed операционка, на которую они всех и загонят. В этом я убедился и того более, когда увидел первую бэту 2005 студии. Собственно говоря — дотнет рос и ширился, как дрожжи в печке. А вот из всех плюсов неуправляемого кода я заметил только тот небольшой факт, что стали лучше поддерживаться юникодовые строки.
Собственно говоря, прошло шесть лет. Полностью управляемой операционки пока нет. Первый шаг к тому — Windows 7 Mobile. Но ей пока не до десктопа. Так что, никаких грандиозных нововведений разработчики неуправляемого не получали уже много лет.
Теперь, моя мысль такова — данный ход от Майкрософт — последняя бочка мёда в ложке дёгтя для неуправленцев. Неуправляемое ещё будет существовать в течении 5-ти лет, а потом уже уйдёт на покой. И вот на эти пять лет они и решили выпустить хорошую, годную, верную платформу, которая сможет удовлетворить тех разработчиков, которым критически нужна скорость и возможность делать меморилики.
P.S. Не то, чтобы неуправляемое — это высшее зло вселенной. Нет. Просто оно уже устарело. И Майкрософт на него ставку делать не хочет.
Собственно говоря, прошло шесть лет. Полностью управляемой операционки пока нет. Первый шаг к тому — Windows 7 Mobile. Но ей пока не до десктопа. Так что, никаких грандиозных нововведений разработчики неуправляемого не получали уже много лет.
Теперь, моя мысль такова — данный ход от Майкрософт — последняя бочка мёда в ложке дёгтя для неуправленцев. Неуправляемое ещё будет существовать в течении 5-ти лет, а потом уже уйдёт на покой. И вот на эти пять лет они и решили выпустить хорошую, годную, верную платформу, которая сможет удовлетворить тех разработчиков, которым критически нужна скорость и возможность делать меморилики.
P.S. Не то, чтобы неуправляемое — это высшее зло вселенной. Нет. Просто оно уже устарело. И Майкрософт на него ставку делать не хочет.
Меморилики можно делать и в управляемой среде.
Да, до этого я не дошёл. Мне ещё есть чему поучиться.
Ничего, я вот и до мемори ликов в неуправляемой среде не дошёл.
Ну до этого не далеко идти — просто забудьте как-то отписаться от ивента когда объект уже не нужен — вот и готов «меморилик».
Смешно? А ведь насколько часто я в больших проектах вижу что-то типа button.onclick += ..., и никаких "-=". Особенно весело когда добавляют лямбду к другому объекту с замыканием на какое-то свойство первого объекта.
Так что проще простого — это только один из кучи простейших способов поиметь меморилики в менеджд среде.
Смешно? А ведь насколько часто я в больших проектах вижу что-то типа button.onclick += ..., и никаких "-=". Особенно весело когда добавляют лямбду к другому объекту с замыканием на какое-то свойство первого объекта.
Так что проще простого — это только один из кучи простейших способов поиметь меморилики в менеджд среде.
Смешно? А ведь насколько часто я в больших проектах вижу что-то типа button.onclick += ..., и никаких "-=". Особенно весело когда добавляют лямбду к другому объекту с замыканием на какое-то свойство первого объекта.
А зачем резрегистрировать обработчик, если не «особенно весело»?
Я часто добавляю динамически обработчики при динамическом создании контролов внутри формы (или веб-страницы): тут нет внешних привязок и нет проблем для сборщика мусора.
А зачем резрегистрировать обработчик, если не «особенно весело»?
Я часто добавляю динамически обработчики при динамическом создании контролов внутри формы (или веб-страницы): тут нет внешних привязок и нет проблем для сборщика мусора.
У Вас эти контролы удаляются? Если только добавляются то все нормально — при удалении формы, контролы удалятся. А вот если у вас динамически появляются-пропадают контролы на форме и Вы не отписываетесь от события, то это как краз совершенно классический пример мемори лика.
Псевдо-код демонстрирующий:
с первого взгляда довольно чисто, но вот после DoNothing-а памяти чуток уменьшится.
Псевдо-код демонстрирующий:
Form form = new Form();
void DoNothing() {
for (var i = 1; i<10000; i++) {
var c = CreateCoolControl();
form.Controls.Add( c );
// тут мы решили что надо удалить (или прошло некоторое время)
form.Controls.Remove( c );
}
}
Control CreateCoolControl() {
var control = new CoolControl();
// тут мы "настраиваем" наш контрол
control.Title = ....
form.OnPaint += control.onPaint(); // вешаем событие - вроде как часть конфигурирования
return control;
}
с первого взгляда довольно чисто, но вот после DoNothing-а памяти чуток уменьшится.
Здесь всё понятно, но я не вижу в Вашем коде
что-то типа button.onclick += ...
В случае:
… вроде бы проблем быть не должно.
что-то типа button.onclick += ...
В случае:
Public Form frm = new Form();
void AddControl() {
Button b = new Button();
b.OnClick += new MouseClickEvent(a, e => MsgBox.Show(a.Text));
frm.Controls.Add(b);
}
void DeleteControl (Button c) {
frm.Controls.Remove©);
}
… вроде бы проблем быть не должно.
можно и не делать, она сама их сделает
Точно также, как делать вменяемые сборщики мусора в неуправляемой среде. А фактически же при вызове delete в плюсах память тоже не высвобождается сразу, а просто помечается как свободная.
Да бог с ней с управлением памяти, не такая уж огромная проблема. В плюсах тоже сейчас фактически мало, кто руками за памятью следит. Фишка managed в очень хорошем RTTI, которого в плюсах вовсе и нету. Зато за счет отсутствия полноценного RTTI плюсы жрут меньше памяти и быстрее работают.
Впрочем в Qt есть и RTTI и автоматизированное управление памятью, но синтаксис конечно не такой стройный, ибо фичи сделаны через эмуляцию. Но в целом это работает очень хорошо, если забить на некоторые проблемы с синтаксисом (ну например злые конструкции типа QMetaMethod::invoke()).
Впрочем в Qt есть и RTTI и автоматизированное управление памятью, но синтаксис конечно не такой стройный, ибо фичи сделаны через эмуляцию. Но в целом это работает очень хорошо, если забить на некоторые проблемы с синтаксисом (ну например злые конструкции типа QMetaMethod::invoke()).
В Qt чтоб сделать удобно сериализуемый класс, нужно заюзать как минимум три макроса (Q_OBJECT, Q_PROPERTY, Q_DECLARE_METATYPE), написать два дополнительных конструктора да еще и qRegisterMetaTypeStreamOperators() не забыть. И сами операторы написать. И все равно ручками придется перебрать всё проперти. Жесть как она есть.
Я прям тоскую по VCL, насколько там все естественно и удобно сериализовалось. Хотя .NET конечно выигрывает у VCLя в этом плане.
Я прям тоскую по VCL, насколько там все естественно и удобно сериализовалось. Хотя .NET конечно выигрывает у VCLя в этом плане.
Вообще-то вы сейчас способ через задницу описали. Через QMetaProperty оно делается на раз два три без каких-либо доп требований от класса, кроме Q_PROPERTY и Q_OBJECT. Поэтому увы, надо доки читать перед тем, как вбросы делать ;)
А qRegisterMetaTypeStreamOperators() и два оператора плюс пустой конструктор нужен для производных от QVariant'а.
Короче смешались в кучу люди, кони!
А qRegisterMetaTypeStreamOperators() и два оператора плюс пустой конструктор нужен для производных от QVariant'а.
Короче смешались в кучу люди, кони!
А как простите десериализовать объект если не известно что это за объект? Через QVariant
Так же как и сериализовывать ёлки палки. Про Q_DECLARE_METATYPE не слышали?
Я вообще-то про него и написал. Так вот чтобы Q_DECLARE_METATYPE применить классу, унаследованному от QObject? в нем должен быть дефолтный конструктор и конструктор копии, это раз.
Второе, есть у вас, скажем QDataStream. Там лежит некий серилизованный объект, неизвестно какой, знаем что QObject. Как вычитав ЭТО создать объект нужно класса?
Очевидно вычитать в QVariant. Для чего придется регистрировать потоковые операторы при помощи qRegisterMetaTypeStreamOperators().
Либо при записи самому пихать идентификатор класса и самому его анализировать при чтении, что уже какбэ лисапед.
Второе, есть у вас, скажем QDataStream. Там лежит некий серилизованный объект, неизвестно какой, знаем что QObject. Как вычитав ЭТО создать объект нужно класса?
Очевидно вычитать в QVariant. Для чего придется регистрировать потоковые операторы при помощи qRegisterMetaTypeStreamOperators().
Либо при записи самому пихать идентификатор класса и самому его анализировать при чтении, что уже какбэ лисапед.
>Я вообще-то про него и написал. Так вот чтобы Q_DECLARE_METATYPE применить классу, унаследованному от QObject? в нем должен быть дефолтный конструктор и конструктор копии, это раз.
За конструктор копии в QObject'е надо сразу яйца отрывать!!! Отсюда и все проблемы. QObject'ы надо сериализовывать и десериализовывать через QMetaProperty и никак иначе!
За конструктор копии в QObject'е надо сразу яйца отрывать!!! Отсюда и все проблемы. QObject'ы надо сериализовывать и десериализовывать через QMetaProperty и никак иначе!
Только Qt в отличии от VCL не RIP.
VCL скажем так не в мэйнстриме. Тем не менее сильно сомневаюсь что на VCL меньше живых проектов чем на Qt.
Это уже всё legacy, на Qt же куча новых проектов стартует ибо реально замены пока нету. Java — это немного не то, да и не умеет она под нативный look&feel подстраиваться.
Я выше писал что Qt действительно замены нет, из-за настоящей кроссплатформенности
А как скоро выйдет Turbo WinC++?
Microsoft, просто купите visual assist добавьте фичи IDE которые есть для managed языков или в visual assist.
Sign up to leave a comment.
Слухи про WinC++