Версия для печати темы

Автор: feanor 30 Apr 2012, 03:54

Использует кто?

Эксперимент по зарождению холисрача в нулёвой теме

Автор: Sav 30 Apr 2012, 08:28

Я иногда использую.

Автор: Guevara-chan 30 Apr 2012, 11:35

...Но зачем ? Отказ от косвенной адресации даже в переходах сделал эту вирт. машину абсолютно не эргономичной. Просто посмотрите на досуге, как оно там реализует "On Error Resume Next" - банально необходимую в условиях критичности каждого исключения конструкцию.

Автор: SerAlexandr 30 Apr 2012, 11:52

А Вы таки зачем интересуетесь? Вы, случайно, не официальный представитель Майкрософт в России, ищущий пиратов?
З.Ы. юзаю.


Не "зачем", а "почему". Потому что MSVS2010

Автор: feanor 30 Apr 2012, 11:53

Чиста поржать, блин.
Благо у нас он идет с первого курса.

Автор: SerAlexandr 30 Apr 2012, 11:56

Мы только в конце второго его начали учить

Автор: tolich 30 Apr 2012, 11:58

На самом деле, это только углубляет вопрос "зачем".

Автор: SerAlexandr 30 Apr 2012, 12:03

Okay.jpg

Автор: UnSchtalch 30 Apr 2012, 12:31

Я пользовал. Удобная вещь, тормозящая малость, зато очень легко идет в освоении и написании кода, благо все реализовано за нас и давно, сиди и собирай конструктор.

Автор: Guevara-chan 30 Apr 2012, 13:02

Вот тогда сядь и собери аналог какого-нибудь: http://forum.df2.ru/index.php?showtopic=15070
...Потом расскажешь об успехах.

Автор: UnSchtalch 30 Apr 2012, 13:22

System.Reflection.Emit - милый такой неймспейс под это дело. Куча геморроя обеспечена, но тем не менее

Автор: Guevara-chan 30 Apr 2012, 14:23

Не пойдет: его встраивать (а JIT - наше все) крайне проблематично. Пили свою VM. Там ведь и для этого придумано ?

Автор: gamecreator 30 Apr 2012, 15:02

использую. хороший язык. но удобно писать на нем разве что всякие компиляторы и гуевые проги.
не вижу повода для срача. так что фейл
что это?
express edition же

Автор: Guevara-chan 30 Apr 2012, 15:09

http://msdn.microsoft.com/en-us/library/5hsw66as(v=vs.80).aspx (же)

Автор: packa 30 Apr 2012, 15:36

А мне брат сказал что нынче плюсы уступают шарпу и вообще .net начинает рулить.

Автор: Guevara-chan 30 Apr 2012, 16:00

Скажи еще, зависимостей никаких.

Автор: packa 30 Apr 2012, 16:10

Что?

Автор: gamecreator 30 Apr 2012, 16:22

не что, а платформа дотнет

блок try-catch чтоли? не знаю как он компилится в машинный код, но в MSIL такая конструкция уже есть, даже переводить не надо.

да, и в C# кажись нет resume next

Автор: packa 30 Apr 2012, 16:31

Ну тут уж не шарю, извините

Как мне сказали) я просто процитировал

Автор: UnSchtalch 30 Apr 2012, 17:24

Так Mono же существует. На уровне правда .Net 3.0 - 3.5, но есть же




А куда собрались использовать язык для которого VM нужна, чтобы при том писать на шарпе и не иметь возможности тупо сплавить все проблемы на плечи машинки, работающей с IL?

Автор: Guevara-chan 30 Apr 2012, 18:07

Хм, например для plug-in системы: там ценится как производительность, так и контролируемость кода. В том, собственно, и основная прелесть StasisForth'а, что благодаря расширяемой структуре соотв. VM он может легко быть представлен низкоуровневым языком скриптования... На C# реализуешь поддержку ?

Автор: feanor 30 Apr 2012, 20:16

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

Автор: gamecreator 30 Apr 2012, 20:40

http://www.rsdn.ru/article/devtools/perftest.xml

Автор: IvanSav 30 Apr 2012, 23:07

