Цитата

в данном примере тоже самое что хочеш ты не болит голова о номерах функ в обьекте и так далее тоже самое будет и с "самодельным" обьектом только вместо include 'ddraw.inc' будет к примеру include 'myobj.inc' В с/с++ тоже вроде как еще инклуды не отменили? а мануаль в лубом случае читать придется с описанием методов обьекта тут уж паралельно на с или асм писать

В С++ все создается автоматичиски - #import *.dll и все, а на ассембелре прийдется писать этот 'myobj.inc'. И описание методов на С++ читать не прийдется - разве что перед самым вызовом надо знать название метода, а какой он по порядку - все равно

Цитата

ошибаешся могу еще как есть стандартные сишные либы в составе виндоса crtdll.dll msvcrt (на крайний случай) из них могу преспокойно вызвать все что угодно хоть printf bstr как раз относится к стандартным функ

А говорю о _bstr_t, а не BSTR - стандартном типе.
Да, ты сомжеш вызвать эту функцию - преобразование из Анси в Юникод. Там такие есть. Но тебе надо будет ее сперва найти . А С++ программер не напрягается на это.

Цитата

мне не пришлось разбиратся в тонкостях СОМ, знал я это

СОМ ты знал не срождения (я думаю ), ты его изучал. А С++ программер вообще мог его не изучать, а почитать в это время книги скажем по алгоритмам.

Цитата

месадж с еррором написать, не проблема

А тебе никто не разрешал писать мессадж с еррором - тебе надо было вызвать исключение, что бы выше могли обработать. Вдруг твой код будет выполнятся на сервере. Вот кстати пример не универсальности твоей потенциальной либы - взаимодействие с пользователем на сервере.
В тех двух строчках кода, что я привел в самом начале, был предусмотрен вызов исключений при ошибках в создании, переходе на интерфейс и в вызове метода. А в твоем коде уже десятки строчек и никак не обрабатываются ошибки. А что буде дальше? Если требования ужесточатся. С++ программеру прийдется просто развернуть код и дописать свое, а ты будеш просто добавлять и добавлять код десятками строчек!

Цитата

и по времени написание ну не чуть не больше чем на томже С

Я так не думаю, 2 строчки против десятков других. Если писать не думая вообще (закрываю глаза на сложность Асма), будет дольше. И здесь еще не учтено время на отладку кода, что ты написал вместо хорошо отлаженных врапперов из С++!

Цитата

Что касается поиска персонала, я думаю примерно одинаковый вред проекту могут принести как гипотетический ассемблерный гений олега, так и недоученный c++ программер орлана который пользуется врапперами и библиотеками классов не имея понятия как они работают.

Мы здесь рассматриваем реальные проекты, когда неопытный С++ программер может подойти к коллеге и спроси у него, что не ясно. С++, Ява и Паскалевские программеры ему смогут помочь. А куда идти Асемблеровскому программеру? Маловероятно, что будет хороший знаток Асемблера в проекте.
PS. А не хочу сказать, что ассемблер плохой язык. На нем можно реализовать _абосолютно_ _все_ что можно сделать на С++ и подобных языках. Вопрос во сколько это обойдется. Сколько за это заплатит заказчик, сколько за это получит сам разработчик.
PPS.v_ez, может вы и найдете себе программиста. Мы вам создали неплохую рекламу: единственная горячая тема и на _порядок_ больше просмотров.
oleg1973 из Италии, я из Украины. Так что нас заинтерисовали только теоретические вопросы реализации проекта.

Цитата(oleg1973 @ 28.7.2004, 22:56)

при некотором знании асма писать на нем не сложнее чем на С

Тут я согласен. Но времени это займет больше, а выигрыш в скорости работы приложения вряд ли будет существенным (разве что при работе с устройствами). Ну а что касается написания СУБД, то тут вопросы излишни...

Orlan
все доводы тобой приведенные относятся к удобствам компилятора
елементарно реализуются с помошью простых макросов
кстати *.inc тоже автоматом

Orlan - согласен, тема на удивление оказалась действительно горяча! )))
Может и найдём здесь , посмотрим...вообще то это работа отдела кадров, но эти подлецы вообще суетиться не хотят )))

