Re[40]: опять cpp в драйвере...
От: x64 Россия http://x64blog.name
Дата: 05.03.10 04:42
Оценка: -1
GN>Ваш ход, маэстро.

Мне не нужен C++ в драйверах. В юзерспейсе в системных вещах у меня тоже C везде. А для прикладных задач или там UI какого-нибудь десктопного у меня C# есть (да и то, только из-за FCL). Ну вот как-то не вписался C++ в мой быт. Вот это мой аргумент — не нужен C++, нет потребности. И я не один
Автор: TarasCo
Дата: 04.03.10
такой, похоже. И вряд ли ты сможешь предложить задачу, которая заставила бы меня взять в руки C++. Тем не менее, это всё не мешает мне писать то, за что платят деньги в итоге, ибо в итоге, как известно, платят за решение проблем, а не за язык. Ну и что после этого ещё обсуждать?
JID: x64j@jabber.ru
Re[41]: опять cpp в драйвере...
От: gear nuke  
Дата: 05.03.10 11:08
Оценка: +1 -1
Здравствуйте, x64, Вы писали:

x64>И вряд ли ты сможешь предложить задачу, которая заставила бы меня взять в руки C++.


Я её уже предложил Разумеется, если ограничиваться личными предпочтениями — её можно рашить и на С, вопрос в эффективности, гибкости решения и затраченном времени. Потому вместо решения последовали отмазки. не надо было даже кода, хватило бы "а на С это можно следать так-то". Но я знаю, что даже этого не будет, любое решение на С проиграет предложенному мы уже это проходили, достаточно сравнить Kernel: Загрузка DLL из памяти (x86)
Автор: x64
Дата: 06.12.08
(незаконченное решение) и это
Автор: gear nuke
Дата: 20.04.09


x64>Тем не менее, это всё не мешает мне писать то, за что платят деньги в итоге, ибо в итоге, как известно, платят за решение проблем, а не за язык. Ну и что после этого ещё обсуждать?


Можно бы обсудить что лучше: освоить средства заказчика в полной мере, или экономить их но это уж не совсем программирование.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[42]: опять cpp в драйвере...
От: x64 Россия http://x64blog.name
Дата: 05.03.10 21:27
Оценка:
GN>...вопрос в эффективности, гибкости решения и затраченном времени.
GN>любое решение на С проиграет предложенному...

Это всё ни чем не подкреплённые заявления. Приведи сравнительные тесты. Или приведи примеры, когда два аналогичных системных продукта (с драйверами, разумеется) писаны один на C, по-старинке, другой на C++. И приведи показатели вроде вот продукт на C, вот он падает каждые 15 минут, и писали его в 10 дольше, и денег, соответственно, потрачено в 20 раз больше, и т.д. и т.п. Разумеется, при условии что и тот и другой продукт писали ребята вполне квалифицированные, вот твоего уровня, например. Вот это был бы другой разговор, а пока у тебя только два кода (при чём решающих разные, по-большому счёту, задачи), один на C другой твой на С++, и твои слова, что код на C++ лучше. Чем он лучше, — не понятно. Ещё раз говорю, приводи примеры, иначе сейчас это всё смахивает на попытки пропихнуть NTL куда надо и куда не надо. Мне вообще сама идея NTL нравится, но только как исследовательский проект. Использовать это лично я вряд ли когда-нибудь буду, у меня у самого сишная Kernel-Mode Library, отлаженная, откомментированная, проверенная временем, зачем мне ещё что-то?
JID: x64j@jabber.ru
Re[41]: опять cpp в драйвере...
От: x64 Россия http://x64blog.name
Дата: 05.03.10 21:28
Оценка:
IID>>Ниасиливший детектед!
GN>ИМХО больше похоже на сильное влияние Дельфи.

Ребят, почините уже детекторы, ни хрена угадать не можете...
JID: x64j@jabber.ru
Re[43]: опять cpp в драйвере...
От: IID Россия  
Дата: 06.03.10 08:50
Оценка:
Здравствуйте, x64, Вы писали:

GN>>...вопрос в эффективности, гибкости решения и затраченном времени.

GN>>любое решение на С проиграет предложенному...

x64>Это всё ни чем не подкреплённые заявления. Приведи сравнительные тесты. Или приведи примеры, когда два аналогичных системных продукта (с драйверами, разумеется) писаны один на C, по-старинке, другой на C++. И приведи показатели вроде вот продукт на C, вот он падает каждые 15 минут, и писали его в 10 дольше, и денег, соответственно, потрачено в 20 раз больше, и т.д. и т.п.

