Здравствуйте, vselezn, Вы писали:

V>У меня задача: запрограммировать под Windows коробочное GUI приложение с мощным интерфейсом, низкоуровневым взаимодействием со специальным электронным девайсом, и простенькой внутренней БД.
V>Срок: ~ месяц.

Я бы выбрал следующее:
1. GUI: VB6 или C++ Builder/Delphi. К сожалению сам работал только с билдером, средство очень мощное, но... глючное . В VB необходимо будет написать кода чуть больше чем в билдере, но работает постабильнее. Еще минус билдера BDE. С помощью этих средств ты напишешь свой приклад быстрее чем на MFC.
2. По поводу взаимодействия с девайсом: если девайс вешается на стаднартные порты (COM, LPT,...) тогда берешь VC++ 6 + ATL и делаешь COM-объект для работы с этим устройством, и дергаешь этот COM-объект из своего приклада.
А ежели девайс какой-то специфический, то возможно и драйвер необходимо будет писать.

А по поводу скорости, МFC естественно будет быстрее и интерфейс можно поинтересней сделать, но не за одим месяц.

Удачи,
Валерий.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Aquary, Вы писали:

A>>под рукой Билдера нет... что не так?
WH>Вызовы:
WH> MessageBox(0, "ctor", "Test", 0);
WH> MessageBox(0, "dtor", "Test", 0);
WH> MessageBox(0, "dtor", "Test", 0);
WH>

А если данные внутрь добавить? А то пока одни методы копировать то и нечего Вот и не вызываеться кострутор копии.

Здравствуйте, adontz, Вы писали:

A>А мне минус зачем, что, я компилятор писал?
А за компанию. Ибо нефиг пытаться оправдать ошибки. Это плохая практика. Ошибки надо исправлять. А если ты тут не причем то чего тогда встреваешь?

Здравствуйте, 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? Можете высказаться?

ИМХО — .НЕТ

У меня задача: запрограммировать под Windows коробочное GUI приложение с мощным интерфейсом, низкоуровневым взаимодействием со специальным электронным девайсом, и простенькой внутренней БД.
Срок: ~ месяц.

Я знаю варианты реализации (может есть другие?):
1. Visual Basic .Net и Windows Forms (обязательно ли код будет managed? Можно ли инсталировать .Net Framework как компонент инсталяции приложения? Достаточно ли богатая [созревшая] функциональность?)
2. C# .Net и Windows Form (те же вопросы что и в (1))
3. Visual Basic 6.0.
4. Visual C++ (.Net или 6.0) и Win API (user32, gdi32).
5. Visual C++ и MFC.
6. Visual C++ и ATL (Windows classes).
7. Delphi.

Моя оценка вариантов:
1. Могут быть проблемы с инсталляцией .Net Framework’а при инсталяции продукта и проблемы с managed-кодом (нужно чтобы приложение работало на всем семействе виндов); могут быть проблемы с низкоуровневым взаимодействием с девайсом.
2. Тоже что и (1), только язык по-серьезней.
3. Тоже что и (1), только native-код и без .Net Framework’а.
4. Долго и много рутины.
5. Вроде все нормально только наслышан, что MFC – прошлое.
6. Тоже что и (4), только чуть проще.
7. Среднее между (3) и (5). Но все-таки на-C интересней.

Вроде все за MFC? Можете высказаться?

Здравствуйте, 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. Долго и много рутины.
V>5. Вроде все нормально только наслышан, что MFC – прошлое.
V>6. Тоже что и (4), только чуть проще.
V>7. Среднее между (3) и (5). Но все-таки на-C интересней.

V>Вроде все за MFC? Можете высказаться?

Я за 6 , но если туда добавить WTL

А вообще, MFC не использовал, т.к. в свое время тоже решил, что это прошлое
Если надо создавать приложения быстро, использую Делфи (опыт работы с паскалем у меня куда больше чем с C++)

Здравствуйте, vselezn, Вы писали:

...
V>7. Среднее между (3) и (5). Но все-таки на-C интересней.

С++ Builder — это VCL + С++.

Здравствуйте, vselezn, Вы писали:

V>У меня задача: запрограммировать под Windows коробочное GUI приложение с мощным интерфейсом, низкоуровневым взаимодействием со специальным электронным девайсом, и простенькой внутренней БД.

Нижний слой реализовать в виде библиотеки. Лучше всего в виде COM-объекта средствами C++/ATL.

Верхний слой писать на Delphi/VCL или на C#/WinForms.

Это с точки зрения скорости и качества разработки.

Здравствуйте, vselezn, Вы писали:

V>У меня задача: запрограммировать под Windows коробочное GUI приложение с мощным интерфейсом, низкоуровневым взаимодействием со специальным электронным девайсом, и простенькой внутренней БД.

