изучать язык? (7 стр)

daemolisher
> как узнать когда началась одна наносекунда и закончилась предыдущая?

RDTSC

как на Java поработать с этим TSC?

daemolisher
> как на Java поработать с этим TSC?

Встроенными средствами никак, - через DLL - выполнить эту самую инструкцию RDTSC и вернуть результат в JAVA машину.

теоретически, если игра не пошаговая, то в ней нужно как-то привязываться ко времени?
1. читаем устройства ввода
2. считаем разность текущего значения времени и предыдущего
3. учитываем эту разность в игре
4. выводим результаты
5. возвращаемся с пункту 1.

как-то так наверно, да?

daemolisher
Отвечая на вопрос 0 поста.
Каждый язык/компилятор/интерпритатор преследует свои задачи, обладает той или иной гибкостью.

(пишу очевидное и всем извесное)
Чем хороши C++, object Pascal и им подобные - так это возможность слепить эфективный код и быстроедействующий код под конкреный процессор и конкретную ОС. Чем ещё хороши эти языки - возможностью писать менеджеры через классы, что значительно увеличивает КПД программиста.

Далее, переходя в крайности в минус С++ -> C -> ASM - возможность писать более топорный код, который может работать на процессорах типа 8051, код без илишеств (типа мега менеджеров), но более затрантый по времени написания.

Переходя к C# Java и им подобные - получаем возможность использовать много готовых решений, ценой того, что готовые решения должны стоять на ЭВМ. (Frame Work, Java машина). При этом у Java преимущество в крос платформенности. При этом можем попасть в засаду, связаную с отсутствием нужных библиотек, писав которые, мы получаемся на уровне C++.

теперь о выборе компилятора/среды.
Их пишут разные фирмы и каждая из них приследует свою цель. Например MicroSoft, выпускает компилятор, удобный для работы c MFC, а раньше MFC стоило больших денег. А без MFC сложный каркас приложения лепился долго. Поэтому среда не имеет возможности делать формы, кнопки визуально без MFC. Преимущество 2 - это Windows был также откомпилирован MSVC и в свои библиотеки они напихали кода, который может что-то в Windows использовать более эфективно.

Borland С - шёл как отличный комерческий проект, заточеный на быстрое штамповыание форм, компиляцию эфективного, быстродействующего кода и прочего прочего, чтобы быть нужным конечному пользователю. Например Borland С++ делает функции по умолчанию fast call, а MSVC std call.

Теперь о DirectX - т.к. его выпускает MicroSoft - лучше испотльзовать MSVS, т.к. новый DirectX SDK идёт именно для этого компилятора. Именно под этот компилятор проводились тесты и исправлялись ошибки.

что касается OpenGL - не знаю.

KKH
> C++, object Pascal и им подобные
> под конкреный процессор и конкретную ОС.
ЩИТО? Большиство компиляторов кроссплатформенны. Для многих ЯП есть ОС-независимые framework'и.

> Переходя к C# Java и им подобные - получаем возможность использовать много
> готовых решений
Под Си и C++ их в разы больше. Тот же Boost, Qt например.

> При этом у Java преимущество в крос платформенности.
Си в разы кроссплатформеннее. Покажи JRE под микроконтроллёр.

> Например MicroSoft, выпускает компилятор, удобный для работы c MFC,
MFC даже сама MS не использует.

X512
Разумеется я написал своё мнение и твои замечания имеют место.

>ЩИТО? Большиство компиляторов кроссплатформенны. Для многих ЯП есть ОС-независимые framework'и.
у разных процессоров int имеет различную длинну например. Когда пишется программа как кросс платформенная об этом приходится помнить программисту, а не компилятору. И всё в этом роде. Да разумеется можно и несколько платформенный код сделать. Сам такие программы пишу. Но работают они под ограниченным набором ОС.

>Под Си и C++ их в разы больше. Тот же Boost, Qt например.
Согласен что много, но речь о C# Java которые работают только на машинах где стоят их библиотеки.

>Си в разы кроссплатформеннее. Покажи JRE под микроконтроллёр.
не в разы. Покажи мне программу на С/C++, которая не будет учитывать особенностей тех платформ, под которые будет компилироваться программа ? На JRE эту разницу как раз решает её Ява машина. Это как раз суть подходов Java и C. На Java мы просто пишем приветствие и оно работает везде. А в C мы чекаем, подо что компилиуемся, что там нам ОС возвращает, куда будем писать в окно или консоль, если окно невозможно создать ... и т.д. Как раз я и говорю про то что
>При этом у Java преимущество в крос платформенности. При этом можем попасть в засаду, связаную с отсутствием нужных библиотек
если нет JRE под нужный микроконтроллер - то мы в пролёте. А С программе пофиг на это.

