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

AVC>>[code]
AVC>> Си++ Java Oberon
AVC>>Модульность и раздельная компиляция Нет Да Да

Если вспомнить о dll, то раздельная компиляция в С++ есть

AVC>>Шаблоны Да Нет Нет

Начиная с 1.5 в Java средства обобщеного программирования присутствуют

AVC>>Наследование Мн. Од. Од.

В Java есть множественное наследование интерфейсов.

Здравствуйте, Дарней, Вы писали:

GN>>Каким образом получить доступ к регистрам CPU в C++ ?

Д>

Д>__asm mov ax, my_var

Вы всерьёз утверждаете, что это С++ ?

Здравствуйте, Трурль, Вы писали:

Т>Код на Рапире:
Т>

Т>A+B->C

Т>почти идеальный язык для обучения детей. Жаль, что заброшен.

Как всегда, всё уже украдено до нас.

А вокруг всё не утихали споры, что первично, яйцо или курица ...

Здравствуйте, gear nuke, Вы писали:

GN>Вы всерьёз утверждаете, что это С++ ?

Определенно не Оберон
Суть в том, что в С++ есть простая и удобная интеграция с асмом, которая позволяет делать такие вещи без усилий. В Яве например такой интеграции нет — что и неудивительно, учитывая требования, которые предъявлялись к языку.

Здравствуйте, Дарней,

GN>>Вы всерьёз утверждаете, что это С++ ?

Д>Определенно не Оберон

Уже больше похоже на правду — утверждения, что это С++ нет .

Д>Суть в том, что в С++ есть простая и удобная интеграция с асмом, которая позволяет делать такие вещи без усилий.

Ну так давайте будем называть вещи своими именами — доступ к регистрам обеспечивает ассемблер. Про простоту и удобство ИМХО немного преувеличено, только начнёшь его использовать более-менее серьёзно в том же MSVC/ICC, как компилятор бьёт по рукам вразумительным сообщением "internal compiler error".

Д>В Яве например такой интеграции нет — что и неудивительно, учитывая требования, которые предъявлялись к языку.

Я этот язык не знаю, слышал только, что он кроссплатформенный. А теперь вопрос: можно ли получить доступ к регистрам в кроссплатформенном коде на С++? .

Здравствуйте, gear nuke, Вы писали:

GN>Ну так давайте будем называть вещи своими именами — доступ к регистрам обеспечивает ассемблер.

обычно под любым языком понимается не только собственно язык, но и совокупность стандартных для него средств. Тот же самый reflection обеспечивается никак не самим C#, а CLI. Тем не менее, когда говорят, что в C# есть reflection, все прекрасно понимают, о чем идет речь.

GN>Про простоту и удобство ИМХО немного преувеличено, только начнёшь его использовать более-менее серьёзно в том же MSVC/ICC, как компилятор бьёт по рукам вразумительным сообщением "internal compiler error".

всё познается в сравнении

GN>А теперь вопрос: можно ли получить доступ к регистрам в кроссплатформенном коде на С++? .

Я думаю, если написать несколько #ifdef, то можно

Здравствуйте, Дарней, Вы писали:
Д>Суть в том, что в С++ есть простая и удобная интеграция с асмом, которая позволяет делать такие вещи без усилий.
Гм. У меня вопрос: что будет, если я попробую скомпилировать этот код для таргет платформы... ну, скажем, хотя бы Intel 80c31?
У меня (и не только) есть глубокое подозрение, что ты называешь "С++" не совсем тот язык.

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

S>Гм. У меня вопрос: что будет, если я попробую скомпилировать этот код для таргет платформы... ну, скажем, хотя бы Intel 80c31?

Если ты скомпилируешь любой свой код (pure C++, безо всякого asm interop) под эту платформу, нет абсолютно никакой гарантии, что он там заработает. И даже — что он там вообще скомпилируется. Если конечно предположить, что ты не закладывал совместимость именно с этой платформой в свой код.
Надо просто понимать, что никакой "полной" кроссплатформенности у C++ нет — есть только та, которую ты закладываешь в свой код сам.

S>У меня (и не только) есть глубокое подозрение, что ты называешь "С++" не совсем тот язык.

А ты уверен, что "C++" — это единый язык? Есть конечно стандарт, но много ли компиляторов, которые полностью ему удовлетворяют? И много ли кода, который не нарушает стандарт и не использует никаких платформо-зависимых вещей?

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

