>BTW, забавно, что Linux не позволяет отобразить диапазон шинных >адресов, отличных от RAM. Я был сильно удивлен когда впервые с >этим столкнулся. Это ты лишнего захотел ;) кстати разве всякая NUMA это дело разве не обходит ?

Дык и тот же MPlayer отлично играет через /dev/fb.

sS: В смысле NUMA? По-моему процессору вообще пофиг NUMA или нет, просто на NUMA более продвинутый контроллер памяти, который может далеко зарулить запрос на чтение/запись RAM.

Лано - поставлю ка я себе еще 0.5 Gb RAM а то чего то
ничего не ремапится ;)

2 sS

можно конечно говорить о старых классических стандартах
вообще говоря и так очевидно что общего у этих языков много,
но imho лучше избавиться от установки что один является как бы частью второго и значит типа "меньше и хуже" и сидят на нем одни аскеты которые сами себя счастья лишают ;)

Такую вот установку приходится наблюдать время от времени. "А вот новый сникерс теперь на 20% больше" и "C++ это тот же С, только с плюсами" :)) С маркетинговой точки зрения С++ выглядит однозначно выигрышнее и привлекательнее, вроде новой и улучшенной версии какого то старья. Cтарик Фрейд еще сто лет назад показывал что человеком на 99% правит Id, то бишь темная бездна подсознания, невидимая энергия которого и подпитывает многие якобы разумные и даже интеллектуальные споры, например о с/cpp :)

2NiKel

>можно конечно говорить о старых классических стандартах
>вообще говоря и так очевидно что общего у этих языков много,
>но imho лучше избавиться от установки что один является как бы >частью второго и значит типа "меньше и хуже" и сидят на нем одни >аскеты которые сами себя счастья лишают ;)

Ну реально сейчас если брать самые последние стандарты

C99 и С++98 то это уже фактически 2 разных языка

вот только как много кода сейчас следует C99 стандарту (кроме некоторых кусков кода ядра Linux) ?

(глядя на ветку lkml "C99 Initialisers" в 40 постингов)

блин - пошел прикручивать HIGHMEM

Ну вот ... C HIGHMEM гораздо приятнее ;)

sS

В общем народ потихоньку переползает. Некоторые даже призывают не стеснятся новых фич. В среде девелоперов позиции С довольно сильны, так что будут они на нем писать долго и рано или поздно перейдут на С99 и так далее. Тот же Линус выступает за большее внимание в gcc именно базовому С, грозился что перейдет на любой другой компилятор кторый будет лучше и будет его больше устраивать. Из такого положения вещей я бы и исходил, даже если сейчас и не все пишут на С99. Да ладно, пусть даже в чем то с и срр полностью совпадают - идеологически подходы разные. Действительно, то что делает одного хорошим программером для С++ реально мешает таковым быть для С, и наоборот.. Раньше вот считал что полезно сразу приучать к OOП на базе какого то академического паскаля или джавы, типа для развития кругозора и мышления, сейчас уже в этом сомневаюсь. Объектный подход если его освоить приучает к комфорту от которого потом не так просто отказаться :) Академические условия не требуют особой эффективности или контроля исполнения, подразумевается что у нас имеется идеальный компилятор, который, разумеется, делает совершенный обьектный код и нас вcя эта кухня никак не касается :)

> Еще раз, я не говорю, что ты можешь отобразить кадровый буфер
> "by hand" через mmap на что-либо, это может сделать драйвер.
Я почему бы и нет? mmap на /dev/mem ведь никто не отменял?

ANSI C vs С++

> Тут есть тонкость - про какой С/C++ мы говорим ...

Если ты достаточно внимательно прочел тот документ, ссылку на который какой-то добрый человек здесь опубликовал, то для тебя не составит труда построить пример программы, которая является правильной с точки зрения C89 и не является таковой с точки зрения ISO/IEC 14882:1998 (ANSI C++). Также тебе будет нетрудно написать программу, которая является правильной с точки зрения обоих стандартов, но имеет разную семантику. Или в выполнении этого упражнения тебе нужна помощь?

Только не надо говорить, что эти различия малы, несущественны, умещаются на какой-то там доле странички. Раз примеры таких программ существуют, это означает, что C не есть подмножество C++. Ч.Т.Д.

Це, ЦеПэпэ - какая на фиг разница? Работает - и ладно! Вон линух у меня работает замечательно. И беось не хуже. Да хоть на Scheme ядро пишите, лишь бы летало.

>Я почему бы и нет? mmap на /dev/mem ведь никто не отменял?

Ну /dev/mem как верно заметил sS - это только RAM. Как я понимаю, при попытке отобразить через /dev/mem не-ISA не-RAM возникнут проблемы.

Во всяком случае выше последней RAM страницы - стопудово.

>>Я почему бы и нет? mmap на /dev/mem ведь никто не отменял?
>Ну /dev/mem как верно заметил sS - это только RAM. Как я понимаю,
>при попытке отобразить через /dev/mem не-ISA не-RAM возникнут проблемы.
По крайней мере, поскольку речь тут шла про кадровый буффер,
насколько я знаю SVGALib получает к нему доступ именно таким
образом.
Раньше она использовала mmap на /proc/self/mem, но теперь это
отменили, а вот mmap на /dev/mem оставили и доступ к FB получить
через него можно запросто.

2 Sunch:

По поводу мэйнфреймов которые народ любит - дык он платонически любит, видел-то каждый десятый (это оптимистическая оценка). А лучше Бе была в "streaming media". Ну и (имхо) по сравнению с *nix/X - в наличии внятного GUI c "user interface guidelines" и отлично написанного (одной командой) и ПОЛНОГО документированного API (только не надо про posix орать пожалуйста - в posixe далеко не всё что нужно есть, да и был posix и на уровне shell и на уровне вызовов в BE, только berkeley sockets не было, что вызывало кучу гемора при портировании на Be программ с унихов) и , hence, отсутствии зоопарка тулкитов/библиотек.

