Windows, VS 2005, C/C++, DLLs
Сообщение удалил BotWi
И, кстати, эти мои заморочки вообще осмыслены, или лучше не париться?Не париться. Большая часть всякой ерунды в .NET написана на unsafe C#.
Тупой штоле?
Имеется в виду, что меняется в ответах на предыдущие три вопроса. Типа, у плюсов же дополнительно есть ещё vtable, RTTI и другие необходимые штуки, вот как они сочетаются с отрубанием стандартной библиотеки и вообще?
Имеется в виду, что меняется в ответах на предыдущие три вопроса. Типа, у плюсов же дополнительно есть ещё vtable, RTTI и другие необходимые штуки, вот как они сочетаются с отрубанием стандартной библиотеки и вообще?
Насчёт большей части не знаю, все винформы в 1.1 по крайней мере через пару вызовов утыкались в Native (в смысле, если рефлектором посмотреть).
Да и вообще, может я чего-то не понимаю, но unsafe C# — та ещё радость, ибо блокирует GC и вообще ведёт себя весьма нагло.
Да и вообще, может я чего-то не понимаю, но unsafe C# — та ещё радость, ибо блокирует GC и вообще ведёт себя весьма нагло.
часть инфы по своему первому вопросу можешь почерпнуть из Рихтера
Да и вообще, может я чего-то не понимаю, но unsafe C# — та ещё радость, ибо блокирует GC и вообще ведёт себя весьма нагло.Ты действительно думаешь, что маршалинг данных в Си-шную dll и обратно ведёт себя лучше?
Ты действительно думаешь, что маршалинг данных в Си-шную dll и обратно ведёт себя лучше?Я не исключаю такой возможности! =)
Насколько я помню, когда ты хочешь передать в сишную дллку массивчег, он выделяет в каком-то отдельном специально обученном месте кусочег памяти, туда всё копирует, а по возвращении, если ты его попросишь, копирует обратно.
Но вообще меня больше производительность интересует, а у него она какая-то непонятная. Ну поинтеры, ну и что?
Насколько я помню, когда ты хочешь передать в сишную дллку массивчег, он выделяет в каком-то отдельном специально обученном месте кусочег памяти, туда всё копирует, а по возвращении, если ты его попросишь, копирует обратно.И что, ты думаешь, что полное копирование туда и обратно будет быстрее конструкции языка? Ты приведи пример тех вещей, которые ты собираешься делать. Почти наверняка расходы на маршалинг перекроют все плюсы от использования Си. Мало того, на Си и Си++ ещё надо уметь писать: решения в лоб куда быстрее будут работать на C# или Java.
Ты приведи пример тех вещей, которые ты собираешься делать.Я собираюсь писать виртуальную мойшыну для ICFP2006, с целью потренироваться и наработать немножко кода, который может пригодиться.
Причём маршалить её состояние взад-вперёд я вовсе не собираюсь, равно как и возвращать управление после каждой инструкции.
Причём по условиям задачи требуется множество побитовых операций, равно как и быстрый доступ к массивам, можно будет потом сравнить с производительностью того, что написал , но так у меня есть сильное подозрение, что в этой задаче чистый С уверенно сделает шарп в несколько раз. Особенно если меня не заломает всё-таки написать свой менеджер памяти, специально заточенный под.
Совсем тогда не понимаю, зачем тебе С# и устройство dll'ей в винде. Задача хорошо решится на Си++, без всяких менеджеров памяти в том смысле, как ты написал в своём посте. Только писать будешь намного дольше - в лоб совсем нельзя.
Во-первых, она достаточно проста, чтобы решить её влоб, вот прям так сразу. 13 команд, что там мудрить? И С++ нафиг тут не нужен, вообще. У меня будет один класс, VMState, который я прекрасно опишу структуркой и буду делать так:
int Step(UniversalMachineState * this) { int i = this->blablabla; bla bla; bla; }
ООП в голове, а не в языке, причём если не нужно наследования с инкапсуляцией, то сей вполне хватает. Можно было бы и вообще забить на структурку, но мне как-то хочется периодически сохранять состояние, равно как и запускать несколько мойшин параллельно (одна что-нить считает, во вторую я тыкаю пальчегами). Это же не очень сложно, в конце концов.
Во-вторых, я, конечно же, хочу писать высокоуровневый код на шарпе. Типа, интерфейсег к ВМ, который иногда спрашивает у меня, что я хочу ему сказать, ему что-то говорит моё процедурко, а он ей отвечает ответ.
В-третьих, зародившаяся у меня было мысль про standalone server-like application, работающую через стандартные потоки, тут же была отвергнута как извращение. Ибо мне нужно как минимум два логических канала доступа до виртуальной машины — с входным/выходным потоком и с командами управления, а придумывать отдельный скриптовый язык и писать два его интерпретатора — это какое-то ящериковское овладёвывание. Зачем мне эмулировать RPC, если у меня и так есть быстрое и удобное RPC?
int Step(UniversalMachineState * this) { int i = this->blablabla; bla bla; bla; }
ООП в голове, а не в языке, причём если не нужно наследования с инкапсуляцией, то сей вполне хватает. Можно было бы и вообще забить на структурку, но мне как-то хочется периодически сохранять состояние, равно как и запускать несколько мойшин параллельно (одна что-нить считает, во вторую я тыкаю пальчегами). Это же не очень сложно, в конце концов.
Во-вторых, я, конечно же, хочу писать высокоуровневый код на шарпе. Типа, интерфейсег к ВМ, который иногда спрашивает у меня, что я хочу ему сказать, ему что-то говорит моё процедурко, а он ей отвечает ответ.
В-третьих, зародившаяся у меня было мысль про standalone server-like application, работающую через стандартные потоки, тут же была отвергнута как извращение. Ибо мне нужно как минимум два логических канала доступа до виртуальной машины — с входным/выходным потоком и с командами управления, а придумывать отдельный скриптовый язык и писать два его интерпретатора — это какое-то ящериковское овладёвывание. Зачем мне эмулировать RPC, если у меня и так есть быстрое и удобное RPC?
Во-вторых, я, конечно же, хочу писать высокоуровневый код на шарпе. Типа, интерфейсег к ВМ, который иногда спрашивает у меня, что я хочу ему сказать, ему что-то говорит моё процедурко, а он ей отвечает ответ.Если на шарпе будет только GUI, то на кой чёрт было задавать такие вопросы в первом посте?
Во-первых, она достаточно проста, чтобы решить её влоб, вот прям так сразу. 13 команд, что там мудрить?Я думаю, что там порулит не язык программирования, а алгоритм.
> Если на шарпе будет только GUI, то на кой чёрт было задавать такие вопросы в первом посте?
Ты тоже пьяный что ли? Не ГУИ, я ж вроде ясно написал, что на шарпе я буду писать процеДурки, которые будут общацо с ВМ. Посредством p/invoke.
> Я думаю, что там порулит не язык программирования, а алгоритм.
Быстрая и удобная виртуальная машина оченно способствует, я думаю.
Ты тоже пьяный что ли? Не ГУИ, я ж вроде ясно написал, что на шарпе я буду писать процеДурки, которые будут общацо с ВМ. Посредством p/invoke.
> Я думаю, что там порулит не язык программирования, а алгоритм.
Быстрая и удобная виртуальная машина оченно способствует, я думаю.
Ты тоже пьяный что ли? Не ГУИ, я ж вроде ясно написал, что на шарпе я буду писать процеДурки, которые будут общацо с ВМ. Посредством p/invoke.Нет. Я, в отличии от тебя, трезвый. Ты написал свой пост так, что на C# ты будешь только управлять VM. Типа GUI, или ещё каким-то образом. Если вся работа VM будет сосредоточена в коде на Си, то какая разница, сколько выполняется маршалинг? Если нет, то как я уже написал выше, затраты на маршалинг могут перекрыть все плюсы использования Си.
Быстрая и удобная виртуальная машина оченно способствует, я думаю.
Судя по названию соревновалки - вряд ли. Разве что им действительно грезится быстрый код и системное программирование.
Плюсов использование для виртуальной машины в скорости прироста не даст, имхо. Достойно работает она вполне сейчас. В чемпионате сделать машину быстро задача основная, а не быстрой сделать.
Если хочешь поучавствовать - давай лучше команду наберём, да потренируемся вместе. Надо узнать, кто в чём спец.
Если хочешь поучавствовать - давай лучше команду наберём, да потренируемся вместе. Надо узнать, кто в чём спец.
1) Как именно работают дллки в винде с точки зрения языка С. Интересует то, как там разделяется память — вроде как каждый процесс получает уникальную копию глобальных переменных, но уничтожается ли всё автоматически при детаче? Нужно ли как-то явно освобождать то, что я выделил ВиртуалАллоком, например, и если да, то где? Что-то оффлайновый МСДН очень скупо эти вопросы освещает.dll, c и virtual alloc - это независимые вещи, и в общем случае, они ничего друг о друге не знают, вернее, из всех этих трех вещей только С чуть-чуть знает, что есть еще такая штука dll.
с - использует менеджер памяти завязанный на статику (т.е. считает, что вся программа известна на момент линковки соответственно у каждой dll свой независимый менеджер памяти.
[разумное предположение] c-ный менеджер памяти должен умирать вместе со всей выделенной им памятью, в момент выгрузки dll.
virtual allloc выделяет память и привязывает к процессу, ни про какие C/Dll он, вообще, не знает.
Я собираюсь писать виртуальную мойшыну для ICFP2006, с целью потренироваться и наработать немножко кода, который может пригодиться.если нужна сверхскорость разработки - имхо, стоит забыть про unsafe C#, а тем более про C/C++, потому что любая ошибка/опечатка будет приводить к core dump, который в наспех написанной программе можно искать неделями.
я бы взял за основу C# (может даже какой-нибудь F# и если только уж совсем припрет скорость - то локальные участи переписывал бы на unsafe C#.
ps
если говорить именно о ICFP, то лучше потратить 1000-2000$ на нормальный комп, чем тратить драгоценное время на ловлю багов в unsafe коде.
Оставить комментарий
bleyman
А подскажите-ка, где можно почитать про такие вещи:1) Как именно работают дллки в винде с точки зрения языка С. Интересует то, как там разделяется память — вроде как каждый процесс получает уникальную копию глобальных переменных, но уничтожается ли всё автоматически при детаче? Нужно ли как-то явно освобождать то, что я выделил ВиртуалАллоком, например, и если да, то где? Что-то оффлайновый МСДН очень скупо эти вопросы освещает.
2) Как правильно писать сишные программы без использования стандартной библиотеки, что вообще тогда происходит, имеет ли это смысл (ну типа я хочу свой маллок реализовать, мне тогда нафиг не сдался стандартный и его автоматически выделенный heap как это увязывается с предыдущим пунктом етс.
3) Как работает дотнетовский p/invoke в предыдущих двух вопросах — где он выделяет место под временные буфера, нужно ли какие-то дополнительные действия предпринимать?
4) Что меняется при переходе от С к С++?
Это типа хочется научиться писать действительно легковесные дллочки с критическими по производительности кусками кода. Чтобы использовать "высокоуровневый ассемблер" именно как высокоуровневый ассемблер. И, кстати, эти мои заморочки вообще осмыслены, или лучше не париться?