Совершенно бессмысленное сравнение, потому что...

x64>Разумеется, при условии что и тот и другой продукт писали ребята вполне квалифицированные, вот твоего уровня, например.

...как только pure-C сольёт ты тут же начнёшь вопить о низкой квалификации сишников.

x64>Вот это был бы другой разговор, а пока у тебя только два кода (при чём решающих разные, по-большому счёту, задачи), один на C другой твой на С++, и твои слова, что код на C++ лучше.

Именно так, два небольших примера, из которых можно сделать определённые выводы. Уровень квалификации тоже можно усмотреть. В отличие от "системных продуктов", которые ещё и closed source будут, в случае "квалифицированных разработчиков".

x64>Чем он лучше, — не понятно.

А ещё говоришь что детекторы сломались. "Ниасилил" в канонической форме.

x64>Ещё раз говорю, приводи примеры,

С его стороны С++ пример был, ждём твой на pure-C

x64>иначе сейчас это всё смахивает на попытки пропихнуть NTL куда надо и куда не надо. Мне вообще сама идея NTL нравится, но только как исследовательский проект. Использовать это лично я вряд ли когда-нибудь буду, у меня у самого сишная Kernel-Mode Library, отлаженная, откомментированная, проверенная временем, зачем мне ещё что-то?

О, раз у тебя своя либа есть — тогда за чем же дело встало ? Раз pure-C такой весь замечательный да ещё с качественной библиотекой поддержки, то написать killer sample будет делом часа-двух. Вместо воплей на форуме и злобного минусования всех постов.
kalsarikännit
Re[43]: опять cpp в драйвере...
От: gear nuke  
Дата: 15.03.10 04:09
Оценка: 1 (1)
Здравствуйте, x64, Вы писали:

GN>>...вопрос в эффективности, гибкости решения и затраченном времени.

GN>>любое решение на С проиграет предложенному...

x64>Это всё ни чем не подкреплённые заявления.


Боюсь, ты их банально не понял, но не знаю с какого места нужно объяснять подробнее.

x64>Приведи сравнительные тесты.


За всё это время я так и не придумал, как можно реализовать функтор на С (статический полиморфизм на макросах не считаю за приемлимое решение). Так что С слил так и не выйдя на дорожку...

x64> Или приведи примеры, когда два аналогичных системных продукта (с драйверами, разумеется) писаны один на C, по-старинке, другой на C++. И приведи показатели вроде вот продукт на C, вот он падает каждые 15 минут, и писали его в 10 дольше, и денег, соответственно, потрачено в 20 раз больше, и т.д. и т.п.


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

Ну вот давай сравним твой файрвол и OSSS. Окей, тест на стабильность второй пока не прошёл. Исправление багов — вопрос времени. Но когда твой начнёт выполнять функцию блокировки нежелательного трафика?

x64>Ещё раз говорю, приводи примеры, иначе сейчас это всё смахивает на попытки пропихнуть NTL куда надо и куда не надо.


Она туда уже давно нагуглилась и без RSDN. А на самом деле и сейчас рановато. Парадокс? Верхи не могут, низы не хотят...
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[44]: опять cpp в драйвере...
От: x64 Россия http://x64blog.name
Дата: 15.03.10 04:34
Оценка: :))
GN>Ну вот давай сравним твой файрвол и OSSS. Окей, тест на стабильность второй пока не прошёл. Исправление багов — вопрос времени. Но когда твой начнёт выполнять функцию блокировки нежелательного трафика?

Некорректное сравнение, ибо разработка OSSS ведётся уже более двух лет, а jFirewall Personal Pro писан одним человеком за считанные месяцы и далеко не на fulltime при чём. Было б у меня два года чистого времени плюс некоторые финансы, то ваш OSSS, равно как и Касперские, Аутпосты и прочая, по фичам и стабильности сосали бы не нагибаясь. А так... ну этот проект и не задумывался изначально как коммерчески успешный, так что придумай что-нибудь получше.
JID: x64j@jabber.ru
Re[45]: опять cpp в драйвере...
От: gear nuke  
Дата: 15.03.10 06:26
Оценка: 1 (1) +1
Здравствуйте, x64, Вы писали:

x64>Некорректное сравнение


Дык, а к чему такое вообще было предложено в контексте С vs C++?

x64>ваш OSSS, равно как и Касперские, Аутпосты и прочая, по фичам и стабильности сосали бы не нагибаясь.