Там самые интересные моменты не учитывают - для шарпа\жавы еще нужна компиляция из байт-кода в нативный - в итоге запускаться будет на порядок дольше чем С или делфи да и сборщик мусора из-за которого прога может сколько приспичит оперативы кушать - в некоторых случаях это критично.
То что не надо вручную память выделять\освобождать эт хорошо, но на том же с++ если юзать умные указатели можно полностью забыть о ручном new\delete.

Кстати интересное наблюдение - на шарпе\жаве порог вхождения ниже на порядок и, как результат, средний уровень намного ниже чем в том же C++. Не знаю хорошо это или плохо, но меня устраивает.

Автор: UnSchtalch 02 May 2012, 09:58

Очевидно же, что телескопами гвозди. Да и выше есть аргумент на ту же тему. Оно реализуемо, но медленно. Хотя из забавного - Android вот портировали на шарпы. Статья на хабре. http://goo.gl/u1rQB




Учитывая, что это проблема только первого запуска - медленный запуск, пока создается все же откомпилированная из IL - кода под текущее окружение версия программы.

Автор: Guevara-chan 03 May 2012, 10:38

Именно так, но даже бы и ладно на ожидаемую для псевдокода (а именно его олицетворяет CIL) неторопливость к исполнению – убивает сама архитектура, не позволяющая никак оптимизировать подобные задачи без выхода за «безопасный» уровень. Собственно, даже в штатных библиотеках Framework’а, если вдруг прогнать их через ILDasm, логики почти не обнаруживается: просто многоуровневая обертка для API в 90% случаев. Так зачем оно вообще ?

Автор: UnSchtalch 03 May 2012, 16:56

Слово конструктор в моем первом посте и фразу IvanSav про низкий порог вхождения не замечаем?

Шарпы сделаны мелкомягкими в качестве конкурентного продукта к Java, что вполне себе очевидно. Вдобавок ко всему - увы, в плане потенциала интерфейсной ляпоты тот же WPF, как можно посудить - впереди планеты всей. Серьезно - где еще можно сделать эффекты пиксельного свечения кнопок, плавную анимацию движения контролов и еще туеву хучу таких милых вещей без серьезного курения мануалов и тонн кода(!) ?
Это рассматривается чисто в качестве примера.

И да, напоследок про неторопливость - а циферки для сравнения в первом, втором запуске проги и чего-нить аналогично найтивного можно. В качестве подтверждения?

Автор: Guevara-chan 03 May 2012, 22:16

Встречный вопрос: с каких это пор порог вхождения front-end'а стал оправданием за откровенный маразм back-end'а ? Или у CIL тоже куда-то вкрутили низкий порог с конструктором ?


С GUI-библиотекой REBOL'а, например. Еще и на всех OS одинаково смотреться будет.


Т.е. ты в своих словах ("Оно реализуемо, но медленно") уже усомнился ? Gut, пили реализацию ранее упомянутой StasisVM и под нее уже сравним результаты по стандартным benchmark'ам на выбор.


*Ушла искать хоть одну актуальную .NET-сборку для мобильных телефонов.*

Автор: gamecreator 03 May 2012, 22:37

кстати у CIL тоже низкий порог вхождения. я писал на нем - все просто и понятно. не то, что в асме.
а Java все равно уг. и этого не вырубишь топором (если, конечно, не знаешь где их штаб-квартира)

Автор: UnSchtalch 03 May 2012, 22:52

Ээээ, нет. Это я предлагаю доказать, что дотнет-приложения после JIT-компиляции будет уступать найтивным приложениям такое число раз. А не реализовывать что-то свое для конкуренции и ради спора. Поскольку холивар не нов, наверняка уже есть доказательства для той или иной стороны в виде диаграмм и документов.


Пример я как бы выше привел - ведроид.

Автор: etoprostoya 03 May 2012, 22:59

А что, есть какой-то не майкрософтовский компилятор, который работает с шарпом?

Автор: gamecreator 03 May 2012, 23:20

mono, но говорят, что он уг

Автор: IvanSav 03 May 2012, 23:25

Qt тоже неплох. И с кроссплатформенностью получше чем у шарпа.

Угу. Mono. Весчь вполне работающая - даже от майкрософта поддержка какая-то есть. Под линухой софта написаного под него хватает с головой, а вот запустить что-то написанное на винде для дотнета удается редко. Почему-то половина разрабов все равно пытаются вызвать что-нибудь из нативного кода или, хотя бы, прочитать что-нибудь из несуществующего под линухой реестра.

