> man operating_systems
● Новости ● Статьи ● Форум ● Файлы ● КаталогОС ● Рассылки
Добро пожаловать,
Пользователь:

Пароль:


Запомнить

[ ]

Свежие материалы
bullet Производительность программных RAID-массивов из разных дисков в Linux
bullet Лицензия раздора
bullet Патч Reiser4 для Linux 2.6.22
bullet Подготовка к экзамену LPI Linux.
bullet Архитектура файловой системы UFS2

Обсуждения
bullet Микропроцессор "Эверест" (1)
bullet Запрет регистрации на osrc.info (1)
bullet Ответ Javе и Flash'у (70)
bullet Новая программа поддержки от Microsoft (2)
bullet Solaris будет портирован на Itanium и POWER? (3)
bullet 9 декабря вышла новая сборка Xameleon (9)
bullet рассылка (2)
bullet ЗРОС (3)
bullet Новый стиль OSRC.info (2)
bullet Обсуждение статьи "Взгляд на развитие YellowTAB" (124)

В Сети
Гостей: 4, Пользователей: 1 ...
Roman I Khimov смотрит rss.php

рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07

Пользователей: 1007
Новичок: alicemokas


C++ в ядре Linux?
У компании есть патч, позволяющий использовать C++ в ядре Linux. Патч позволяет использовать всю мощь исключений C++, глобальные конструкторы и деструкторы, динамическую проверку типов.

[ Читайте далее... ]
Roman I Khimov  в  Пятница, 29 Октябрь 2004, 14:27  |   Комментарии: 74  |  для печати

Комментарии
ossadchy |04.11.2007 22:22
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
Без соответствующей системы классов в ядре толку с этого очень немного.

ossadchy |04.11.2007 22:24
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
А в целом - присоединяюсь к мнению Линуса - не в духе Linux это все.

alman |05.11.2007 17:28
Комментарии: 58

Зарегистрирован: 28.10.2006 01:21
Ну вот, Торвальдс не осилил С++.

А мне повезло, у меня есть друг, который всегда бил меня по рукам, когда я использовал синтаксис С++, но писал не объектно ориентированные программы.

Dron |05.11.2007 19:26
Комментарии: 558


это как это??? заместо слова struct писал слово class???
с99 и так многое позволяет...

некооторые вон на c++ умудряются писать как на си...
не знаю, насколько Линус знает с++, но во всяком случае бесспорно одно... C++ значительно мощнее си. А всякая мощ не дается бесплатно. С++ гораздо менее предсказуем с точки зрения сгенерированного кода. А для ядра это необходимо.

Chizh |05.11.2007 20:19
Комментарии: 85

Зарегистрирован: 13.09.2004 18:42
Dron, Си гораздо более непредсказуем, чем С++. Не вводи людей в заблуждение

ossadchy |05.11.2007 20:50
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
все языки с ручным управлением памятью -- и С, и С++ -- предсказуемы по определению.
в С++ мощь дается практически за даром -- он не ушел очень далеко от С++.
но я против ибо С++ -- монстр, да еще и достаточно старый..

Dron |05.11.2007 22:20
Комментарии: 558


Если кто-то думает что С++ почти то же самое что и си, он наверное плохо значет C++.

C++ позволяет писать меньше букав, кроме того у C++ совершенно другая логика...

Chizh, Под предсказуемостью я имел ввиду полученный в результате код... если на си a + b - Это a + b и ничего другого, т то на C++...

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

Dron |05.11.2007 22:23
Комментарии: 558


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

Использоавние любого инструмента должно быть обосновано.
Я вдре линукс в этом нету необходимости. (хотя может быть и позволило бы немного уменьшить количество букв)

Chizh |06.11.2007 00:34
Комментарии: 85

Зарегистрирован: 13.09.2004 18:42
ossadchy, ручное управление памяти непредсказуемо по определению, потому, что никогда не известно точно, когда память должна быть удалена. Относительно предсказуемым является только автоматический сборщик "мусора", потому что в него заложен значительный интеллектуальный аппарат по отслеживанию висящих, зацикленных и прочих ссылок.

alman |06.11.2007 03:28
Комментарии: 58