Пожалуй, все вендоры фаерволлов заявляют что-то подобное, разве что без намёков на высоту табурета, а rustock вот уже сколько лет их и обходит, кроме (не нашего) OSSS.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[45]: опять cpp в драйвере...
От: Testator Россия  
Дата: 16.03.10 21:16
Оценка:
Здравствуйте, x64, Вы писали:

x64>Было б у меня два года чистого времени плюс некоторые финансы, то ваш OSSS, равно как и Касперские, Аутпосты и прочая, по фичам и стабильности сосали бы не нагибаясь.


Уссацца Нука, какие имеются ввиду фичи, хотя бы примерно? Тема блокировки трафика со всякими правилами и методами детектирования вредоносных данных уже обсосана практически до предела. Осталось только прикрутить полноценную экспертную систему для последнего, но и это уже антивирусы практически реализуют со всякими эвристиками для "proactive". Целые подразделения сидят и постоянно занимаются пополнением онлайновых баз знаний. Все эти Security Suits уже как швейцарские ножи, монструозные серебряные крылатые ракеты стреляющие по воробьям. Что тут можно добавить, сделать баллистическую ракету с разделяющимися боеголовками? Зачем?
▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬
Мы — то, во что верим.
Re[45]: опять cpp в драйвере...
От: IID Россия  
Дата: 17.03.10 07:57
Оценка: 6 (1) -1
Здравствуйте, x64, Вы писали:

GN>>Ну вот давай сравним твой файрвол и OSSS. Окей, тест на стабильность второй пока не прошёл. Исправление багов — вопрос времени. Но когда твой начнёт выполнять функцию блокировки нежелательного трафика?


x64>Некорректное сравнение, ибо разработка OSSS ведётся уже более двух лет, а jFirewall Personal Pro писан одним человеком за считанные месяцы и далеко не на fulltime при чём. Было б у меня два года чистого времени плюс некоторые финансы, то ваш OSSS, равно как и Касперские, Аутпосты и прочая, по фичам и стабильности сосали бы не нагибаясь. А так... ну этот проект и не задумывался изначально как коммерчески успешный, так что придумай что-нибудь получше.


(наш) OSSS это не только фаерволл Точнее это далеко не фаерволл. Фаерволл в чистом виде дай бог чтобы 10% от размера _ЯДРА_ составлял. И при этом он на порядки мощнее и навороченее чем jFW. И да, ядро OSSS написано на С++, как уже заметил gear_nuke.
kalsarikännit
Re[46]: опять cpp в драйвере...
От: x64 Россия http://x64blog.name
Дата: 17.03.10 15:42
Оценка:
IID>это не только фаерволл

jFirewall Personal Pro это тоже не только фаервол, элементы проактивки присутствуют.

IID>И при этом он на порядки мощнее и навороченее чем jFW.


Я уже объяснил почему это некорректное сравнение, а ты продолжаешь гнуть свою линию. Успокойся уже, в вас нет ничего особенного. Имея в наличии ваш арсенал (время и финансы) у любого более-менее грамотного человека получится на выходе OSSS.
JID: x64j@jabber.ru
Re[47]: опять cpp в драйвере...
От: gear nuke  
Дата: 17.03.10 16:29
Оценка: +1
Здравствуйте, x64, Вы писали:

x64>Я уже объяснил почему это некорректное сравнение, а ты продолжаешь гнуть свою линию.


А я уже высказывал удивление, зачем ты пытаешься повернуть разговор в другое русло — от сравнения функций в 20 строк, где видно влияние языка, к сравнению больших продуктов, где играют роль многие факторы. Вот и получил, что хотел. И IID сразу спрогнозировал, куда это русло приведёт.

На данный момент выводы следующие: моё утверждение, что С не имеет средств для эффективного решения некоторых задач верно, поскольку пример на С++ есть
Автор: gear nuke
Дата: 05.03.10
, а на С нет. Аналогичного кода на С нет не потому, что мне или кому-то еще его лень делать, а так как это попросту невозможно. Я могу легко признать этот факт, поскольку именно он вынуждает меня пользовать С++, не смотря на большую сложность языка. А противники С++ признать его не хотят, потому что такое признание будет иметь форму: "я не могу написать", а кто её обнародует в здравом уме? Вот и происходит перевод темы...
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[47]: опять cpp в драйвере...
От: IID Россия  
Дата: 17.03.10 22:57
Оценка:
Здравствуйте, x64, Вы писали:

x64>Имея в наличии ваш арсенал ... у любого более-менее грамотного ...