Кстати - ради интереса сравнил скорость поиска в нативном хекс-редакторе и редакторе на шарпе. Победа за нативным - 15 сек vs 25 сек. Серьезнам сравнением это не назовешь конечно, но хоть что-то.

Автор: tolich 03 May 2012, 23:31

А у шарпа она разве есть?

Автор: gamecreator 03 May 2012, 23:40

а на втором запуске приложения?

Автор: IvanSav 03 May 2012, 23:48

Точно так же. Насколько я знаю трансляция IL -> нативный идет при первом вызове функции при каждом запуске.

Нет. А зачем? Да и вопрос был где еще кроме шарпа есть юзабельный интерфейс.

Автор: gamecreator 04 May 2012, 00:10

вот и я думал, что при каждом. но люди говорят другое.

Автор: Guevara-chan 04 May 2012, 10:00

1) Конкретно это, если бы ты утруждался слежением за нитью дискуссии, утверждала далеко не я.
2) ...Ежели так интересно – посмотри мою реализацию интепретационного цикла:


...Еще есть желание обсуждать эту тему ?


Если понял - объясни мне, пожалуйста, как стековая машина может заваливаться на бок от наличая на этом самом стеке "лишних" данных в процессе (строго формализированного) вызова ?


...Еще одна OS, которую (никогда не на)пишут JavaC# ? Еще и под полулегитимный Mono ? Не забывая, что "Our goal as a company is to provide the best platform for building mobile apps, and so XobotOS will not be a focus for us going forward. But it was a fun experiment to run, and as it turns out" http://blog.xamarin.com/2012/05/01/android-in-c-sharp/ ?
*OKay.jpg*

Автор: gamecreator 04 May 2012, 10:19

т.е. ты утверждаешь, что .net приложение не будет уступать нативному? я думал, что это позиция UnSchtalch'a

Автор: tolich 04 May 2012, 10:22

Не будет уступать такое число раз.

Автор: Guevara-chan 04 May 2012, 10:23

Смотря какое. Смотря какому. http://www.gotdotnet.ru/forums/2/60938/, и я говорю не только о практике использования ассемблерных вставок, вообще не переносимы до такой степени, чтобы всерьез сравнивать... Но скорее всего будет, хотя слова "разы" я точно не писала.

Автор: Gingerk 04 May 2012, 13:54

Тред замечу, от 2006 года
сейчас 2012

У тебя распостранённая ошибка ненавистников management code.
Берем задачу с решением оптимизированным на unmanaged, переносим его в management
Получаем бред и тормоза - радостно носимся с мантрой management code is shit

Автор: Guevara-chan 04 May 2012, 14:39

Да там задачи-то, по сути, никакой нет. Тупо разногласия в рассмотрении байт. Даже специально сейчас протестировала гипотетический аналог на PB:

...Вот чуть избыточно получилось, т.к. я описала как генератор, так и получатель. Помимо того задачи нет, есть единственная проблема с shared-границей.

P.S. Еще оно "managed" а не "management". Но это так, к слову.

Автор: gamecreator 04 May 2012, 15:48

не нашел собственно того самого перевода из байт в слова. или тестировался только порядок байт?
источник

Автор: Guevara-chan 04 May 2012, 15:55

А его там и быть не должно. Я просто разметила 2 разнотипных массива (Byte/Word) на одном участке памяти. Это же все равно абстракция.
...Ведь нету на самом деле никаких таблиц, связанных списков и чисел с плавающей точкой: только наборы байт и способы их обработки.


Fixed.

Автор: gamecreator 04 May 2012, 16:21

ой, не заметил. это ваше StructureUnion сбивает с толку.
так какой результат?

Автор: Guevara-chan 04 May 2012, 16:40

Более чем удовлетворительный, как по мне (извиняюсь за сбитые комментарии, копировала из сообщения):



...А вот CLR такого сделать не даст чисто физически. Управляемость, видите ли.

Автор: IvanSav 04 May 2012, 16:46

Это скорее идет от "Очень объекто-ориентированного программирования" чем от managed\unmanaged. Все запихивают за 3-4 уровнями интерфейсов да абстракных классов, а кто начнет выяснять как оно внутрях устроено - секрет, тайна, расстрел за нарушение ООПшной инкапсуляции.
Так и тут - а вы уверены что из двух Int8 получится Int16? А вы уверены что порядок байт в слове правильный? И толку потом от этой compile-time проверки типов если почти везде идет принудительное преобразование одного во второй, а все баги отлавливать приходится при запуске.