>MFC даже сама MS не использует.
Я пишу про те давние времена когда были только Windows 95, 98 и NT. Когда не было этих ferameWork и С#. Когда рулили Java, Borland C, Delphi и MFC, а WinAPI только осваивали. Тогда-то вышел компилатор (среда) MSVS 6.0 который не имел возможности слепить форму под Win32, а только под платную MFC. Сейчас конечно не то время, я пишу про прослеживающуюся традицию MicroSoft что-то начать делать, плюнуть и делать что-то другое. Например этот MFC заменили C#. Уверен пройдёт время и придумают C% или D**. А сказать я хотел, что не стоит гнаться без нужды за фишками от MicroSoft, т.к. они старые "кидала". (Не раскрыл свою мысль). А как альтернативный компилятор (среда) хорошь от Borland. Есть и ещё, сходу вспомнить не могу.

P.S. если я где-то приврал x512 меня поправит ;)

X512
>> Переходя к C# Java и им подобные - получаем возможность использовать много готовых решений
> Под Си и C++ их в разы больше. Тот же Boost, Qt например.
В случае C# и Java мы имеем всё в одном флаконе и довольно высокого качества. В случае C++ нам надо шалтая-болтая собирать.

>> При этом у Java преимущество в крос платформенности.
> Си в разы кроссплатформеннее. Покажи JRE под микроконтроллёр.
Например, в телефонам JRE ME есть. Или что тебе надо? Всегда можно JRE написать под нужную платформу/процессор.

NightmareZ
> Например, в телефонам JRE ME есть.

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

oistalker
> Причем в кажом телефоне свой набор доступных классов,... весело наверное писать под весь ассортимент, что ходит по рукам народонаселения.
Ну да. А ещё в каждом телефоне своя функциональность. Весело наверное писать на Си под весь ассортимент, что ходит по рукам народонаселения.

KKH
> у разных процессоров int имеет различную длинну например.
basetyps.h и stdint.h тебе в помощь. Будет работать под все ОС. Ещё проблемы?

> Но работают они под ограниченным набором ОС.
Если будешь писать только со стандартыми библиотеками - будет работать абсолютно везде. Если будешь использовать Qt - почти везде.

> На JRE эту разницу как раз решает её Ява машина.
В С++ эту разницу решают FrameWork'и. Например написав программу на Qt она будет работать на большинстве ОС без правок.

NightmareZ
> В случае C# и Java мы имеем всё в одном флаконе и довольно высокого качества.
Но портировать машину и framework - очень сложное занятие. В том же Haiku портировали Qt, но не могут портировать Java и .NET машину и её framework, хотя для продвижения ОС это было бы полезно.

> Например, в телефонам JRE ME есть.
Там не микроконтроллёр, а нормальный процессор(ARM обычно). И JRE ME несовместим с JRE SE. В чём профит такой "кроссплатформенности"?

> Всегда можно JRE написать под нужную платформу/процессор.
Не всегда. Иногда важно быстродействие, надёжность и малые объёмы памяти.

> А ещё в каждом телефоне своя функциональность.
Это вообще бред. По хорошему в каждом телефоне должна стоять нормальная ОС(хотя бы GNU/Linux), а не УГ от разработчика. Эта быдлоОСь реально бесит...

X512
> Но портировать машину и framework - очень сложное занятие. В том же Haiku портировали Qt, но не могут портировать Java и .NET машину и её framework, хотя
> для продвижения ОС это было бы полезно.
Ну Microsoft могут, а в хайку не могут. Следовательно, Microsoft молодцы, а хайки - нет.

> Там не микроконтроллёр, а нормальный процессор(ARM обычно).
Ога, она не блондинка, она светловолосая. Суть одно и то же.

> И JRE ME несовместим с JRE SE. В чём профит такой "кроссплатформенности"?
Ну и Си несовместим. Нужно перекомпилировать и надеяться, что косяки не повылазят. В чём профит?

> Не всегда. Иногда важно быстродействие, надёжность и малые объёмы памяти.
А чаще нет. Вот и замечательно.

> Это вообще бред. По хорошему в каждом телефоне должна стоять нормальная ОС(хотя
> бы GNU/Linux), а не УГ от разработчика. Эта быдлоОСь реально бесит...
Вернись в реальность. Тут редко бывает "по-хорошему".

... думаю тема переросла в русло "при желании можно сделать всё"...

Как минимум Managed C++, но скорее всего C#

Ну там наверное ГУИ ВинФормс...
Сам та двиг всяко на Си++...