Зарегистрирован: 28.10.2006 01:21
это как это??? заместо слова struct писал слово class???


Угу. И не понимал как они работают.

Hmmm |06.11.2007 11:44
Комментарии: 45

Зарегистрирован: 09.08.2006 11:29
Непредсказуемость она больше в голове программиста. Вы только вдумайтесь в возможности директив препроцессора C (в С++ они конечно тоже есть) Встречал программы на С содержащие строчки вида:
#define macro1(x) do_something(x,34,"foo",vary) 

Гений программиста подразумевал что при использовании макроса символ vary будет определен. А как народ возведение в квадрат макросами делает? Этож чем надо болеть в детстве что бы не понимать что макросами такую функцию реализовать невозможно.
Хотя на C++ конечно дух захватывает от осознания того ЧТО можно наворотить
Я думаю ядро линукса постепенно на C++ перепрут, потому как проект огромный и модульности C явно недостаточно. Что поделаешь Эйнштей вон кванты не осилил, его гений это нисколько не умаляет

ossadchy |06.11.2007 14:26
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
2Chizh -- язык-то предсказуем, в классическом смысле этого слова(в данном контексте), и известно когда память освобождать. лишь одна проблема: сложно все человеку держать в голове, и это, естественно, делает автоматическое управление памятью более привлекательным. есть даже волшебная libgc, которая позволяет "включить" автоматическое управление памятью в C и C++.

2Hmmm:
1. как раз модульности в C++ не больше чем в C(действительно хорошо с этим дела в Component Pascal, к примеру)
2. школьники еще не таких макросов могут написать
3. очень сомнительно что таки перепрут... пока это Linux -- врядли... и опять же -- не стоит говорить о некомпетентности Линуса -- это уже просто смешно
Просто человек не видит места данному инструменту в данном проекте.


Если кто-то думает что С++ почти то же самое что и си, он наверное плохо значет C++.

Это верно. C++ очень далек от C, это даже не "надмножество" C. В отличии от изумительного языка Objective-C


Hmmm |06.11.2007 15:07
Комментарии: 45

Зарегистрирован: 09.08.2006 11:29
1. как раз модульности в C++ не больше чем в C(действительно хорошо с этим дела в Component Pascal, к примеру)

На чем базируется ваше утверждение? Из описания Component Pascal я таких выводов не сделал. Если вы близко знакомы с этим языком может приведете конкретный пример?

Dron |06.11.2007 15:14
Комментарии: 558


А вот GC в ядре вообще не место. В приложениях хрен бы с ним... А в ядре все должно быть четко.

Вообще не уважаю gc, для языков, которые не оперируют явно динамической памятью - это естественно, хотя есть разные подходы. А для языков, явно оперирующих распределением памяти - gc - это затыкание дыр... ИМХО.

Программист обязан представлять для чего выделяется память и где ее надо освобождать.

ossadchy |06.11.2007 20:18
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
2Dron: современное ПО ОЧЕНЬ СЛОЖНОЕ, труд программиста дорог, сроки сжатые... все это в результате ОБЯЗЫВАЕТ использовать более удобные средства разработки

2Hmmm: в С и C++, как такового понятия модуля нет.. есть translation unit -- единица компиляции и не более того. В целом -- это модульность. Но сегодняшние задачи требуют большего...

Что есть модуль? Это компонент системы с четко определенным интерфейсом, который может быть внедрен или заменен.
Проблемы в текущих реализациях языка есть везде: определение интерфейса в .h файлах достаточно старомодная вещь и требует наличия и согласования версий этих самых .h файлов с внедряемыми модулями. Модули могут представлять собой объектные файлы, статические или динамические библиотеки... все эти типы модулей достаточно плохо позволяют решать задачу
- объектные файлы и статические библиотеки -- могут быть присоеденены к проекту только на этапе линковки
- динамические библиотеки -- механизмы работы с ними для каждой платформы свои и программист должен "руками" их присоединять к своей программе...
в отличии от того же Component Pascal или ComponentJ не определены механизмы взаимодействия модулей(не их компонент!)...
и это только вершина айсберга...