v_ez - респект. Свои кадры надо подбирать самому.

Цитата

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

Возможность записать код в одну строчку является большим преимуществом перед языком, который реализует тоже самое десятками строк кода. Прошли те времена, когда надо было писать на языках удобных для машин. Тепер можна писать на языках удобных для людей. И в этом помогают нам и современные удобные для разработки компиляторы.
С++ удобен сам по себе. А если еще добавить профессиональные библиотеки к нему, то вообще супер выходит

Цитата

елементарно реализуются с помошью простых макросов

И почему же до сих пор при помощи макросов и знаний в ассемблере не реализовано то, что я выразил в 2-х строчках элементарного кода, или не предложено равноценной замены? ....

Orlan

Цитата

Возможность записать код в одну строчку является большим преимуществом перед языком, который реализует тоже самое десятками строк кода.

invoke SuperLibCreateObject,libz <---создаем obj
comcall libz,oleg1973 <--- вызываем первый метод


2 строки, также как и у тебя
все остальное относится не к коду а к препроцессору

Цитата

все остальное относится не к коду а к препроцессору

Нет. Оно относится к языку С++ - конструкторы, инициализация объекта, вызов метода и прочее. Препроцесор - это только деректива #import, которая в твоих 2-х строчках, кстати и нереализована.

Цитата

invoke SuperLibCreateObject,libz <---создаем obj comcall libz,oleg1973 <--- вызываем первый метод

Опять же, ты сильно упростил задачу. Например, нет _вообще_ обработки ошибок.
Я предложил тебе сделать альтернативный код к моему, который не уступал ничем.
Из этого кода можна сделать выводы: в ассемблере
1. Очень сложно делать обработку ошибок. Как я понял исключительные ситуации не предусмотрены в языке и их надо реальизовывать вручную. Программа на ассемблере должна молится на то, что бы случайно не оказалось свободного места на диске, случайно не пропала сеть - ведь она даже не скажет в чем заключалась ошибка.
2. Язык и библиотеки либо плохо документированы, либо очень слабы и не позволяют программерам легко и непринужденно реализовать стандартные операции (в данном случае преобразование Анси в Юникод)

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

Цитата

1. Очень сложно делать обработку ошибок. Как я понял исключительные ситуации не предусмотрены в языке и их надо реальизовывать вручную. Программа на ассемблере должна молится на то, что бы случайно не оказалось свободного места на диске, случайно не пропала сеть - ведь она даже не скажет в чем заключалась ошибка.

бред, в данном случае язык совсем не причем, за обработку исключений ось отвечает, есть GetLastError для этого

Цитата

2. Язык и библиотеки либо плохо документированы, либо очень слабы и не позволяют программерам легко и непринужденно реализовать стандартные операции (в данном случае преобразование Анси в Юникод)

а это просто смех вызывает
иди на intel.com там целый сайт языку и докам посвящен
а насчет библиотек, так их спецально для асма и нету, так как никто не запрещает использовать все стандартные библиотеки оси

однако сортировку чисел похоже на асме реализовать затруднительно. не говоря о том чтобы реализовать более сложный алгоритм.
базар о скорости сортировки

Цитата

бред, в данном случае язык совсем не причем, за обработку исключений ось отвечает, есть GetLastError для этого

Нет, GetLastError возвращает код последней ошибки, а саму обработку исключений с использованием этой функции должен писать программер, если он не хочет конечто что бы его постоянно вылетала - тогда операционка точно обработает ошибку, если сама не подвиснет

Цитата

а насчет библиотек, так их спецально для асма и нету, так как никто не запрещает использовать все стандартные библиотеки оси

А другие языки активно используют и другие библиотеки (не только "библиотеки оси"), что существенно усиливает их.

AndyY
тыб не вякал
по скорости то я тебя уделал аж в 8 раз (80 мс против 10 мс)

Orlan

Цитата

если он не хочет конечто что бы его постоянно вылетала - тогда операционка точно обработает ошибку, если сама не подвиснет

с умом сделаные проги как правило не глючат, почитай про SEH

Цитата

А другие языки активно используют и другие библиотеки (не только "библиотеки оси"), что существенно усиливает их.