>> Что касается сборщика мусора в Си/Си++.
>> Конечно я имел в виду "прецизный" ("точный", "аккуратный" и т.п.;
>> tracing garbage collector) сборщик мусора, наподобие обероновского.

C>В той реализации Оберона, которую я смотрел, нет полностью точного
C>сборщика GC. Он там "mostly precise" — куча собирается точно, но стек
C>рассматривается консервативно. Boehm GC так тоже умеет.

Действительно, кандидаты из стека выбираются "консервативно" (по крайней мере, в Компонентном Паскале).
По-видимому, это реализационный компромисс.
Наверное, считается, что в стеке "корневых" указателей намного меньше, чем в загруженных модулях.
Не сомневаюсь, что Boehm умеет работать "консервативно" со стеком.
Но вряд ли Boehm умеет "прецизно" работать с сегментом данных.

C>В C++/CLI будет возможен.

Си++ — всегда большие надежды.

>> Просто сейчас мне пришла в голову мысль: а не "завышены" ли мои
>> требования? М.б. и правда консервативного сборщика мусора вполне
>> достаточно в большинстве случаев?

C>Обычно достаточно, тот же Mono до сих пор без проблем его использует.
C>Большой минус консервативных сборщиков в том, что для них закрыты многие
C>оптимизации, доступные в точных сборщиках.

Спасибо за информацию.
По крайней мере, у меня появилась новая идея.


P.S. Еще раз прошу прощения у тех, кому пока не успел ответить.

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

AVC>>>[code]
AVC>>> Си++ Java Oberon
AVC>>>Модульность и раздельная компиляция Нет Да Да

AVK>Если вспомнить о dll, то раздельная компиляция в С++ есть

Это скорее старая добрая независимая компиляция.
Разве есть в DLL контроль типов?

AVC>>>Шаблоны Да Нет Нет

AVK>Начиная с 1.5 в Java средства обобщеного программирования присутствуют

И вызывают большие нарекания.
В любом случае, это не шаблоны.

AVC>>>Наследование Мн. Од. Од.

AVK>В Java есть множественное наследование интерфейсов.

Эта идея в Java действительно новая и, похоже, неплохая.

Здравствуйте, gear nuke, Вы писали:

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

CC>>Надеюсь меня можно считать человеком?
CC>>Как по мне, так
CC>>Z = X + Y
CC>>Z := X + Y
CC>>куда естественнее чем
CC>>X + Y => Z

GN>Полностью согласен, и я тоже так считаю.
GN>Но провёл простой эксперимент — спросил ребёнка что он думает по этому поводу (знак "=>" был заменён на обычную стрелочку).

GN>ИМХО мы просто путаем понятное и привычное .

Тут есть еще один ньюанс. Дело не только в прозрачности записи. При анализе кода я, например, часто выполняю такую задачу: найти место, где переменной Z присваивалось значение. В силу многолетней привычки поиск я осуществляю слева направо. Соответствено с случае Оператора := мне прийдется смотреть строку только до этого оператора и я сразу определю, какой переменной присваивается значение. А вот в случае использования -> мне прийдется бегать глазами по невыровненой правой части выражений.

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

AVC>Здравствуйте, gear nuke, Вы писали:

AVC>Вместе с тем, если бы все различие между языками сводилось к особенностям синтаксиса Си и Паскаля, оно не заслуживало бы слишком долгого обсуждения.

Для меня синтаксис все же важен. Нет ничего хуже, чем допустив банальную опечатку потратить пол дня в отладке на ее поиск. Паскаль выигрывает у си в том отношении, что односимвольная опечатка (вставка/замена/пропуск символа) в паскале намного реже приводит к ошибке компиляции, чем в си.

Здравствуйте, Дарней, Вы писали:

GN>>Ну так давайте будем называть вещи своими именами — доступ к регистрам обеспечивает ассемблер.

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

Как может быть стандартным средством ассемблер, если процессоры все "нестандартные"? . Ну есть в языке ключевое слово asm, которое добрая половина компиляторов, включая распространённые для windows, не поддерживает. Остальное-то — implementation defined.

Д> Тот же самый reflection обеспечивается никак не самим C#, а CLI. Тем не менее, когда говорят, что в C# есть reflection, все прекрасно понимают, о чем идет речь.

Прошу прощения за глупый (от незнания) вопрос: а в других (каких?) языках транслируемых в cli эта штука есть? В Component Pascal думаю нет .

GN>>Про простоту и удобство ИМХО немного преувеличено, только начнёшь его использовать более-менее серьёзно в том же MSVC/ICC, как компилятор бьёт по рукам вразумительным сообщением "internal compiler error".