ossadchy |06.11.2007 20:23
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
2Dron: добавлю.. поймите сейчас дешевле купить компьютер мощней чем тратить время на разработку программ на ассемблере... все ваши измышления перечеркиваются одним простым фактом: GC есть во всех современных языках и используется во всю.. смысл рассуждать о том нужен он или нет -- это стандарт ДЕ ФАКТО.


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

Тут что-то вообще не понятно.. если язык "не оперирует явно"(хотя, как минимум выделением в большинстве случаем явно оперирует программист.. исключение -- управление строками в некоторых языка, как-то Delphi) динамической памятью, то как ему без GC?

Chizh |06.11.2007 22:08
Комментарии: 85

Зарегистрирован: 13.09.2004 18:42
Си - процедурный язык, поэтому под модульностью там понимается только единица компиляции, т.е. исполняемый файл, статическая или динамическая библиотека. С++ оперирует классами, каждый из которых тоже может размещаться в отдельных единицах компиляции. Стало быть модульность заключается не в языке программирования, а в бинарниках. Форматы динамических библиотек хоть и различаются порядком расположения секций, но принцип у всех одинаковый: в каждом модуле есть список импортируемых модулей, которые загружаются в память по мере обращения к процедурам. С точки зрения языка программирования, это довольно прозрачно.

alman |07.11.2007 04:45
Комментарии: 58

Зарегистрирован: 28.10.2006 01:21
стоит говорить о некомпетентности Линуса -- это уже просто смешно


не только смешно, но и неприлично и опасно для репутации.

Я просто хочу сравнить С и С++ на примере виртуальных файловых систем.

Начнём с C - http://www.osrc.info/comment.php?comment.news.946

и то же самое по смыслу на С++


class ISuperblock
{
public:
    virtual class IBlockDevicePartition    *    GetDevice(void) = 0;
    virtual class ISuperblock            *    GetParentSuperblock(void) = 0;

    virtual void            AddReference() = 0;
    virtual void            DelReference() = 0;
    virtual typeDirentry *    ReadDir(class DirectoryHandler * dir) = 0;
    virtual class Inode    *    MakeInode (unsigned short uid, unsigned short gid, unsigned short mode) = 0;
    virtual int                RemoveInode(class Inode * inode) const = 0;
    virtual class Inode *    GetInode(int nInodeNumber, int nParenNumber ) = 0;
    virtual int                ReleaseInode(class Inode * inode) = 0;
    virtual int                InsertDirectoryEntry (class Inode * where, class Inode * which, const char *szName) = 0;
    virtual int                DeleteDirectoryEntry (class Inode * where, const char *szName) = 0;
    virtual int                MakeSymbolicLink(class Inode * inode, const char * szLinkTo) = 0;
    virtual int                StatFS( statfs_t * stat) = 0;
    virtual bool            IsDirectoryEmpty ( class ISuperblock * sb, class Inode * inode_dir) = 0;
    virtual int                FlushDiskCaches(void) = 0;
    virtual int                ConnectToDevice(class IBlockDevicePartition * Device) = 0;
    virtual class Inode    *    GetRootInode(void) = 0;
    virtual void            SetParent(class Inode * inode) = 0;
    virtual const int        GetReferenceCount(void) = 0;
    virtual int                GetCurrentDirectoryName (class IProcess * process, class Inode * inode, char * dirname) = 0;
    virtual const ino_t        GetParenInode(void) = 0;
    virtual char *             GetFileSystemName(void) = 0;
    virtual int                OpenNode(class Inode * inode) = 0;
    virtual int                CloseNode(class Inode * inode) = 0;
    virtual int                TruncateInode(class Inode * inode, unsigned int nSize = 0) = 0;
};


alman |07.11.2007 04:55
Комментарии: 58

Зарегистрирован: 28.10.2006 01:21
пардон, ссылкой ошибся. Вот эта должны быть для сравнения.
http://www.osrc.info/plugins/content/content.php?content.121.2

ossadchy |07.11.2007 09:09
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
2Chizh: ну а как быть с тем что динамически загрузив модуль вы НЕ ЗНАЕТЕ какие классы подгрузились.. стало быть надо разрабатывать свою инфраструктуру для получения интерфейса модуля... с точки зрения программиста -- потраченное время...