Жава тут соригинальничала еще круче - там Integer и int это абсолютно разные вещи, которые и вести себя могут каждый по своему.

Автор: Gingerk 05 May 2012, 00:32

P.S. Еще оно "managed" а не "management". Но это так, к слову.
[/quote]

Ай блин, верно да ))
описался.

Автор: Шалвенд 06 May 2012, 16:08

В данный момент - активно его учу. Ну как бы активно.

Автор: Undead 29 Apr 2018, 19:33

Бамп.
В 18-м как с шарпом обстоит? Я, как 1Сник несчастный, фактически знаю его синтаксис (в 1С он аналогичен), но не практиковался. То есть, я даже не знаю, а как и где на нём кодить.
Стоит вообще начинать, или лучше сразу плюсы?

Автор: t800 29 Apr 2018, 21:47

Если с точки зрения Работы в GameDev то

C# - это Unity
C++ - Unreal Engine

Unreal Engine для начинающих сложней соответственно мелких проектов на нем делают меньшие и работу на UE Вы найдете скорей всего только в Офисе, если хотите работать на удаленке ИМХО лучше скрипты да ассеты на C# для Unity клепать. Вот так вот.

Автор: feanor 03 May 2018, 08:55

забавно читать тред 2012 года

лол


Вообще-то их ниши вполне себе разошлись.

Автор: sergroj 06 May 2018, 20:14

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

Автор: Undead 17 May 2018, 01:13

Я хочу быть более-менее универсальным. Вообще моя цель близка к геймдеву, разработке своего софта и в далёкой перспективе - к своему движку. У меня не хватит времени на всё, что интересно, поэтому думаю выбирать из Java, C++ и C#.
Критерии - хорошая оптимизация, поддержка ассемблера, потенциально возможная мультиплатформенность. Но есть ещё один критерий - хватит ли у меня сил на освоение.

Автор: t800 17 May 2018, 09:38

C# - это реально только винда.
Java - это никакого ASM

Соответственно, если Вы действительно планируете писать свой движок, то изучайте С++

Автор: Undead 17 May 2018, 11:28

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

Автор: stoned_golem 18 May 2018, 00:10

C++ не советовал бы. Сложно, сомнительная ситуация на рынке.

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

C# поможет найти работу не в геймдеве, если не сложится. Ассемблер юзнуть не проблема - https://www.codeproject.com/Articles/1392/Using-Unmanaged-code-and-assembler-in-C

(Я вообще на пыхе пишу, это лишь личное мнение )

Автор: feanor 18 May 2018, 13:24

Если гейдев, то плюсы, так-то, но это "большой" гейдев, который реже белого слона. В тайге.
Реальность гейдева, кажца, это веселые фермы, клоноаркады и "три в ряд" на андроидоайфон.

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

С мультиплатформенностью сомнительное первое место берет джава, наверн (одинаково мерзко работает на всех платформах, зато без перекомпиляции), потом плюсы, потом шарп (у него получше, чем пять лет назад, но все равно не восторг. Хотя игрушки на OpenTK сожрет, вроде, и моно, и ксамарин)

Ассемблер? В 2018 году и, более того, на перспективу? Как аргумент? Серьезно?


чисто прагматически - проблема, по крайней мере, по сравнению с плюсами с их declspec(naked) и инлайновыми асмовыми вставками.
просто потому что накладные расходы на переход к неуправляемому коду/маршаллинг данных великоваты, приходится выносить код в внешние либы сразу крупными кусками, и значит, все равно надо учить хотя бы ту же сишечку (хотя сишечку учить надо все равно, сишечка делает человеком).

с другой стороны, использование ассемблера - это прям вообще пример пресловутой преждевременной оптимизации

Автор: stoned_golem 18 May 2018, 20:47

Верно. И кроссплатформенности лишаемся.

Автор: Snake_B 18 May 2018, 22:39

т.е. желание написать свой движок никого не смущает?

Автор: stoned_golem 18 May 2018, 22:59

Не вижу ничего зазорного наваять движок. Для обучения отличный ход, только сразу не надо это делать, юзнуть другие движки сначала.