--J/K--

А две платформы - гы :). Если "крутость" системы определяется количеством поддерживаемых платформ - то, давайте оставим NetBSD, а остальное всё в сад, как безнадёжно отставшее :). Ну можно ещё Open и Free оставить. Как близких родственников и потенциальных доноров. (Щас меня начнут гасить гитлерюгенд от лынукса) Только вот манагерам (не просто так кстати) насрать где что работает :).

--J/K--

про struct _ { int mem; char data[1]; }; Кто там хотел пример на с++? смотрите std::string, блин. там именно так и сделано. 2murr: "Всю жизнь считал, что ООП сближает предметную область и кодирование, по сути облегчает процесс кодирования, что и является самым большим достоинством. ;)" значит жизнь ты прожил короткую. ООП позволяет несколько симплифицировать представление задачи, упростить её настолько, чтобы она стала помещаться в голове проектировщиков и как следствие больший упор при разработке был на задачу, а не на детали реализации. Но сам процесс создания симплифицированной модели весьма не прост. С++ требует большего количества мозгов, чем Си. По себе знаю :) Долго думаю как правильно и концептуально сделать класс(подсистему классов), потом делаю наконец как попало(давно работать уже должно), потом таки вижу как же надо было. На Си пишу не задумываясь. По несколько тыщ (<10) строк без проблем.

>Если ты достаточно внимательно прочел тот документ, ссылку на >который какой-то добрый человек здесь опубликовал, то для тебя не >составит труда построить пример программы, которая является >правильной с точки зрения C89 и не является таковой с точки зрения >ISO/IEC 14882:1998 (ANSI C++). Также тебе будет нетрудно написать >программу, которая является правильной с точки зрения обоих >стандартов, но имеет разную семантику. Или в выполнении этого >упражнения тебе нужна помощь?

Вы таки сами _внимательно_ почитали ЧТО там написано

Там указанных различий именно на четверть странички


ЗЫ: Я свое отупражнялся 15 лет назад - сейчас к сожалению
не до упражнений - приходится переписывыать огромные куски
кода которые 10 лет жили и ничего а тут вдруг по желанию каких то там "стандартизаторов" вдруг стали deprecated - У них де файловый
дескриптор не определен в какой нибудь 3-е разрядной ОС
которую так сходу и не вспомнишь и тд. и тп.

ИДИОТЫ!!! С++, помимо большего удобства это ещё и БОЛЕЕ БЕЗОПАСНЫЙ ЯЗЫК по сравнению с С!!! Небольшие накладные RUNTIME расходы (лишний указатель в стеке при вызове методов класса) - это такая ХУЙНЯ!!! Зато более логичной, стройной и понятной получается программа. К тому же механизмы управления памятью(construction/destruction) лучше контролируют потенциальные ошибки, которые часто проявляются при кодировнии на С(утечки). А вообще-то спор не по существу - большинство спорящих здесь - красноглазые уёбки, толком в этих языках не разбирающихся. Это раз. А два - это религиозный спор (типа Asm vs C, Win vs Linux). Так что нихуя вы тут ничего не наспорите.

"ООП позволяет несколько симплифицировать представление задачи, упростить её настолько, чтобы она стала помещаться в голове проектировщиков и как следствие больший упор при разработке был на задачу, а не на детали реализации. Но сам процесс создания симплифицированной модели весьма не прост. С++ требует большего количества мозгов, чем Си. По себе знаю :) Долго думаю как правильно и концептуально сделать класс(подсистему классов), потом делаю наконец как попало(давно работать уже должно), потом таки вижу как же надо было. На Си пишу не задумываясь. По несколько тыщ (<10) строк без проблем."

Хорошо сформулировано ;) Присоединяюсь

Могу только добавить что при правильном проектировании
на ++ приходится писать раз в 5 меньше кода чем на С при том же
функционале и практически без сколь нибудь заметных потерь
производительности - а уж поиск ошибок ... С - шный программер
их дебагера бы не вылзил ;)

2SCREW
>ИДИОТЫ!!!
Начало ImHO неверное ;)

А вот дальше все правильно ;)

"помимо большего удобства это ещё и БОЛЕЕ БЕЗОПАСНЫЙ ЯЗЫК по сравнению с С!!! Небольшие накладные RUNTIME расходы (лишний указатель в стеке при вызове методов класса) - это такая [censored]
Зато более логичной, стройной и понятной получается программа. К тому же механизмы управления памятью(construction/destruction) лучше контролируют потенциальные ошибки, которые часто проявляются при кодировнии на С(утечки)."

А вот дальше Вы снова неправы (по крайней мере по форме)

Чем опохмелялись то ? ;)

А я не видел на с++ ни одной нормальной программы. Только
глюкодромы разные.

> А я не видел на с++ ни одной нормальной программы. Только глюкодромы разные.

Ну, а AutoCad написан, к примеру, на Visual C++. И глюкодромом его назвать как-то не получается ;-)

AutoCad написан, к примеру, на Visual C++

А я почему то думал, что на лиспе :)

> А я почему то думал, что на лиспе :)

Там есть конечно встроенный интерпретатор лиспа, но основа программы - на C++ :)

К сожалению, видел только их хедеры :(

2anonymous (*) (2003-08-14 09:55:24.675765):

шел бы ты чудак обратно в своё болото продолжать писать свой аутглюк на дотнете...