ossadchy |07.11.2007 09:13
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
Собственно общепризнано, что C++ хорош для СИСТЕМНОГО программирования. Виртуальные машины, компиляторы, ядра -- там он неплохо работает. В UNIX-подобных системах ему не место в ядре, ибо так сложилось исторически.
Объяснение: если "каркас" ядра написан на C, то всегда можно подключить модуль на C++ и он будет использовать все доступные возможности. Если наоборот - ядро на C++(имею в виду ОО-ядро), а модуль на C, то соответственно такой возможности нет.
Пример: есть GTK и Qt -- первая библиотека написана на С и доступна практически с любого языка без ограничений, вторая же -- на C++ и доступна в полном объеме C++ программам.

Dron |07.11.2007 11:24
Комментарии: 558


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

В остальном ядро - это черный ящик, туда можно запихнуть все, что хочешь, но для интерфейса придется делать процедуры...

Если только не отказаться от аппаратной многоуровневой защиты. Но я лично против этого.

Хорошо ли C++ для ядра, или не очень - это вопрос риторический... такой же как и 'Язык - основа операционной системы'

Dron |07.11.2007 11:37
Комментарии: 558


А по поводу GTK vs QT - то я однозначно выбираю QT, потому, что он гармоничен, в отличии от сборища разрозненных библиотек GTK.

Насчет препятствий, как же всякие pq (Perl/Tk-overQT), PyQT (python bindings for QT), QtRuby... Да, они все объектные... но перенос объектной модели на процедурную несколько неоправдан, хотя и возможен.
GUI по определению объектный.

Hmmm |07.11.2007 16:27
Комментарии: 45

Зарегистрирован: 09.08.2006 11:29
Что фактически делает драйвер в процедуре _init()? Экспортирует таблицу виртуальных методов. Почему тогда не оформить этот подход в виде создания класса предка от которого будут порождаться все остальные классы драйверов в системе? Ведь такой подход идеологически никак не противоречит архитектуре системы (я знаком только с Solaris и немного с Linux архитектурами) А если ООП подход работает для драйверов, что мешает расширить его на все ядро ОС вцелом? Линус пока проявил себя лишь как C программист, его успешных проектов на C++ я не знаю, отсюда могу предположить что его суждения мягко говоря не адекватны в силу недостаточного понимания вопроса. Он знает как написать ядро ОС на C, но не имеет опыта программирования на C++. Если кто нибудь может указать конкретную причину причину по которой C++ не может быть использован для написания ядра операционной системы прошу высказывайтесь.

ossadchy |07.11.2007 17:02
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
2Dron:
GTK vs QT тоже вопрос риторический

2Hmmm:
потому что все то же можно написать на C++ делается без значительных усилий на C. потому что привязаться к C++ -- добавить зависимость от еще одного инструмента при построении. потому что ядро UNIX-подобной системы традиционно пишется на С. в целом это вопрос идеологии.

По поводу недостаточного понимания вопроса Линусом все уже высказались.

Ну а мое отношение к С++ -- резко негативное, в силу громоздкости языка и отсутствия *стандартных* библиотек для решения насущных задач, в силу того что я не воспринимаю шаблоны как удобное средство, в силу того что не люблю идеологически размытых платформ. Хотя когда надо -- применяю и этот язык -- чего только не сделаешь за деньги )

Dron |07.11.2007 17:28
Комментарии: 558


Ну а мое отношение к С++ -- резко негативное, в силу громоздкости языка и отсутствия *стандартных* библиотек для решения насущных задач, в силу того что я не воспринимаю шаблоны как удобное средство, в силу того что не люблю идеологически размытых платформ. Хотя когда надо -- применяю и этот язык -- чего только не сделаешь за деньги )


Может быть ты просто не дружишь с темплейтами?

Вообще, ИМХО, мощное не может быть простым...
Ни один гонщик в мире не ездит на автоматической коробке передач...

За все надо платить... C++ офигенно мощный. И поэтому он сложен.

Кстати насчет 'без значительный усилий делается на си' - в корне не согласен. Чтобы к примеру тот же QT сделать на си, понадобиться написать GTK
Ну если быть проще... на каждый объект QT придется написать по нескольку десятков функций.