Д>всё познается в сравнении

Не совсем понятно, что с чем сравнивать . По сравнению со standalone ассемблерами, __asm в MSVC/ICC не выдерживает никакой критики — куча ограничений + множество багов. Вот на вскидку пара вещей, транслируемых неверно:

mov eax, $              ; mov eax, 0
mov eax, [ecx][0*edx]   ; mov eax, [ecx][ 1*edx]

GN>>А теперь вопрос: можно ли получить доступ к регистрам в кроссплатформенном коде на С++? .

Д>Я думаю, если написать несколько #ifdef, то можно

Даже не буду упирать на CPU без регистров (например, исполняющие java bytecode ), скажу только, что для ряда процессоров нет возможности использовать asm в существующих для них компиляторах. Ну а для тех, где есть, количество #ifdef будет несколько больше, чем несколько .

Резюме — если нужна кросплатформенность в С++, то забываем про asm. Нужна кросплатформенность в другом языке — тоже самое. Так что в качестве каких-то признаков генетического наследования регистры не уместны ИМХО.

Здравствуйте, gear nuke, Вы писали:

GN>Прошу прощения за глупый (от незнания) вопрос: а в других (каких?) языках транслируемых в cli эта штука есть? В Component Pascal думаю нет .

Я с ним тоже не знаком, но думаю, что есть. Никакой особой поддержки со стороны языка там не требуется.
Только не "транслируемые в CLI", а "работающие в среде CLI"

GN>Резюме — если нужна кросплатформенность в С++, то забываем про asm. Нужна кросплатформенность в другом языке — тоже самое. Так что в качестве каких-то признаков генетического наследования регистры не уместны ИМХО.

Ну ладно, как скажешь Пусть останется "прямой доступ к памяти и платформо-зависимым фичам"

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

GN>>ИМХО мы просто путаем понятное и привычное .

M>Тут есть еще один ньюанс. Дело не только в прозрачности записи. При анализе кода я, например, часто выполняю такую задачу: найти место, где переменной Z присваивалось значение. В силу многолетней привычки поиск я осуществляю слева направо. Соответствено с случае Оператора := мне прийдется смотреть строку только до этого оператора и я сразу определю, какой переменной присваивается значение. А вот в случае использования -> мне прийдется бегать глазами по невыровненой правой части выражений.

В общем-то ответ находися в моей цитате выше.

Здравствуйте, Дарней, Вы писали:

Д>Пусть останется "прямой доступ к памяти и платформо-зависимым фичам"

Какже останется? Мы же говорим о кроссплатформенном языке .

Здравствуйте, gear nuke, Вы писали:

GN>Какже останется? Мы же говорим о кроссплатформенном языке .

Язык — он такой, какой есть. Не очень то кроссплатформенный

Здравствуйте, Дарней, Вы писали:

Д>Язык — он такой, какой есть. Не очень то кроссплатформенный

А если захотели мы кросплатформенность получить? (java)

Здравствуйте, gear nuke, Вы писали:

GN>А если захотели мы кросплатформенность получить? (java)

вот-вот. если захотели — то получили Яву
в С++ слишком много неочевидных граблей

AVC wrote:

> C>В той реализации Оберона, которую я смотрел, нет полностью точного
> C>сборщика GC. Он там "mostly precise" — куча собирается точно, но стек
> C>рассматривается консервативно. Boehm GC так тоже умеет.
> Действительно, кандидаты из стека выбираются "консервативно" (по
> крайней мере, в Компонентном Паскале).
> По-видимому, это реализационный компромисс.

Да, так как точная сборка стека (и регистров процессора) — это такой
маленький хвостик, который тянет за собой слона. Например, придется
придумывать pinned pointers для интероперабельности с нативным кодом,
защизенные секции и т.п. Для этого нужны изменения в яыке (который Вирту
не хочется менять, я так понимаю).

Вообще, сейчас только в C++/CLI нормально продумана интеграция GC и
нативного кода.

> Наверное, считается, что в стеке "корневых" указателей намного меньше,
> чем в загруженных модулях.
> Не сомневаюсь, что Boehm умеет работать "консервативно" со стеком.
> Но вряд ли Boehm умеет "прецизно" работать с сегментом данных.

Умеет, умеет. Ему лишь надо указать формат объектов (то есть где в них
искать указатели) — этим успешно пользуются в Mono. С С++ это немного
неудобно, но тоже возможно.

--
С уважением,
Alex Besogonov (alexy@izh.com)