| ||
Тема: С++ vs Java
с одной стороны где ж взять столько памяти, с другой, вытеснив неисользуемые данные в своп, освободившееся место можно использовать под дисковый кеш, что улучшит производительность
у меня другая теория: хочешь быстрый комп - покупай быстрый винчестер. правда, в последнее время для ускорения винчестеры, как и процессоры, приходится распараллеливать
навредить ?Сообщение от traveller
а ссылка есть? надо сильно
явным вызовом mlock/mlockall можно блокировать регион памяти от свопирования, но тогда опять возникает проблема -
......
так что 4Г RAM - не роскошь, а средство быстрого передвижения к очередному дидлайну.
http://www.gnu.org/software/libc/manual/html_node/Locking-Pages.html
The future is already here - it is just unevenly distributed. (c) W. Gibson
к сожалению, 4г это не 640к и не для всех достаточно
наткнулся про сборщики мусора и джава:
http://bash.org.ru/quote.php?num=811
еще понравилось:
http://bash.org.ru/quote.php?num=5844
The future is already here - it is just unevenly distributed. (c) W. Gibson
"C++ Is my favorite garbage collected language because it generates so little garbage" (c) bs
ОС Linux написана на обычном С без С++ )))
И слава богу, иначе сборка ядра занимала бы сутки...
А уж про глючность не говорю...
The future is already here - it is just unevenly distributed. (c) W. Gibson
Unix написан на С в те времена когда С++ еще в помине не было. Видно Linux решили писать на нем же
Прямо уж суткиИ слава богу, иначе сборка ядра занимала бы сутки...
А уж про глючность не говорю...а глючность зависит от разработчика, а не от С++
Странно, как люди до С++ жили...
Провел эксперимент - перевел программеров с С++ на С.
Результат - количество глюков заметно уменьшилось.
Факт... Для некоторых наверное неожиданный...
В конце 90-х был обзор крупных проектов которые писались с использованием ООП и без него. Сроки разработки, количество ошибок и т.п. Результаты были вполне предсказуемы...
(c) Reducing Run-Time Overhead in C++ ProgramsAlso, remember that the fastest parts of a program are those that are done before the pro-gram even starts. In general, you should:
• Catch errors during translation time (compiling and linking) rather than at run time. You should make the most of type checking and access checking, which means you should avoid using casts and void *.
• Simplify run-time computations by doing what you can at compile time.
• If you must do computations at run-time, shift them from the most time-critical parts to the least time-critical parts of the program (which is often, but not always, program start-up).
• When all else fails, try using C++ as just C.
Embedded Systems Conference San Francisco 2002
The future is already here - it is just unevenly distributed. (c) W. Gibson
os linux написана раньше чем ее компилятор с++
так же как и до фортранаСтранно, как люди до С++ жили...
это не делает чести этим программерамПровел эксперимент - перевел программеров с С++ на С.
Результат - количество глюков заметно уменьшилось.
Факт... Для некоторых наверное неожиданный...
все крупные проекты, приходящие на ум в конце десятых, используют ооп в той или иной мереВ конце 90-х был обзор крупных проектов которые писались с использованием ООП и без него. Сроки разработки, количество ошибок и т.п. Результаты были вполне предсказуемы...
ну, это ведь не значит "используйте malloc вместо new или fabs вместо std :: abs" , скорее что-то типа "не передавайте структуры по значению и не используйте исключений в качестве альтернативного возврата"• When all else fails, try using C++ as just C.
А что такое ОС Linux?
Только ядро,
или к примеру, KBD окна?
Я бы не стал так огульно утверждениями разбрасываться.
OS Linux состоит из двух основных частей - ядра Торвальдса и кучи пакетов GNU
Сам Столлман утверждает, что правильное название - OS GNU/Linux.Ядро написано на С. С GNU частью сложнее, однако и там С доминирует.
Разумеется там есть и С++ код, только вот встречается он как ни странно редко и преимущественно в двух областях (исключение - mysql).
Первая область - это ГУИ разных вариантов и пользовательские прибамбасы. Я всегда сомневался в жизненности идеи сделать из линукса виндоуз, однако именно здесь С++ оправдан, так как со времен Смоллтока любой гуй несет каинову печать с яркой надписью по кругу - Ugly by Design.
Вторая область - это многочисленные оболочки над существующим кодом (обычно С), которые позволяют 00-программерам не напрягаться и мыслить в привычном русле. Собственной функциональности у таких пакетов - 0.
Возьмите любой репозиторий Линукса и проверьте сами.
Есть исключения и из этих двух правил, однако большинство из них несут характерные признаки непонимания авторами софта одной маленькой, но очень поганой разницы в понятиях. Есть софт, делающий жизнь удобнее. Есть софт, который расширяет возможности. И большинство ОО-проектов пишутся так, как будто вторая категория включена в первую. А это неправда.
The future is already here - it is just unevenly distributed. (c) W. Gibson
Несколько замечаний по предыдущим постам.
1. Торвальдс начал писать Линукс в октябре 91. Страуструп начал писать С++ в 83-м. Очевидно, Торвальдс хорошо понимал разницу между языками и сделал правильный выбор.
2. В защиту фортрана (и умершего в прошлом месяце его автора - небезизвестного Бэкуса) могу привести очень характерный пример.
Есть очень старая библиотека - называется BLAS. Библиотека линейной алгебры. Любой серьезный производитель процессоров дает свою версию библиотеки оптимизированную под себя. Есть она и у Intel и у AMD. Что характерно - пишется на фортране с ассемблером. Интерфейсы - фортрановские. Мне почему-то кажется, что человека, который раскроет глаза Intel что надо ее писать на С++ в объектном стиле выгонят не дослушав.
Интересно, что любой программист, который приходит с института и которому я даю задачу написать какую-то математику почему-то начинает строчить свою реализацию TMatrix.
Вопрос - где на самом деле повторное использование кода выше - в фортране или С++?
Учитывая количество программ в мире использующих векторные и матричные операции (любая обработка изображений например и т.п.).
3. В защиту malloc против new.
Работа с new вместо malloc хуже! Потому что new абстрактно атомарен и следовательно при невозможности создать объект генерирует эксепшн. Затратный до одурения. 5 лет назад большинство компилеров оборачивало ЛЮБОЙ вызов конструктора в трай-кетч, а программист про это и не знал. Что давало падение производительности до 40 раз! Сейчас ситуация получше, но смысл в использовании этих вещей, кроме синтаксического сахара? Делать из С Бейсик? Работая с malloc можно пользоваться статическим чекером splint, разработчики которого официально заявили, что не будут поддерживать С++ по причине сложности его модели памяти. Работая с malloc можно использовать тонны наработанного кода по отладке памяти. А с new/delete? Последний статический чекер С++ который я видел стоил всех бабок и имел переполненные баглисты за каждый месяц.
про std:abs и крупные проекты на ООП напишу, если не размажут по стенке за этот пост.
The future is already here - it is just unevenly distributed. (c) W. Gibson
Ща мы с pal размажемесли не размажут по стенке за этот пост.
Если бы new был настолько хуже чем malloc его бы не придумали
Последний раз редактировалось THRESHE; 01.04.2007 в 23:29.
пиши, я лично вот очень внимательно слушаюпро std:abs и крупные проекты на ООП напишу, если не размажут по стенке за этот пост.
как сказал мне когда-то очень давно, один очень продвинутый дядька,
при вызове new автоматически вызывается конструктор, а при вызове delete - деструктор (см. следующий пункт). Так что нововведение можно описать формулой: new = malloc + конструктор, delete = free + деструктор.
Последний раз редактировалось traveller; 02.04.2007 в 08:30.
есть еще возможность переопределенияпиши, я лично вот очень внимательно слушаю
как сказал мне когда-то очень давно, один очень продвинутый дядька,
при вызове new автоматически вызывается конструктор, а при вызове delete - деструктор (см. следующий пункт). Так что нововведение можно описать формулой: new = malloc + конструктор, delete = free + деструктор.
обычно делается для пулирования, но возможны и другие применения
управление жизненным циклом объекта - это не прерогатива ООП. Инициализацию и освобождение ресурсов писали еще на ассемблере задолго до Страуструпа. ООП дал этой технике новую синтаксическую нотацию и расширил семантику, гарантировав атомарность операции.
malloc, если нельзя получить память возвращает 0. Что возвратит инициализатор на С? А что захотим, то и вернет. Принято, что указатель, либо 0 в случае ошибки. А что в этом случае делает конструктор С++? А вот хз. У Страуструпа почему-то про это не написано. Разве что в приложении, которое почему-то на русском языке раньше издавалось отдельно, а сейчас похоже вообще не издается.
Вернуть значение конструктору нельзя. С++ Faq-lite рекомендует переводить объект в зомби путем установки внутреннего состояния в "полуоткрытый". Либо юзать внешний exception с контролем уже распределенных ресурсов. В результате имеем классный выбор - либо дикий геморрой либо гемморой с понижением производительности. И все только за тем, чтобы с помощью трюка обойти ограничения языка и вернуть одно значение ошибки (в виде индикатора состояния или кода exception). И вот оно нам надо? Может все-таки malloc с классическим инициализатором и полной свободой реализации попроще будет?
Кстати а если конструктор самого exception не сработал, что будет?
Будет время - обязательно поэкспериментирую... Люблю вивисекцией заниматься.
И еще люблю перечитывать http://local.joelonsoftware.com/mediawiki/index.php/Russian пункт 36...
The future is already here - it is just unevenly distributed. (c) W. Gibson
Ваши права
Ответить с цитированием
Социальные закладки