Если бы был арсенал, если бы было время, если бы писалось фуллтайм, если бы изначально коммерческий... Если бы у бабушки что-то было, то это уже была бы не бабушка. Верно ?
kalsarikännit
Re[48]: опять cpp в драйвере...
От: eagersh  
Дата: 18.03.10 17:25
Оценка:
Здравствуйте, gear nuke, Вы писали:

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


x64>>Я уже объяснил почему это некорректное сравнение, а ты продолжаешь гнуть свою линию.


GN>А я уже высказывал удивление, зачем ты пытаешься повернуть разговор в другое русло — от сравнения функций в 20 строк, где видно влияние языка, к сравнению больших продуктов, где играют роль многие факторы. Вот и получил, что хотел. И IID сразу спрогнозировал, куда это русло приведёт.


GN>На данный момент выводы следующие: моё утверждение, что С не имеет средств для эффективного решения некоторых задач верно, поскольку пример на С++ есть
Автор: gear nuke
Дата: 05.03.10
, а на С нет. Аналогичного кода на С нет не потому, что мне или кому-то еще его лень делать, а так как это попросту невозможно. Я могу легко признать этот факт, поскольку именно он вынуждает меня пользовать С++, не смотря на большую сложность языка. А противники С++ признать его не хотят, потому что такое признание будет иметь форму: "я не могу написать", а кто её обнародует в здравом уме? Вот и происходит перевод темы...

И практически все продолжают использовать С в драйверах
Ты привел не типичный пример который редко может использоваться в драйверах.Я тебе советовал получить больше практического опыта в разработке драйверов.И для разных типов драйверов.Тогда ты будешь лучше понимать какие проблемы разработчик решает в кернеле.
Например я пишу сейчас miniport StorPort driver.Я честно говоря не вижу как использования С++ поможет мне написать этот драйвер быстрее и надежней.Проблемы которые я сейчас решаю совершенно далеки от проблем использования языка.
Re[49]: опять cpp в драйвере...
От: gear nuke  
Дата: 18.03.10 18:00
Оценка:
Здравствуйте, eagersh, Вы писали:

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


Кроме этих "обычных" проблем, я понимаю, что есть и другие проблемы — которые в рамках С не решаются. По крайней мере, ни у кого до сих пор не получилось, начинает получаться только на С++.

Я уже приводил в пример Lugh. Вот часть функционала:

We have tested our unpacking algorithm against the following, widely used, packers:

* acprotect
* andpakk2
* armadilo
* aspack
* asprotect
* execrypter
* expressor
* fsg
* morphine
* npack
* nspack
* packman
* pecompack
* pelock
* pespin
* rlpack
* svk protector
* telock
* themdia
* upx
* winunpack
* yoda protector

For all these packers Lugh has successfully identified and extracted the self modifying code nearly in real-time.

сколько есть аналогов на С? Ну я знаю про трейсеры, которые могут быть использованы для подобного, жаль только real-time не применимо.

E>Например я пишу сейчас miniport StorPort driver.Я честно говоря не вижу как использования С++ поможет мне написать этот драйвер быстрее и надежней.Проблемы которые я сейчас решаю совершенно далеки от проблем использования языка.


Стоит ли обобщать частный случай на всех остальных.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[49]: опять cpp в драйвере...
От: IID Россия  
Дата: 18.03.10 22:04
Оценка: +1
Здравствуйте, eagersh, Вы писали:

E>Я тебе советовал получить больше практического опыта в разработке драйверов.И для разных типов драйверов.Тогда ты будешь лучше понимать какие проблемы разработчик решает в кернеле.


Ты меня забавляешь Нет, ну серъёзно. Отставь в сторонку свой высокомерный тон. gear_nuke специалист, и специалист высокого класса. Чтобы это понять достаточно почитать его посты на РСДНе. А пока твои высказывания напоминают попытку научить курицу нести яйца.
kalsarikännit
Re[50]: опять cpp в драйвере...
От: eagersh  
Дата: 18.03.10 23:46
Оценка:
Здравствуйте, gear nuke, Вы писали:

GN>For all these packers Lugh has successfully identified and extracted the self modifying code nearly in real-time.

GN>[/q]сколько есть аналогов на С? Ну я знаю про трейсеры, которые могут быть использованы для подобного, жаль только real-time не применимо.

E>>Например я пишу сейчас miniport StorPort driver.Я честно говоря не вижу как использования С++ поможет мне написать этот драйвер быстрее и надежней.Проблемы которые я сейчас решаю совершенно далеки от проблем использования языка.


GN>Стоит ли обобщать частный случай на всех остальных.

