Здравствуйте, adontz, Вы писали:
A>А если данные внутрь добавить? А то пока одни методы копировать то и нечего Вот и не вызываеться кострутор копии. А какое отношение наличие данных к тому что деструктор был вызван дважды?
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>А если данные внутрь добавить? А то пока одни методы копировать то и нечего Вот и не вызываеться кострутор копии.
К оптимизации. Это у других функций сторонний эффект может быть. У конструктора копии весьма ясная цель и для сласса без данных весь несуществующая. Вот его и выкинуло. Ты попробуй — а потом отвергай, оно конечно и не правильно, но логика в этом есть.
Здравствуйте, adontz, Вы писали:
A>К оптимизации. Это у других функций сторонний эффект может быть. У конструктора копии весьма ясная цель и для сласса без данных весь несуществующая. Вот его и выкинуло. Ты попробуй — а потом отвергай, оно конечно и не правильно, но логика в этом есть.
Нет ни какой логики это грубейшая ошибка ведущая к очень трудноуловимым оршибкам. ТОЧКА.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>К оптимизации. Это у других функций сторонний эффект может быть. У конструктора копии весьма ясная цель и для сласса без данных весь несуществующая. Вот его и выкинуло. Ты попробуй — а потом отвергай, оно конечно и не правильно, но логика в этом есть. WH>Нет ни какой логики это грубейшая ошибка ведущая к очень трудноуловимым оршибкам. ТОЧКА.
Здравствуйте, adontz, Вы писали:
A>А мне минус зачем, что, я компилятор писал?
А за компанию. Ибо нефиг пытаться оправдать ошибки. Это плохая практика. Ошибки надо исправлять. А если ты тут не причем то чего тогда встреваешь?
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vselezn, Вы писали:
V>У меня задача: запрограммировать под Windows коробочное GUI приложение с мощным интерфейсом, низкоуровневым взаимодействием со специальным электронным девайсом, и простенькой внутренней БД. V>Срок: ~ месяц.
V>Я знаю варианты реализации (может есть другие?): V>1. Visual Basic .Net и Windows Forms (обязательно ли код будет managed? Можно ли инсталировать .Net Framework как компонент инсталяции приложения? Достаточно ли богатая [созревшая] функциональность?) V>2. C# .Net и Windows Form (те же вопросы что и в (1)) V>3. Visual Basic 6.0. V>4. Visual C++ (.Net или 6.0) и Win API (user32, gdi32). V>5. Visual C++ и MFC. V>6. Visual C++ и ATL (Windows classes). V>7. Delphi.
V>Моя оценка вариантов: V>1. Могут быть проблемы с инсталляцией .Net Framework’а при инсталяции продукта и проблемы с managed-кодом (нужно чтобы приложение работало на всем семействе виндов); могут быть проблемы с низкоуровневым взаимодействием с девайсом. V>2. Тоже что и (1), только язык по-серьезней.
Чем язык то серьезней?
V>3. Тоже что и (1), только native-код и без .Net Framework’а.
не согласен в принципе.
V>4. Долго и много рутины.
никак не дольше, чем на С++ 6.0
V>5. Вроде все нормально только наслышан, что MFC – прошлое. V>6. Тоже что и (4), только чуть проще. V>7. Среднее между (3) и (5). Но все-таки на-C интересней.
на счет среднего в принципе не согласен. Абсолютно непохоже.
А что на С интересней — это дело вкуса.
V>Вроде все за MFC? Можете высказаться?
Здравствуйте, vselezn, Вы писали:
V>У меня задача: запрограммировать под Windows коробочное GUI приложение с мощным интерфейсом, низкоуровневым взаимодействием со специальным электронным девайсом, и простенькой внутренней БД. V>Срок: ~ месяц.
Я бы выбрал следующее:
1. GUI: VB6 или C++ Builder/Delphi. К сожалению сам работал только с билдером, средство очень мощное, но... глючное . В VB необходимо будет написать кода чуть больше чем в билдере, но работает постабильнее. Еще минус билдера BDE. С помощью этих средств ты напишешь свой приклад быстрее чем на MFC.
2. По поводу взаимодействия с девайсом: если девайс вешается на стаднартные порты (COM, LPT,...) тогда берешь VC++ 6 + ATL и делаешь COM-объект для работы с этим устройством, и дергаешь этот COM-объект из своего приклада.
А ежели девайс какой-то специфический, то возможно и драйвер необходимо будет писать.
А по поводу скорости, МFC естественно будет быстрее и интерфейс можно поинтересней сделать, но не за одим месяц.
Вот и не вызываеться кострутор копии.
А какое отношение наличие данных к тому что деструктор был вызван дважды? 
. В VB необходимо будет написать кода чуть больше чем в билдере, но работает постабильнее. Еще минус билдера BDE. С помощью этих средств ты напишешь свой приклад быстрее чем на MFC.