C++ Builder
Интерфейс — ваяется также быстро, как и в Дельфи
Взаимодейтвие с дивайсами — тут использование C и C++ наиболее оправдано
Работа с БД — с ней работа просто на ура в кратчайшие сроки.

Коллега писал задачу примерно с теми же требованиями — в итоге Билдер оправдал все ожидания. У коллеги при этом, правда, был опыт разработки на Дельфи и хорошие знания железа.

Здравствуйте, Aquary, Вы писали:

A>C++ Builder
хъ
Ты только с ним осторожней... глючный он до ужаса.

Здравствуйте, vselezn, Вы писали:

V>6. Visual C++ и ATL (Windows classes).
WTL? Ы?

Здравствуйте, WolfHound, Вы писали:

WH>Ты только с ним осторожней... глючный он до ужаса.

Если не лезть куда не надо — всё ОК будет
Для GUI-компонент глюков не наблюдал... искал плохо, наверное
Низкоуровневые операции никто не мешает на MSVC написать...
А БД.. если ADO заюзать, то глюков не больше, чем в визуальных компонентах...

Здравствуйте, Aquary, Вы писали:
A>Если не лезть куда не надо — всё ОК будет
BCB6 Запускаем и фигеем

//---------------------------------------------------------------------------

#include <vcl.h>
#pragma hdrstop

#include "Unit1.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)
#pragma resource "*.dfm"
TForm1 *Form1;
class Test
{
public:
        Test()
        {
                MessageBox(0, "ctor", "Test", 0);
        }
        Test(const Test&)
        {
                MessageBox(0, "cctor", "Test", 0);
        }
        ~Test()
        {
                MessageBox(0, "dtor", "Test", 0);
        }
        operator int()
        {
                return 0;
        }
};
Test GetTest()
{
        return Test();
}
//---------------------------------------------------------------------------
__fastcall TForm1::TForm1(TComponent* Owner)
        : TForm(Owner)
{
//      int t=GetTest();
        while(int t=GetTest());
}
//---------------------------------------------------------------------------

Это я написал когда пытался выделить минимальный код с другим глюком... Вобщем С++ от него требовать опасно...

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Aquary, Вы писали:
A>>Если не лезть куда не надо — всё ОК будет
WH>BCB6 Запускаем и фигеем
...[погрызли мыши]...
WH>Это я написал когда пытался выделить минимальный код с другим глюком... Вобщем С++ от него требовать опасно...

под рукой Билдера нет... что не так?

Здравствуйте, vselezn, Вы писали:

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.

Работу с железом — 6, ввиде СОМ-объекта, все остальное 2.

Здравствуйте, vselezn, Вы писали:

skipped

V>Вроде все за MFC? Можете высказаться?

У меня коллега на работе был противником MFC. Делал все На Visual C++ 6.0 но без MFC.
Он уехал и мне достались "по наследству" его проекты.
При ближайшем рассмотрении оказалось, что он "руками" реализовал функциональность MFC классов для работы с битмапами, файлами, строками и т.д. Естественно, не без ошибок.
Делайте выводы
ИМХО, в MFC очень приличный набор работающих и полезных функций.
Не стОит забывать, что текущая версия MFC уже 7.0, к этому времени даже продукцией фирмы Microsoft уже можно безбоязненно пользоваться.
А по поводу интерфейса могу порекомендовать Xtreme Toolkit library от Codejock.
Это надстройка над MFC, позволяющая элементарно создавать вполне приличный интерфейс.

Здравствуйте, Aquary, Вы писали:

A>под рукой Билдера нет... что не так?
Вызовы:
MessageBox(0, "ctor", "Test", 0);
MessageBox(0, "dtor", "Test", 0);
MessageBox(0, "dtor", "Test", 0);

Здравствуйте, Akzhan, Вы писали:

A>Нижний слой реализовать в виде библиотеки. Лучше всего в виде COM-объекта средствами C++/ATL.

A>Верхний слой писать на Delphi/VCL или на C#/WinForms.

A>Это с точки зрения скорости и качества разработки.

А какие подводные камни существуют у данного подхода в частности и, в целом, у проектов, ядро которых программируется на языке сходном по возможностям и уровню с С++, а пользовательский интерфейс на языках типа Delphi? Сильно ли уменьшается скорость работы таких приложений, если уменьшается вообще по сравнению, например, с "чистым" C++ (ну еще к этому WTL|ATL|MFC для интерфейсу)?

Здравствуйте, cMex, Вы писали:

A>Нижний слой реализовать в виде библиотеки. Лучше всего в виде COM-
A>Верхний слой писать на Delphi/VCL или на C#/WinForms.
A>Это с точки зрения скорости и качества разработки.

