Как научиться писать ПО под Win?

[кустомер]

Не напоминает. Но мне простительно, потому что я не работал с этим языком.
И поэтому объясните мне подоходчивее: почему, Вы полагаете, этот язык подходящ именно в работе электронщика?

[terminator_seva]

Не напоминает. Но мне простительно, потому что я не работал с этим языком.
И поэтому объясните мне подоходчивее: почему, Вы полагаете, этот язык подходящ именно в работе электронщика?

Я с этим языком тоже не работал, но я его и не рекомендовал.
Я просто акцентировал внимание что на С он совсем не похож.

[кустомер]

Поправка принимается. Выяснения "кто правее" мне неинтересны.
А вот про плюсы того или иного языка для наших электронных задач - я с интересом бы послушал что-нибудь новенькое.

[evg220]

про плюсы того или иного языка...

Хороший вопрос. Просто не ответишь...
Во-первых, на любом современном языке можно решать любые задачи. Это значит, что (как на автомобиле) - та дорога короче, которую ты знаешь!
Во-вторых, профессиональные программисты (не путать с кодировщиками на чем-то) не заморачиваются этим вопросом. Они используют разные средства (языки) наиболее удобные для реализации той, или иной части большой задачи.
Как я уже говорил выше, для "тяжелых" (сложных) вычислений используют Фортран, для интерфейса под ГУИ - С++ с соответствующей библиотекой.
Если нужно посчитать быстро простое уравнение, то для этого годится и Бейсик...
Таким образом, все сводится к требованиям решаемой задачи...

[vit66work]

Дык библиотеки из любой среды вызываются.

Так ведь надо описать в этой среде кучу структур, описать последовательность передачи параметров для кучи функций,
а чтобы это сделать, по всякому сначала надо разобраться в заголовчных сишных файлах, т.е. в С всё равно надо ковыряться.
Я как-то захотел вызвать из VBasic-а GetOpenFileName, прикинул, подумал, и решил , что и так хорошо.

[кустомер]

Ну вот у меня - какие основные задачи? - управление наваянным устройством от компа.
Тяжелых вычислений тут как правило нет. Зато первостепенная роль - переносимость и стабильность. Чтобы работала на любом компе (платформа WIN). Чтоб не позорила меня неожиданными глюками.

Во-вторых - работа с портами. (Нужна же связь, никуда не денешься).

Интерфейс - ну минимально приличный. Опыт показал, что навороченный интерфейс в практической работе - помеха.


А у вас, как электронщиков, - какие требования?

[evg220]

управление наваянным устройством от компа

Скорее всего через стандартные порты?
Вот в Qt это реализуется очень просто. Во-первых, там есть стандартный "абстрактный" класс, обеспечивающий типовую работу с внешними устройствами (включая файлы). В результате работа с устройствами и файлами практически одинакова.
Во-вторых существуют Qt-ные (бесплатные) проекты, обеспечивающие наиболее удобные способы работы с портами, созданные на основе указанного класса.

Чтобы работала на любом компе (платформа WIN)

и любая другая платформа.
Различия при работе с Юниксами могут возникать только при желании (что бывает только в специфических задачах) работать непосредственно с Х-библиотекой "пингвинов".

[кустомер]

Сейчас связываю преимущественно через МК и использую COM (меньше всего заморочек).

На предприятии, где я, кроме WIN не стоит никакая другая платформа, и менять ее в планах руководства нет железно. Так что многоплатформенность мне - как козе баян

Вот в Qt это реализуется очень просто. Во-первых, там есть стандартный "абстрактный" класс

Во-во!- Сломаешь все мозги с этими "классами", будь они неладны; только "абстрактного" мне вдобавок еще и не хватало

Так ведь надо описать в этой среде кучу структур, описать последовательность передачи параметров для кучи функций,
а чтобы это сделать, по всякому сначала надо разобраться в заголовчных сишных файлах, т.е. в С всё равно надо ковыряться.
Я как-то захотел вызвать из VBasic-а GetOpenFileName, прикинул, подумал, и решил , что и так хорошо.

- Золотые слова! Подпишусь, как под своими.

[worldmasters]

Уважаемый кустомер, СОМ порт в нынешнее время стал настолько изученным что врядли найдется среда в которой небыло бы компоненты для доступа к нему.
для продуктов CodeGear существуют различной степени сложности бесплатные компоненты SerialPort. Настроек минимум. А Microsoft и подавно включает в свои среды разработки собственный компонент последовательного порта. работать с ним проще некуда. и события получения данных и пороги срабатывания. Совсем необязательно вникать в API. Немного хуже обстоят дела с USB, стандарт относительно новый, инфы с примерами не так уж и много, НО... есть класс HID для которого опять же существуют бесплатные компоненты. и опять же различной сложности. Тот компонент который использовал я не вызвал никаких проблем. По сети где то гуляет моя програмка USB_HID Sniffer которая слушает порт.
Так что выбор остается за Вами. Определится для каких целей вам нужен порт, скорость обмена, качество, масштабируемость. Если объемы данных и скорости маленькие то целесообразней взять COM. В другом случае можно покумекать с HID.

[worldmasters]

А вот про плюсы того или иного языка для наших электронных задач - я с интересом бы послушал что-нибудь новенькое.

Из своего опыта скажу что к плючам С++ можно отнести относительную свободу программирования. Типы данных можно рассматривать так как нужно программисту а не компилятору. Простой доступ к памяти по указателям. Однако огромным минусом всего этого становится нагрузка на программера по отслеживанию чтобы указатель не выскочил в определенный момент куда не нужно. От этого и отталкивались когда создавали C#. Здесь была попытка снять лишнюю нагрузку с программиста и объединить простоту делфи и функционал С++. В принципе указатели как были так и остались, НО... теперь их контролирует компилятор.
Мне кажется шарп намного проще и удобнее чем С++. Сроки разработки приложений сокращаются в десятки раз. Еще наверное к плюсам шарпа можно отнести огромное изобилие компонент, которые помогают решить многие проблемы более коротким путем.
Вот.