Ацкий труд надо сказать...
Проблема даже не в возможностях C++ vs С... просто идеология другая.

То же самое каcается и Linux ядра. Писать на Cи с наворотами - это понты. A идеологию у такого проекта враз не поменяешь.

ossadchy |07.11.2007 17:53
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
2Dron: "не дружу" не значит не использую или не понимаю, вообще нет привычки отрицать неизвестное. С++ -- излишне сложен, и не дает эта сложность ощутимых преимуществ.

GTK предоставляет намного более сложную объектную модель нежели C++. А чтобы сделать Qt пришлось сделать препроцессор C++
А на каждый объект в C++ надо писать 10 методов -- те же функции. Если же в C подключить мощь макросов, многое делается просто и элегантно.

Ну не люблю я сложных вещей

ossadchy |07.11.2007 17:55
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
Вместе с тем я НИ В КОЕМ СЛУЧАЕ не говорю что у С++ нету права жить. Просто мое отношение к нему, по возможности, с аргументацией.

Chizh |07.11.2007 19:59
Комментарии: 85

Зарегистрирован: 13.09.2004 18:42
ossadchy, на этапе сборки модуля линкуются библиотеки импорта всех используемых библиотек. Сами же модули загружаются автоматически динамическим линковщиком, по мере обращения к процедурам библиотек. За ними не обязательно следить специально.
Сегодня Си используется исключительно из-за стандартного интерфейса вызова функций.
По поводу сложности С++: объединение функций в классы ни сколько не усложняют систему, а наоборот, объединяют функции в группы, позволяют строить иерархию. Это же хорошо

Dron |07.11.2007 21:11
Комментарии: 558


А на каждый объект в C++ надо писать 10 методов -- те же функции. Если же в C подключить мощь макросов, многое делается просто и элегантно.

Ну не люблю я сложных вещей


10 методов - это всеравно один объект. то есть одна сущность... в то время как в си, 10 функций - это 10 функций.
Кроме того они еще и общего состояния не имеют, нужно заводить для этого глобалы...

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

Может быть это сложность, но сложность оправданная.
Что касается темплейтов. Я сам еще не все понимаю в них, но из того что понимаю ясно, что никакими языковыми средствами такого не сделать. Не спроста в C# 2.0 тоже привнесли generic.

ossadchy |08.11.2007 10:01
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
2Dron: а вообще пробовал писать ОО программы на С? Никаких "глобалов" не надо -- объявляем 1 или 2 структуры в зависимости от выбранной модели защиты полей. Вообще полезно просто написать пару ОО программок на С чтоб понимать что ООП -- это технология, реализуемая в рамках почти любого языка.


Не спроста в C# 2.0 тоже привнесли generic.

И в Java ввели.. а все от того что статическая типизация(не типобезопасность!) создает кучу проблем которые решаются вот такими вот граблями как шаблоны. Во истину объектно-ориентированные языки не требуют таких "наворотов".

ossadchy |08.11.2007 10:04
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
2Chizh: вы меня не правильно поняли -- я не против ОО языков -- ни в коем случае!


ossadchy, на этапе сборки модуля линкуются библиотеки импорта всех используемых библиотек. Сами же модули загружаются автоматически динамическим линковщиком, по мере обращения к процедурам библиотек. За ними не обязательно следить специально.

Поверьте, с процессом динамической линковки знаком. НО обратите внимание "на этапе сборки модуля линкуются библиотеки импорта всех используемых библиотек" -- а вы можете и не знать ВСЕХ библиотек -- есть плагины, компоненты и масса вещей... вот и рождаются COM, XPCOM и т.д.

ossadchy |08.11.2007 10:11
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
Подитожим
1. С++ в ядро линукс не попадет в ближайшем будущем из-за идеологии проекта и Линуса Торвальдса
2. На С можно писать ОО код. Но никто не заставляет никого делать это именно на С. Хотя это полезно для более глубокого понимания того что сгенерирует компилятор С++.
3. При разработке на С++, как и на любом другом языке, есть свои проблемы. Не зря на сцену выходят Java, C# и др. Но С++ все еще жив и будет жить в силу того что он генерирует полностью контроллируемый программистом код, в силу того что на С++ можно решать задачи любого уровня -- от ядра ОС, компиляторов, виртуальных машин до прикладных програм. Удобство и целесообразность применения -- дело вкуса, привычки и вероисповедания.