M>А какие подводные камни существуют у данного подхода в частности и, в целом, у проектов, ядро которых программируется на языке сходном по возможностям и уровню с С++, а пользовательский интерфейс на языках типа Delphi? Сильно ли уменьшается скорость работы таких приложений, если уменьшается вообще по сравнению, например, с "чистым" C++ (ну еще к этому WTL|ATL|MFC для интерфейсу)?


Подводных камней я не видел. Нужен только человек, определяющий контракты между ядром приложения и и презентационным слоем. Последние несколько лет для взаимодействия между системами я просто использую обычный COM (oleauto-compatible interfaces).
Благо писать с использованием COM крайне удобно в любой среде программирования.

Здравствуйте, vselezn, Вы писали:

WTL — это конечно круто, но думаю в данной ситуации MFC наиболее оптимальный вариант: довольно удобно и вполне качествеено получается. Тем более если используешь версию от VS7 — они там половину всего переписали на ATL'е .

Здравствуйте, AndrewJD, Вы писали:

AJD>WTL — это конечно круто, но думаю в данной ситуации MFC наиболее оптимальный вариант: довольно удобно и вполне качествеено получается. Тем более если используешь версию от VS7 — они там половину всего переписали на ATL'е .

То-то мне так просто стало работать с MFC. Последний раз использовал два года назад, долго плевался
А сейчас надо было дипломник делать, так за два дня сбацал study app.
Ибо большая часть классов/макросов из ATL доступна немедленно.

Есть ещё огрехи, да и всё равно кажется туповатой, но всё же хоть работать удобнее стало.

Здравствуйте, 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. Долго и много рутины.
V>5. Вроде все нормально только наслышан, что MFC – прошлое.
V>6. Тоже что и (4), только чуть проще.
V>7. Среднее между (3) и (5). Но все-таки на-C интересней.

V>Вроде все за MFC? Можете высказаться?

Я бы писал на том что лучше знаю и проблемы чего могу решить. Если Ваш разработчик хорошо занет MFC — пишите на нем. Это всего лишь облегченный путь по быстрому создать оконный интерфейс, как собственно и другие пути. Хотя, могу предположить что раз у Вас есть взаимодействие с низким уровнем — работают у Вас спецы. Это я к тому, что все кроме MFC является средством для быстрой разработки, как сказал один мой знакомый — VB это язык программирования для домохозяек Не примите в обиду программеры на VB. Я бы писал на MFC, так как неплохо его знаю.

Здравствуйте, vselezn, Вы писали:

V>У меня задача: запрограммировать под Windows коробочное GUI приложение с мощным интерфейсом, низкоуровневым взаимодействием со специальным электронным девайсом, и простенькой внутренней БД.

Я бы писал на Delphi

Мощный интерфейс. Никаких проблем.
Низкоуровневое взаимодействие. Никаких проблем. Даже embeded приложения писал
Простенькая БД. Никаких проблем.
Срок: ~ месяц. Не зная задачи оценить трудно. Но мой знакомый на Delphi-проекты сравит время и стоимость в четыре раза ниже, чем на MFC + VC++. Самое интересное, что выбирают все равно VC++.

Здравствуйте, adontz, Вы писали:

A>А если данные внутрь добавить? А то пока одни методы копировать то и нечего Вот и не вызываеться кострутор копии.
А какое отношение наличие данных к тому что деструктор был вызван дважды?

Здравствуйте, WolfHound, Вы писали:

A>>А если данные внутрь добавить? А то пока одни методы копировать то и нечего Вот и не вызываеться кострутор копии.

К оптимизации. Это у других функций сторонний эффект может быть. У конструктора копии весьма ясная цель и для сласса без данных весь несуществующая. Вот его и выкинуло. Ты попробуй — а потом отвергай, оно конечно и не правильно, но логика в этом есть.

Здравствуйте, adontz, Вы писали:

A>К оптимизации. Это у других функций сторонний эффект может быть. У конструктора копии весьма ясная цель и для сласса без данных весь несуществующая. Вот его и выкинуло. Ты попробуй — а потом отвергай, оно конечно и не правильно, но логика в этом есть.
Нет ни какой логики это грубейшая ошибка ведущая к очень трудноуловимым оршибкам. ТОЧКА.

Здравствуйте, WolfHound, Вы писали:

A>>К оптимизации. Это у других функций сторонний эффект может быть. У конструктора копии весьма ясная цель и для сласса без данных весь несуществующая. Вот его и выкинуло. Ты попробуй — а потом отвергай, оно конечно и не правильно, но логика в этом есть.
WH>Нет ни какой логики это грубейшая ошибка ведущая к очень трудноуловимым оршибкам. ТОЧКА.

А мне минус зачем, что, я компилятор писал?