Это ты обобщаешь частные проблемы сикьюрити стаф на все разработки в Windows kernel.Посмотри на примеры в WDK, которая является базовым тоолкитом для разработки драйверов, и укажи где лучше в этих примерах использовать С++. Также посмотри форумы на OSR, которые являются лучшим форумами по Windows device drivers, и оцени по количеству вопросов какие в основном драйвера разрабатываются сейчас.И имеет ли смысл использовать там С++.Меня этот вопрос интересует.Пока теоритически.К сожелению твой пример не убедителен для большинства приложений в Windows kernel.
Re[50]: опять cpp в драйвере...
От: eagersh  
Дата: 18.03.10 23:57
Оценка:
Здравствуйте, IID, Вы писали:

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


E>>Я тебе советовал получить больше практического опыта в разработке драйверов.И для разных типов драйверов.Тогда ты будешь лучше понимать какие проблемы разработчик решает в кернеле.


IID>Ты меня забавляешь Нет, ну серъёзно. Отставь в сторонку свой высокомерный тон. gear_nuke специалист, и специалист высокого класса. Чтобы это понять достаточно почитать его посты на РСДНе. А пока твои высказывания напоминают попытку научить курицу нести яйца.

Пока я не увидел на его примерах реального применения С++.Я имею ввиду то что нельзя сделать на С в kernel. Если бы у него был достаточный опыт разработки драйверов для железа, которые в основном и разрабатываются для Windows kernel, то он бы не приводил тот пример как преимущества С++ над С.
Re[51]: опять cpp в драйвере...
От: gear nuke  
Дата: 19.03.10 00:50
Оценка: 1 (1) +1
Здравствуйте, eagersh, Вы писали:

E>Это ты обобщаешь частные проблемы сикьюрити стаф на все разработки в Windows kernel.


Я пытаюсь показать знание логики Если мне нужно, а тебе не нужно — то в общем, нужно. Где ошибка в моих рассуждениях?

E>Посмотри на примеры в WDK, которая является базовым тоолкитом для разработки драйверов, и укажи где лучше в этих примерах использовать С++. Также посмотри форумы на OSR, которые являются лучшим форумами по Windows device drivers, и оцени по количеству вопросов какие в основном драйвера разрабатываются сейчас.


RAII много где уместно и позволяет чуть экономить время на написание, и иногда сильно — на отладку изменённого через год goto спагетти (ага, его никто не пишет, оно само получается). И еще экономит время на чтение кода новым человеком. Примеры в WDK слишком долго листать приходится

E>И имеет ли смысл использовать там С++.Меня этот вопрос интересует.Пока теоритически.


Может быть сначала можно посмотреть на мелочи? Стал бы использовать:

std::uint32_t вместо DWORD
std::wstring вместо RtlInitUnicodeString & Co?
std::list<> вместо ExInterlockedInsertHeadList & Co?
std::mutex?
std::atomic<> вместо ReadWriteBarrier и CAS?

Предположим, оно будет. Никаких преимуществ, лишь чуть меньше строк.
Просто потому, что это стандартизовано?

Понятно, что если человек уже 20 лет пишет на С, у него давно есть отлаженные библиотеки, то ему нет никакого практического смысла переучиваться. Пока не перейдёт в другой проект, где используется другой велосипед. А так — приходит студент знакомый с С++ и... он сразу может написать по крайней мере некоторые тесты. Это помогает решить проблему с людьми. Часть кода может ревьювить не-кернел специалист.

E>К сожелению твой пример не убедителен для большинства приложений в Windows kernel.


Это из-за его не-кернельности, точнее ему все равно в каком месте системы работать — ядре, или юзермоде.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[52]: опять cpp в драйвере...
От: Аноним  
Дата: 19.03.10 03:42
Оценка: +2
Здравствуйте, gear nuke, Вы писали:

GN>Понятно, что если человек уже 20 лет пишет на С, у него давно есть отлаженные библиотеки, то ему нет никакого практического смысла переучиваться. Пока не перейдёт в другой проект, где используется другой велосипед. А так — приходит студент знакомый с С++ и... он сразу может написать по крайней мере некоторые тесты. Это помогает решить проблему с людьми.


Вот этого они и боятся job security, понимаешь... Наколбасить кучу кода и самому его же поддерживать — а что, деньги-то платят, студенты — "не доросли еще"... ляпота. IMHO, в пустую gear nuke ты здесь распыляешся, в пустую... Тот кто плюшки увидел — тот уже давно использует, остальные с крутым видом ("реальное применение С++ — это то что нельзя сделать на С в kernel") едят кактусы.

PS: привет с rsdn.cpp
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.