Автор: Snake_B 19 May 2018, 00:28

и много их успешно написаных одиночками?

хотя, если там какие-нибудь нарды, я не знаю..

Автор: t800 19 May 2018, 13:10

Успешно написаных - Вагон и маленькая тележка.

Автор: stoned_golem 19 May 2018, 15:09

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

Автор: Undead 19 May 2018, 23:46

По всему выходит, лучше чистый си.

По движку мне нечего пока комментировать. Я не сказал, что буду делать его в одиночку + диздоков у меня хватает, да и курить существующие движки никто не запретит. Это цель на следующие 10 лет, а не на ближайшее время. Соответственно, и концепция заложена довольно глубокая. Учитывать будущее надо, да.
Я прогресснул в кодинге, так что понимаю возможные ограничения и проблемы, и именно поэтому ищу решения очень вдумчиво.
Спасибо за дельные мысли)

Автор: feanor 19 May 2018, 23:58

Еще одно удивительное заключение!

Автор: Snake_B 20 May 2018, 00:37

смотря что считать успешным.. то что они в принципе написаны.. или все таки у них был какой-то выхлоп..

Автор: feanor 20 May 2018, 01:53

Если без шуточек и контекста, то в разрезе general purpose/быдлоиндигеймдева и прочего кодитьдлясебя, набор рандомных плюсов/минусов:

pro C++:
- нейтив, как ни крути.
- огромное количество библиотек наработанного кода на любые нужды
- принципиальное отсутствие вендор-лока

contra C++:
- обратная сторона нейтива - гибкое балансирование между производительностью кода и производительностью программиста. Либо ты пишешь со всеми плюсами производительности, но впятеро медленнее, потому что ручное управление памятью, либо ты используешь умные указатели и кастомные менеджеры памяти, но тогда выигрыш в производительности куда-то волшебно пропадает.
- он язык без дизайна, и это уже навсегда. Родился как "С с классами", подожрал ООП (тоже реализованное, если верить уважаемым людям, без особого вкуса), потом попытался вобрать в себя модные фичи десятых, но так, что увидев в 2010 синтаксис лямбд я едва не начал заикаться и ссаться в штаны.
- boost. Просто boost. Это как плюсы внутри плюсов, если кажется, что от предыдущего пункта отчаяния недостаточно. И если не кажется - тоже, без их знания никуда.

pro Java:
- это хороший промышленный язык, на котором довольно сложно пробить себе ногу.
- под него есть куча диалектов с хорошей интеграцией. Scala, Groovy, вот этот вот Котлин, которые позволяют использовать иные стили и парадигмы по желанию, это не флейворное переключение между VB/C# или включения днищенского академического F#.
- Андроид, просто Андроид.

contra Java:
- слишком ориентирован на кровавый ынтерпрайз, фактически, кроме него, джава жива только андроидом. В нише страшненьких и прожорливых десктопных приложений (я в курсе, что десктоп нинужен) её вытеснил питон, геймдев на джаве - миф (ну как, серверные части-то как раз работа для джавы, но онлайн - это другое дело)
- она консервативна. Если бы в 2010 я бы посмотрел реализацию тех же лямбда-выражений в джаве, то я бы определенно не начал заикаться — потому что их добавили почти пять лет спустя.
- фабрики, которые конструируют фабрики, которые конструируют фабрики. Иногда стремление к чистоте дизайна заходит слишком далеко.

pro С#:
- он действительно универсален. Тут тебе и десктоп, тут тебе и серверы, и графоний, причем все нормально сделано. Рабочий язык Юнити, опять же.
- очень пологая кривая освоения, проще джавы и крестов
- по рабочим местам, особенно джуниорским, он ту же джаву уверенно обгоняет

contra C#
- он старательно следует дороге плюсов в плане зарастания фичами, причем зачастую - сомнительными либо не оч удачным синтаксическим сахаром. Каждая новая версия рутинно вызывает полыхание в обсуждениях и рост внутренних гайдлайнов, а версии выходят часто.
- завязка на Майкрософт, которая сильно влияет. После выкупа Моно Майкрософтом Моно/Xamarin ударными темпами подтягиваются до уровня шындошс разработки (они даже портировали Windows.Forms, боже мой), но проблемы с патентными формальностями и плохой имидж у МС продолжают вызывать некоторое недоверие.