тыж сам себе противоречиш, а как же глючные либы от сторонних производителей?
в данном вопросе надо отделить мух от котлет
к примеру если opengl то да это либа и без нее никуда
а вот то что находится в math.h это какбы вовсе не либа с Math functions , и асму это не нада
ну уж если совсем от нечего делать то в crtdll все это есть

ну а теперь ты приведи пример либы которую с асмом нельзя будет использовать

oleg1973
1. твоя либа не работает.
2. твоя прога неправильно мерит время (см. статью про измерение времени на моем сайте).
так что сравнивать нечего.

во флейме наглядный пример работы ассемблер-спеца

AndyY
вернись во флейм родной
и посматри последний скриншот

и кстати GetTickCount возвращает ОБЩЕЕ кол-во тиков сделаных процом а не отдельным процессом
так что считать время данным методом неразумно

Это сообщение отредактировал(а) oleg1973 - 6.8.2004, 16:02

Цитата

с умом сделаные проги как правило не глючат

Ты прав
Но вопрос не в этом.
Спор от том сколько усилий надо приложить для написания таких прог
О сортировке. oleg1973 может взять алгоритм AndyY и дизасемблировать а потом прооптимизировать. И только поэтому oleg1973 заведомо в выиграше по скорость. Ну и что? Вы хотите потратить 1000 дол на зарплату программерам ради того что бы программа за все время эксплуатации работала на 1 минуту меньше? Ассемблер позовляет писать быстро выполняющиеся программы. И спрашивается: а это надо? Основной тормоз в программах это не процессор, а пользователь. Быстрота асемблера с легкостью компенсируется покупкой лучшего компа.
А вот теперь возмем MS Word - сложный продукт, миллионы строк кода, сложная иерархия классов. И в этом случае кто будет в выиграше? Сортировка - простая операция, которую можна написать на любом структурном языке. Но миллионы строк кода уже не напишеш на нем.

Цитата

почитай про SEH

SEH неудобна для С++ из за ее неуживчивости с деструкторами классов. А под Linux ты тоже будеш использовать SEH?
Но это мы отклонились. Я говорил о генерации ошибок, а не их обработке. На верху можна сделать один блок обработки который будет ловить все генерируемые ошибки. Вопрос касался на счет генерации этих ошибок. В тех 2-х строчках заложено как минимум 3 генерации исключений. Если ты будеш писать на ассемблере, то тебе прийдется написать 3 сточки кода на вызов функций + 3 на их обработку. И это только в _идеальном_ случае, которых в реальных проектах не бывает. Т.е. выходит что тебе прийдется написатьв 6 раз больше кода. Как минимум. Согласно статистике (надеюсь не повторюся) в каждой сороковой строчке кода есть ошибка. И вот выходит. В твоем коде в 6 раз больше ошибок при одинаковых затратах.

Цитата

тыж сам себе противоречиш, а как же глючные либы от сторонних производителей?

Есть либы от Microsoft, Sun, Borland и др, которые хорошо протестированы и можна сказать безглючны.
Существуют либы 3-х видов (в моей классификации)
1. Системные библиотеки - *.dll и *.so файлы из операционки + другие продукты
2. Статически связываемые библиотеки (например MFC static linked)
3. Библиотеки, которые не требуют статического связывания (ATL, WTL, почти полностью STL)
Теперь такая ситуация с ними в Ассемблере:
1. Можна использовать. Основные сложность в синтаксисе вызова и генерации ошибок.
2. Альтернативы библиотек с высокоуровневых языков нету и поэтому используют вместо них библиотеки 1 как правило. Здесь основная сложность в том, что код просто возбухает на глазах и для добавления новой функции необходимы неимоверные усилия
3. Есть макросы, но это ничто по сравнения с шаблонными классами из STL. Макросы лишь упрощают трудоемкую работу

Цитата

ну а теперь ты приведи пример либы которую с асмом нельзя будет использовать

ATL, WTL, STL, а также MFC, VCL
Для них есть альтернативы - dll из операционки, но это слишком трудоемко, подобных к этим библиотек нету. Можно конечно использовать MFC длл-файлы, но зачем изворачиватся? Зачем лишний груз на голову программера?