Спасибо за внимание.

Dron |08.11.2007 11:52
Комментарии: 558


2Dron: а вообще пробовал писать ОО программы на С? Никаких "глобалов" не надо -- объявляем 1 или 2 структуры в зависимости от выбранной модели защиты полей. Вообще полезно просто написать пару ОО программок на С чтоб понимать что ООП -- это технология, реализуемая в рамках почти любого языка.


ossadchy, На ассемблере пробовал с виртуальными методами... Но ты же не хочешь сказать что это удобнее? Возможно это будет быстрее работать... чуть чуть... такая мизерная выгода не стоит вложенных усилий.

Всмысле на объектном языке это делается проще, изящнее. И надежнее, ибо буквиц меньше.

Во истину объектно-ориентированные языки не требуют таких "наворотов".


Если из языка выбросить понятие типов, то да, шаблоны там не понадобяться. А на си ты даже близко не сможешь приблизиться к функционалу шаблонов. Никакие дефайны не спасут.

ossadchy |08.11.2007 12:56
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
2Dron: не Си как ОО язык я отстаиваю. хотя многое можно сделать и на нем -- для нужд "ядерной" промышленности -- предостаточно. см. 2й пост

cmp |08.11.2007 12:58
Комментарии: 55

Зарегистрирован: 18.04.2005 15:35
ох, как тут си обосрали...
2Hmmm (2ossadchy): Может я ошибаюсь, но кажется линукс начинался писаться на прямых процессорных инструкциях - без этапа компиляции/интерпритации, а учитывая что Линус сейчас работает в компании производящей процы сомневаться в его компетентности я бы совсем не стал.

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

Chizh |08.11.2007 13:28
Комментарии: 85

Зарегистрирован: 13.09.2004 18:42
cmp:"А почему никто ничего не говорил об архитектуре самих процов"...
Узким местом является в основном сборщик мусора. Я слышал, что работы над его аппаратной реализацией в процах уже ведутся.

Dron |08.11.2007 13:54
Комментарии: 558


ох, как тут си обосрали...


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

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

Многие критикуют QT за то, что они ввели свои языковые конструкции. Но ИМХО это невеликая цена привнесенного удобства, респект и уважуха...

Я вот когда писал на ассемблере ядро, тоже написал множество макросов. Для того, чтобы меньше писать в коде. И у меня это по большей части получилось. Но теперь всеравно перехожу на C/C++ ибо удобнее. (Ой, дурак был...

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

А-а-а-а... убью себя ап стену. Риски рулят.

cmp |08.11.2007 15:21
Комментарии: 55

Зарегистрирован: 18.04.2005 15:35
Сборщик мусора? в проце? как-то не представляю.. извините процессор плохо знает байсик и нечайно затер ваш документ, или у него своп карзина будет ))

Chizh |08.11.2007 15:57
Комментарии: 85

Зарегистрирован: 13.09.2004 18:42
Это как MMX или SIMD, не автоматически ускоряют программу своим присутствием, программы должны начать использовать новые инструкции. Принцип работы всех GC одинаков, поэтому можно сделать вполне унифицированные инструкции.

ossadchy |08.11.2007 16:03
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
2cmp:
1. В компетентности линуса как раз я и не сомневался
2. ОО в том виде в котором нам его представляет С++ очень хорошо выражается в инструкциях современных процессоров
3. Оптимизация ПО написанного на динамически типизируемых ОО языках реальна. Динамическая рекомпиляция тут очень и очень помогает, появляются даже возможности сделать такое ПО более быстрым чем написанное на С++(лидер по быстродействию среди других ОО языков). Вот тут подробней об этом.

Hmmm |08.11.2007 23:59
Комментарии: 45

Зарегистрирован: 09.08.2006 11:29
2cmp Линукс писался и пишется на С. Что такое "на прямых процессорных инструкциях" я себе не очень хорошо представляю. Если интересно можете почитать книжку Торвальдса "Just for fun" там собственно он сам историю создания линукса изложил.
Каким боком проектирование процессоров относится к знанию ООП вообще и С++ в частности я не понимаю.
2ossadchy В защиту шаблонов могу привести следующий пример из жизни. Представьте себе, что вам нужно создать 3 класса описывающие координату, скорость и ускорение. С точки зрения функционала эти классы абсолютно одинаковые, однако хочется избежать ситуации когда вместо ускорения случайно начинает использоваться координата ну и т.п. Я решил эту задачу при помощи шаблона, описав им базовый класс со всей необходимой функциональностью и инстанцировал от него 3 класса отличающихся одним целочисленным параметром шаблона. Вообще шаблоны это очень мощное средство языка С++, умение пользоваться ими здорово облегчает жизнь и улучшает читабельность кода.

cmp |09.11.2007 03:41
Комментарии: 55

Зарегистрирован: 18.04.2005 15:35
Читал, оттуда и вспоминал.
Ну как каким, не настолько хорошо я знаю с++ чтобы утверждать что-либо конкретное относительно его, но наверняка есть какая-нить последовательность инструкций часто вызываемая и выполнение которой можно оптимизировать или заменить новой инструкцией. Вообще, мне кажется, что оо языки это некая аналогия с микроядерными системами, а си (со своим все куче) соответственно монолитам, а вот процы одинаковые, - не порядок, есть конечно cell, но как-то, топорно.

ossadchy |10.11.2007 09:50
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
2Hmmm: суть не в том мощное это средство или нет. вопрос в другом -- я, как любитель простоты(прежде всего), всегда ставлю вопрос "А действительно ли это НЕОБХОДИМО?". Так вот, при надлежащем воплощении в языке концепций ООП, необходимость в использовании вещей таких как ШАБЛОНЫ, МНОЖЕСТВЕННОЕ НАСЛЕДОВАНИЕ отпадает как таковая. Но это нисколько не умоляет важности данного инструмента.

Просто на этом форуме я излагаю более с точки зрения ТЕОРИИ, нежели ПРАКТИКИ. Хотя, конечно, в своей практике программирования тоже стараюсь использовать вещи близкие душе. Так, вместо С++ предпочитаю использовать Objective-C.

2cmp: действительно какое-то странное выражение "на прямых процессорных инструкциях". Первая опубликованная версия LINUX была написана на С и ассемблере.


Сборщик мусора? в проце? как-то не представляю.. извините процессор плохо знает байсик и нечайно затер ваш документ, или у него своп карзина будет ))

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

cmp |11.11.2007 08:19
Комментарии: 55

Зарегистрирован: 18.04.2005 15:35
да нормально я это себе представляю, и 99% решений принятых этим самым сборщиком верны, однако, тот оставшийся процент добавляет проблем, и именно его хорошо бы оптимизировать, или как вы говорите упростить сделав более прозрачным механизм работы, например в коде есть вызов eval, откуда сборщику мусора знать к какой переменной он обратится.

ossadchy |11.11.2007 19:05
Комментарии: 58

Зарегистрирован: 10.10.2007 22:55
Сборщик мусора "не знает" даже по какой ветви пойдет выполнение оператора ветвления. Суть в том что все решения принимаются динамически, основываясь на наличии ссылок на данный объект в системе в текущий момент. Если нет ссылок на объект -- он больше никогда не будет использован в системе. Да проблемы бывают, с циклическими ссылками, но эти проблемы успешно решаются более совершенными алгоритмами, нежели простой подсчет ссылок.



Комментарии доступны только авторизованным пользователям, авторизуйтесь или зарегистрируйтесь на сайте здесь

© OSRC.info, 2004-2010.
Авторские права на любые материалы, авторы которых явно указаны, принадлежат их авторам. По вопросам публикации таких материалов обращайтесь к авторам.
Авторские права на любые другие материалы принадлежат OSRC.info.
Сайт является помещением библиотеки. Копирование, сохранение на жестком диске или иной способ сохранения произведений осуществляются пользователями на свой риск.
При использовании материалов сайта ссылка на OSRC.info обязательна.