Здравствуйте, ArtDenis, Вы писали:
AD>Это что-то из области "булки на деревьях растут, а Россия-родина слонов"?
Ну, не нравится свинодобывающая промышленность — подставь кознестроительную или оброкосборочную.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, Дарней, Вы писали:
Д>>а то, что наука в нашей стране окончательно прогнила и практически ни на что не годится — это и так известный факт
A> Какая чушь! Прогнила не наука, а максимум — система обучения. А Наука не приемлет государственных границ.
A> C Уважением, Andir!
Здравствуйте, Pzz, Вы писали:
Pzz>Тогда уж еще и Биллу Гейтсу — влияние его империи еще сильнее.
Не пойдет. Гейтс — менеджер и финансист. Ему другая премия полагается(хотя не знаю, нужна ли она ему).
eao197 wrote: > > Pzz>Ну вообще, по-моему, это правильно. Диссертация все же должна быть про > Pzz>науку, а не про то, какую замечательную программу можем мы написать. И > Pzz>оцениваться диссертация, по-моему, должна в первую очередь с точки > Pzz>зрения научного вклада. > > А вот мне интересно, за какие открытия присуждают звания "кандидата > технических наук"?
Здравствуйте, Cyberax, Вы писали:
C>Простите, но если вы не понимаете, что интероперабельность делается не только одним extern-вызовом функций, то вы просто дилетант.
Сейчас мы выясним кто здесь дилетант.
R>>Уфф. Меня аж чуть просветление не хватило. То есть это не баг, а _фича_ Си++ такое управление памятью? C>Да, причем она дает достаточно много преимуществ по сравнению с другими языками.
Опишите их. По сравнению с Окамлом, Хаскелем и Cyclone.
R>>Вообще, прежде чем ответить, хочется конечно понять для чего оно вам такое нужно. R>>А то ведь есть такое: http://caml.inria.fr/pub/docs/manual-ocaml/libref/Gc.html C>Ну GC. И что? Кого сейчас этим можно удивить?
Во-первых удивить этим можно С++ к которому такой GC не прицеишь, а во-вторых — речь идет о memory management, если не ошибаюсь?
это включает в себя и то, что описано на той странице. Покажите мне как в С++ сделать то, что умеет окамловский GC.
и не в C++ для .NET, ага?
После чего попробуйте мне рассказать, что в окамле и где угодно нельзя руками выделять и освобождать память.
Вы кстати не сказали зачем вам это нужно. А я жду.
C> // Finally, destroy the key and the region
C> free_ukey(key);
C>В морг.
че?
C>Да и подобное делается с помощью пулов в обычном С++.
Вы о чем вообще. Пул — это что, средство _языка_ должно быть?
R>>Но хочется понять долго ли мемори менеджмент в С++ доходил до state-of-the-art, чтобы достигнуть достигать такого — язык, к которому даже GC нормальный не прицепишь. А то мне кажется, идея такого мемори менеджмента мягко говоря не нова. C>Почему же, консервативные GC подцепляются без проблем (лично Boehm GC использовал). А С++/CLI вообще рассчитан на точную сборку.
Консервативные GC идут туда же, куда автопойнтеры, смартпойнтеры и всякая другая жуть на подпорках для эмуляции GC.
сейчас, на секундочку, 2005 год заканчивается.
что касается C++ на .NET, речь началась про С++, который у страуструпа, а не который на .NET. Не увиливайте.
C>А вот покажите мне, пожалуйста, язык с понятием умных указателей, автоматических объектов, placement new, и при этом не клон С++
Вы сами перечитали хоть перед тем как это отправить?
Во-первых это к языку как таковому отношения не имеет, во-вторых, зачем какому-то языку костыль, если в нем изначально все сделано правильно. смартпойнтеры... надо же.
C>(Hint: наиболее близко к этому подходит язык D).
Очень смешно, но не в тему.
C>>>2) Взаимодействие с кодом на С. Где у нас еще есть extern "C"? R>>Хм. R>>С/Objective-C/D/Cyclone ? C>C не считаем. Objective-C страдает с управлением памятью, да и недоделаный он вообще какой-то. D — да, но это последователь С++.
C>Cyclone — слишком мало возможностей. Нет OOP, темплейтов и т.п.
Чего еще там нет? Вы это почитав/подумав написали?
"т.п." там нет. да.
R>>А вообще конечно это одна из самых важных и уникальных идей и языка С++, да.. R>>Скажите, а foreign export ccall в Хаскеле написать уже нет? R>>или там external в O'Caml C>Простите, но если вы не понимаете, что интероперабельность делается не только одним extern-вызовом функций, то вы просто дилетант.
А расскажите мне чем она делается?
А то у меня вообще тут автомат генерирует все. И я потом пользуюсь.
Получается, что даже проще.
C>И нет. Ни Хаскел, ни OCaml не имеют даже близких возможностей интероперабельности.
Близких, это каких?
А то интересно очень.
C>>>Я писал на OCaml'е и немного на Haskell'е, например. Неплохо, но далеко C>>>не самая лучшая вещь с начала времен. R>>А расскажите какая лучшая? C>Никакая. Но функциональные языки уж точно на нее не тянут.
Расскажите почему. Подробно. И покажите.
R>>Кстати еще интересно чем вам так мемори менеджмент в окамле и хаскеле не угодил. Правда. C>Не всегда GC (и связаный с ним оверхед) нужен. И кое-где он не нужен совсем.
А вот это здорово.
Расскажите какой оверхед у GC. _Особенно_ Окамловского.
И почему окамл быстрее С++ при этом.
Cyberax wrote: > >>> Надо сказать, что ядро к окружению отношение не очень большое имеет (а >>> Unix — это прежде всего окружение). То есть на Linux'е можно запустить и >>> встроеное устройство вообще без файловой системы. Кроме того, критикам >>> Линуса стоит напомнить, что есть куча *BSD-систем, которые так и не >>> набрали популярность (в отличие от Линукса). >> Вообще без файловой системы, это вряд ли. > > Сам такое устройство видел. Делается без проблем — все нужное пишется в > виде ядерных модулей и статически линкуется.
Так можно, но зачем тогда Линух? Почему не eCos или RTEMS, которые как
раз предназначены быть прилинкованы к программе в виде библиотеки.
По-моему, Linux без user space это все же извращение...
А что касается "без проблем", инициализацию в ядре придется таки
подхачить, чтобы оно /sbin/init не пыталось запускать. Для многих, хотя
и не для всех, идея что-то поковырять в ядре не кажется беспроблемной
Pzz wrote:
> Так можно, но зачем тогда Линух? Почему не eCos или RTEMS, которые как > раз предназначены быть прилинкованы к программе в виде библиотеки. > По-моему, Linux без user space это все же извращение...
Куча готовых драйверов, сервисов ядра и т.п.
> А что касается "без проблем", инициализацию в ядре придется таки > подхачить, чтобы оно /sbin/init не пыталось запускать.
Не помню, но кажется это делается даже из make menuconfig.
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> ПК>Пожалуй, правильнее говорить об управлении временем жизни объектов, >> с чем C++, действительно, справляется лучше ряда других языков >> благодаря детерминированному разрушению объектов. GC этой задачи не >> решает. >> Я все же не понимаю кое-чего. Для каких задач нужно такое управление?
C>Например, если нельзя допускать пауз GC и большого оверхеда C>конкурентного GC. Или если существуют гораздо более эффективные методы C>управления памятью для данной задачи (preallocated пулы, например). Или C>если требуется детерминированое уничтожение объекта.
Эффективное управление...
>> Но даже если так, почему С++ здесь справляется лучше тех языков, у >> которых нет проблем с алиасингом?
C>А в С++ нет проблем с алиасингом. Более того, он тоже успешно C>используется для некоторых трюков.
Переведите
C>Вот вам прямо с About Haskell
Что вы хотели сказать цитированием мне этого sales talk десятилетней давности?
>> Окамла, у которого очень прогрессивный копирующий GC при котором куча >> всегда утрамбована и который еще и полностью управляемый? >> Или чем С++ здесь лучше Cyclone c его регионами и прочим?
C>А говорите "выучить язык за пару дней"...
Говорю.
C>В С++ продумано взаимодействие аллокаторов, стандартных контейнеров, C>алгоритмов и т.п. Например, как мне поместить в контейнер OCaml'а C>объект, созданый в блоке shared memory? Причем указатели в этом объекте C>представлены в виде смещений относительно начала блока, а null pointer C>представлен в виде указателя со смещением -1.
Вы будете продолжать фантазировать или хотя бы прочитаете мануал по окамлу?
А то мало того, что придумываете жуть всякую, еще и жуть, которая к особенностям языка (в том числе и С++) вообще не относится.
Указатели, объекты, shared memory... мнда.
И кстати. http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign.html
reductor wrote:
> R>>Уфф. Меня аж чуть просветление не хватило. То есть это не баг, а > _фича_ Си++ такое управление памятью? > C>Да, причем она дает достаточно много преимуществ по сравнению с > другими языками. > Опишите их. По сравнению с Окамлом, Хаскелем и Cyclone.
См. ниже.
> R>>Вообще, прежде чем ответить, хочется конечно понять для чего оно > вам такое нужно. > R>>А то ведь есть такое: > http://caml.inria.fr/pub/docs/manual-ocaml/libref/Gc.html > C>Ну GC. И что? Кого сейчас этим можно удивить? > Во-первых удивить этим можно С++ к которому такой GC не прицеишь, а > во-вторых — речь идет о memory management, если не ошибаюсь?
Ручном управлении памятью.
> это включает в себя и то, что описано на той странице. Покажите мне > как в С++ сделать то, что умеет окамловский GC. > и не в C++ для .NET, ага?
В С++ для этого есть другие средства. Зачастую более адекватные.
> После чего попробуйте мне рассказать, что в окамле и где угодно нельзя > руками выделять и освобождать память. > Вы кстати не сказали зачем вам это нужно. А я жду
Руками освобождать ресурсы. Дикость в современном С++.
> C>Да и подобное делается с помощью пулов в обычном С++. > Вы о чем вообще. Пул — это что, средство _языка_ должно быть?
Нет, благодаря средству языка (а именно placement new) можно
реализовать свое управление памятью для объектов. И в частности данную
систему.
> C>Почему же, консервативные GC подцепляются без проблем (лично Boehm > GC использовал). А С++/CLI вообще рассчитан на точную сборку. > Консервативные GC идут туда же, куда автопойнтеры, смартпойнтеры и > всякая другая жуть на подпорках для эмуляции GC. сейчас, на > секундочку, 2005 год заканчивается. что касается C++ на .NET, речь > началась про С++, который у страуструпа, а не который на .NET. Не > увиливайте.
И что? Можно и точный GC для С++ сделать, но это потребует кооперации со
стороны программиста. В библиотеке Boost.Regex, например, есть такой
один (хотя и примитивный).
> C>А вот покажите мне, пожалуйста, язык с понятием умных указателей, > автоматических объектов, placement new, и при этом не клон С++ > Вы сами перечитали хоть перед тем как это отправить? Во-первых это к > языку как таковому отношения не имеет,
Да? Читаем: автоматические объекты — одна из центральных фич языка.
Умные указатели — требуют перегрузки оператора разыменования, так что
это тоже языковая особенность. Placement new — одна из форм ключевого
слова new.
Дальше будете демонстрировать незнание?
> во-вторых, зачем какому-то языку костыль, если в нем изначально все > сделано правильно. смартпойнтеры... надо же.
Вы не понимаете значение слова "гибкость"? Или наивно полагаете, что
можно предусмотреть все случаи использования заранее?
Имеем: библиотека VTK, все объекты в ней создаются с помощью
статического метода New, а уничтожаются методом Delete. Требуется
написать функцию, которая будет создавать объект, чего-то с ним делать и
возвращать его. При этом я не должен заботиться о необходимости ручного
вызова Delete.
> C>Cyclone — слишком мало возможностей. Нет OOP, темплейтов и т.п. > Чего еще там нет? Вы это почитав/подумав написали? > "т.п." там нет. да.
Когда я в последний раз смотрел — еще не было. Теперь добавили, но все
равно с ограничениями.
> C>Простите, но если вы не понимаете, что интероперабельность делается > не только одним extern-вызовом функций, то вы просто дилетант. > А расскажите мне чем она делается? А то у меня вообще тут автомат > генерирует все. И я потом пользуюсь. > Получается, что даже проще.
Это _использование_ C через проксики, а не полноценная
интероперабельность с ним. А то так можно взять SOAP и сказать, что с
помощью него можно с С интероперировать.
> C>И нет. Ни Хаскел, ни OCaml не имеют даже близких возможностей > интероперабельности. > Близких, это каких?
Битовые поля? union'ы? #pragma pack? Поддержка __stdcall, __fastcall и
других calling conventions. Поддержка сторонних аллокаторов.
> R>>А расскажите какая лучшая? > C>Никакая. Но функциональные языки уж точно на нее не тянут. > Расскажите почему. Подробно. И покажите.
Преимущества пока что не перевешивают недостатков. Я бы предпочел
обычный императивный язык с небольшими функциональными расширениями,
пока в этом направлении движется C#.
> R>>Кстати еще интересно чем вам так мемори менеджмент в окамле и > хаскеле не угодил. Правда. > C>Не всегда GC (и связаный с ним оверхед) нужен. И кое-где он не нужен > совсем. > А вот это здорово. Расскажите какой оверхед у GC.
Функциональное программирование прекрасно, оно — радость созерцания. Как только кто-то поймет функциональное программирование, он немедленно перейдет к нему. Массы, которые застряли в устаревшем императивном и объектно-ориентированном программировании, делают это из слепого предубеждения. Они просто не понимают.
Каким-то религиозным духом попахивает
Хотя интересно было бы найти время покопаться в исходниках unison, он вроде на OCaml был реализован. В свое время и ООП пыталось пробивать себе дорогу.
В предыдущей колонке [1] перечислены некоторые из таких применений, и подчеркнуто как используется мощность функциональных языков. Разработчиков сетей связи привлекает Erlang своей поддержкой параллелизма и распределенных вычислений; последнее непосредственно связано с тем фактом, что функциональные данные, являющиеся неизменным, хорошо пригодны для передачи по сети. Создателей систем доказательств теорем привлекает ML с его поддержкой символьных вычислений. Генетики тяготеют к CPL/Kleisli, потому что его система типов поддерживает доступ к гетерогенным базам данных, и потому что математические свойства функциональных языков могут использоваться для оптимизации запросов. Разработчики экспертных систем привлечены к Natural Expert, потому что ленивые вычисления походят на рассуждения обратным логическим выводом, и потому что ленивые вычисления дают возможность создавать экономичный интерфейс к базам данных.
Хочется добавить, что C, C++ и Java успешно работают во всех этих областях
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
reductor wrote:
> C>Например, если нельзя допускать пауз GC и большого оверхеда > C>конкурентного GC. Или если существуют гораздо более эффективные методы > C>управления памятью для данной задачи (preallocated пулы, например). Или > C>если требуется *детерминированое* уничтожение объекта. > Вы на чей вопрос здесь отвечаете? > Я спрашивал для каких задач. Конкретнее.
Игры, требовательные десктопные приложения, системный софт.
> Опять же, про паузы интересно.
RTFM: http://www.memorymanagement.org/
> C>А в С++ нет проблем с алиасингом. Более того, он тоже успешно > C>используется для некоторых трюков. > Переведите
В С++ нет проблем с накладывающимися массивами, так как они с помощью
адресной арифметики могут быть использованы для интересных
inplace-преобразований.
> C>Вот вам прямо с About Haskell > Что вы хотели сказать цитированием мне этого sales talk десятилетней > давности?
А что, вы один должны гнать sales-talk десятилетней давности про GC?
> C>В С++ продумано взаимодействие аллокаторов, стандартных контейнеров, > C>алгоритмов и т.п. Например, как мне поместить в контейнер OCaml'а > C>объект, созданый в блоке shared memory? Причем указатели в этом объекте > C>представлены в виде смещений относительно начала блока, а null pointer > C>представлен в виде указателя со смещением -1. > Вы будете продолжать фантазировать или хотя бы прочитаете мануал по > окамлу?
КАК мне разместить, скажем, список OCaml'а в shared memory и передать на
него ссылку в другой процесс? В С++ это делается так:
//Type of shared memory vectortypedef vector<int, shmem_allocator_int_t > MyVect;
//Create named vector
MyVect *shmem_vect = segment.construct<MyVect>
("ShmVect")(segment.get_raw_alloc_algo());
for(int i = 0; i < max; ++i){
shmem_vect->push_back(i);
}
В другом процессе:
typedef vector<int, shmem_allocator_int_t > MyVect;
MyVect *shmem_vect = segment.find<MyVect>("ShmVect").first;
//А теперь можно, например, посортировать вектор.
std::sort(shmem_vect->rbegin(), shmem_vect->rend());
Хотя я знаю, что вы скажете — дадите мне ссылку на документацию по FFI и
станете рассказывать, что shared memory устарел и никому не нужен.
Cyberax wrote: > >> Так можно, но зачем тогда Линух? Почему не eCos или RTEMS, которые как >> раз предназначены быть прилинкованы к программе в виде библиотеки. >> По-моему, Linux без user space это все же извращение... > > Куча готовых драйверов, сервисов ядра и т.п.
Ну, куча драйверов не нужна. Нужны именно те, которые соответствуют
вашей embedded системе. А таковых может и не быть.
Что до сервисов, они гораздо в более удобном виде доступны из user space.
>> А что касается "без проблем", инициализацию в ядре придется таки >> подхачить, чтобы оно /sbin/init не пыталось запускать. > > Не помню, но кажется это делается даже из make menuconfig.
По-моему, все же не делается. И оно еще обижается, если у него нету хоть
какой-нибудь рутовой файловой системы.
Pzz wrote:
>> Куча готовых драйверов, сервисов ядра и т.п. > Ну, куча драйверов не нужна. Нужны именно те, которые соответствуют > вашей embedded системе. А таковых может и не быть.
Ну вот как раз в Линуксе они были Этот девайс — промышленный
контроллер с видеокамерой.
>>> А что касается "без проблем", инициализацию в ядре придется таки >>> подхачить, чтобы оно /sbin/init не пыталось запускать. >> Не помню, но кажется это делается даже из make menuconfig. > По-моему, все же не делается. И оно еще обижается, если у него нету хоть > какой-нибудь рутовой файловой системы.
Может быть, уже не помню, а смотреть лень Но оно точно очень просто
делается.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, 0xDEADBEEF, Вы писали:
M>Откровенно говоря , после взгляда на вход в середину цикла , разбираться что этот код делает — пропадает у меня охота ..
В середину бесконечного цикла — it makes a lot of difference.
Впрочем, если вы послушный ребенок и никогда не стреляли из рогатки, потому что мама запрещает, я вас понимаю...
Впрочем, на вопрос вы не ответили. А вопрос, напоминаю, был: "должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет".
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>В середину бесконечного цикла — it makes a lot of difference. DEA>Впрочем, если вы послушный ребенок и никогда не стреляли из рогатки, потому что мама запрещает, я вас понимаю...
Стрельба из рогатки, кстати, отнюдь не безобидное занятие и запрещается не безосновательно.
А если ты используешь goto по принципу "запретный плод сладок", то в этом нет ничего хорошего.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> R>>Уфф. Меня аж чуть просветление не хватило. То есть это не баг, а >> _фича_ Си++ такое управление памятью? >> C>Да, причем она дает достаточно много преимуществ по сравнению с >> другими языками. >> Опишите их. По сравнению с Окамлом, Хаскелем и Cyclone.
C>См. ниже.
>> R>>Вообще, прежде чем ответить, хочется конечно понять для чего оно >> вам такое нужно. >> R>>А то ведь есть такое: >> http://caml.inria.fr/pub/docs/manual-ocaml/libref/Gc.html >> C>Ну GC. И что? Кого сейчас этим можно удивить? >> Во-первых удивить этим можно С++ к которому такой GC не прицеишь, а >> во-вторых — речь идет о memory management, если не ошибаюсь?
C>Ручном управлении памятью.
Последний раз — GC не запрещает вручную выделять память. И попробуйте сказать обратное.
При это по ссылке приведены функции, аналог которых попробуйте найдите в С++.
>> это включает в себя и то, что описано на той странице. Покажите мне >> как в С++ сделать то, что умеет окамловский GC. >> и не в C++ для .NET, ага?
C>В С++ для этого есть другие средства. Зачастую более адекватные.
Покажите как в С++ дефрагментировать кучу
>> После чего попробуйте мне рассказать, что в окамле и где угодно нельзя >> руками выделять и освобождать память. >> Вы кстати не сказали зачем вам это нужно. А я жду
C>См. пример в другом письме с объектом в shared memory.
Мимо кассы.
Скажите зачем вам нужно выделять руками память и освобождать ее.
Это дикость везде.
Но в данном случае вы говорили про ручное управление. Вас шатает из стороны в сторону. Держитесь.
Или хотите сказать, в Cyclone нельзя делать этого автоматически?
>> C>Да и подобное делается с помощью пулов в обычном С++. >> Вы о чем вообще. Пул — это что, средство _языка_ должно быть?
C>Нет, благодаря средству языка (а именно placement new) можно C>реализовать свое управление памятью для объектов. И в частности данную C>систему.
Вот этого я не понял. Хотите сказать, синтаксическая возможность написать new (buffer) — это достижение и уникальная особенность?
Или создать буфер заранее?
И в cyclone/caml/haskell/lisp этого нельзя?
Great.
>> C>Почему же, консервативные GC подцепляются без проблем (лично Boehm >> GC использовал). А С++/CLI вообще рассчитан на точную сборку. >> Консервативные GC идут туда же, куда автопойнтеры, смартпойнтеры и >> всякая другая жуть на подпорках для эмуляции GC. сейчас, на >> секундочку, 2005 год заканчивается. что касается C++ на .NET, речь >> началась про С++, который у страуструпа, а не который на .NET. Не >> увиливайте.
C>И что? Можно и точный GC для С++ сделать, но это потребует кооперации со C>стороны программиста. В библиотеке Boost.Regex, например, есть такой C>один (хотя и примитивный).
Нельзя. Или покажите мне как взять например wxwidgets и запустить его под инкрементальным GC который еще автоматом отучит каждый объект при создании требовать указания родителя.
Кооперация... state-of-the-art система с кооперацией.
>> C>А вот покажите мне, пожалуйста, язык с понятием умных указателей, >> автоматических объектов, placement new, и при этом не клон С++ >> Вы сами перечитали хоть перед тем как это отправить? Во-первых это к >> языку как таковому отношения не имеет,
C>Да? Читаем: автоматические объекты — одна из центральных фич языка.
Это не фича, это баг.
C>Умные указатели — требуют перегрузки оператора разыменования, так что C>это тоже языковая особенность. Placement new — одна из форм ключевого C>слова new.
И таким образом все эти уникальные особенности сводятся к возможности перегружать операторы?
Это не уникальная черта С++. Можете мне просто поверить.
Я уж не говорю, что само понятие "оператор" — это тоже баг в С++.
C>Дальше будете демонстрировать незнание?
О да, великий гуру.
>> во-вторых, зачем какому-то языку костыль, если в нем изначально все >> сделано правильно. смартпойнтеры... надо же.
C>Вы не понимаете значение слова "гибкость"? Или наивно полагаете, что C>можно предусмотреть все случаи использования заранее?
Это не гибкость, это затычки для тех дыр, которые можно кое как заткнуть в С++.
Сделать такое хоть в хаскеле не представляется проблемой.
но там это просто _не нужно_.
C>В качестве примера:
C>Имеем: библиотека VTK, все объекты в ней создаются с помощью C>статического метода New, а уничтожаются методом Delete. Требуется C>написать функцию, которая будет создавать объект, чего-то с ним делать и C>возвращать его. При этом я не должен заботиться о необходимости ручного C>вызова Delete.
Хотите сказать, где-то так нельзя?
Я вам там кидал ссылку на то, что в стандартной библиотеке хаскеля это делает.
>> C>Cyclone — слишком мало возможностей. Нет OOP, темплейтов и т.п. >> Чего еще там нет? Вы это почитав/подумав написали? >> "т.п." там нет. да.
C>Когда я в последний раз смотрел — еще не было. Теперь добавили, но все C>равно с ограничениями.
Знаете, это не разговор. Ручное управление памятью — это очень низкого уровня класс задач.
И Cyclone при этом дает ее выполнять с помощью гораздо более высокуровневых инструментов, чем С++
и гораздо мощнее.
Система типов ML, экзистенциальные и абстрактные типы, сабтайпинг, полиморфные структуры, регионы, блаблабла.
Кроме того, что некоторые вещи в С++ будешь делать год, чтобы заработало, другие там еще и вовсе невозможны по фундаментальным причинам.
Вы вскрыли самое больное место С++ — его Си наследие в области того же управления памяти зачем-то.
Даже фортран ведет себя более пристойно в этом смысле.
А потом опять вскрыли — всю эту жуткую систему перегрузки и шаблонов, которая пыхтит, сопит и очень часто не может сделать даже простейшие вещи.
продавец из вас прямо скажем, не очень
>> C>Простите, но если вы не понимаете, что интероперабельность делается >> не только одним extern-вызовом функций, то вы просто дилетант. >> А расскажите мне чем она делается? А то у меня вообще тут автомат >> генерирует все. И я потом пользуюсь. >> Получается, что даже проще.
C>Это _использование_ C через проксики, а не полноценная C>интероперабельность с ним. А то так можно взять SOAP и сказать, что с C>помощью него можно с С интероперировать.
Можно, а что вас не устраивает, кстати?
>> C>И нет. Ни Хаскел, ни OCaml не имеют даже близких возможностей >> интероперабельности. >> Близких, это каких?
C>Битовые поля? union'ы? #pragma pack? Поддержка __stdcall, __fastcall и C>других calling conventions. Поддержка сторонних аллокаторов.
ЭЭ... foreign import stdcall в хаскеле? Ну и я там ссылку кидал на модуль Foreign.*
А в чем вообще проблема-то?
Что мешает _кому угодно_ завести такую поддержку?
Как и аллокаторы и что угодно еще
>> R>>А расскажите какая лучшая? >> C>Никакая. Но функциональные языки уж точно на нее не тянут. >> Расскажите почему. Подробно. И покажите.
C>Преимущества пока что не перевешивают недостатков. Я бы предпочел
Так а какие недостатки-то. Меня этот вопрос сводит с ума.
C>обычный императивный язык с небольшими функциональными расширениями, C>пока в этом направлении движется C#.
Да, C# движется, пока не дойдет до F#
а F# движется пока не дойдет до окамла.
Вы этого события ждете?
>> R>>Кстати еще интересно чем вам так мемори менеджмент в окамле и >> хаскеле не угодил. Правда. >> C>Не всегда GC (и связаный с ним оверхед) нужен. И кое-где он не нужен >> совсем. >> А вот это здорово. Расскажите какой оверхед у GC.
C>Могу и рассказать — как работают GC я знаю в мельчайших подробностях. C>Можете почитать тему: C>http://rsdn.ru/Forum/Message.aspx?mid=993364&only=1
О чем вы там вообще? Что еще за JIT и каким образом это относится к окамлу?
Ну и мельчайшие подробности. Вы откуда это взяли?
>> _Особенно_ Окамловского. И почему окамл быстрее С++ при этом.
C>Не быстрее. Просто иногда помогает отсутствие алиасинга (о котором в С++ C>можно сказать компилятору с помощью слова restrict).
Бум!
все, приехали. просто отсутствие aliasing и то фигня — просто скажи restrict и будет все в ажуре.
Здравствуйте, eao197, Вы писали:
E>Стрельба из рогатки, кстати, отнюдь не безобидное занятие и запрещается не безосновательно.
...переход улицы, кстати, тоже. Но иногда надо.
E>А если ты используешь goto по принципу "запретный плод сладок".
Ну я вроде бы обосоновал почему я применяю goto в данном случае...
Просто я не испытываю по этому поводу комплексов и применяю его там, где оно подходит
А от вас, я тоже хотел бы услышать ответ на вопрос: "должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет".
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Здравствуйте, minorlogic, Вы писали:
M>>Откровенно говоря , после взгляда на вход в середину цикла , разбираться что этот код делает — пропадает у меня охота ..
DEA>В середину бесконечного цикла — it makes a lot of difference. DEA>Впрочем, если вы послушный ребенок и никогда не стреляли из рогатки, потому что мама запрещает, я вас понимаю...
Давайте не на личности. ?
DEA>Впрочем, на вопрос вы не ответили. А вопрос, напоминаю, был: "должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет".
Я уже писал , goto это НЕЯВНАЯ управляющая конструкция , чтобы понять чем она занимается надо отслеживать логику переходов.
А к примеру do{}while ЯВНО указывает на логику цикла .
reductor wrote:
> C>*Ручном* управлении памятью. > Последний раз — GC не запрещает вручную выделять память. И попробуйте > сказать обратное.
Не запрещает. Но делает это очень неудобным для использования, да еще и
добавляет проблем — GC во время циклов сборки должен сканировать
выделенные пользователем блоки памяти.
Это создает проблемы с расшареной памятью — может возникнуть race
condition с другим процессом. Массивы объектов тоже должны особым
образом инициализироваться. В общем, RTFM стандарт C++/CLI — там
подробно эти сложности расписаны.
> При это по ссылке приведены функции, аналог которых попробуйте найдите > в С++.
С++/CLI или Boehm GC — для тех кому это нужно. В большинстве случаев GC
_не_ нужен.
> C>В С++ для этого есть другие средства. Зачастую более адекватные. > Покажите как в С++ дефрагментировать кучу
1. Не фрагментировать ее. Тем более, что в С++ достаточно для этого средств.
2. Использовать memcpy-moveable-объекты.
3. Сделать move constructor объектам и дефрагментировать на здоровье.
4. Использовать уплотняющий GC.
5. Еще что-то можно придумать.
Придется делать руками (как GC в Boost.Regex), но я не помню, чтобы это
мне когда-нибудь нужно было. Custom'ных аллокаторов для задач мне всегда
хватало.
> C>См. пример в другом письме с объектом в shared memory. > Мимо кассы. > Скажите зачем вам нужно выделять руками память и освобождать ее.
Это не требует GC. Консервативный GC ведь вам не нравится, а точный GC
тянет за собой слона.
> C>Руками освобождать ресурсы. Дикость в современном С++. > Это дикость везде.
Только не в языках с GC. Там это норма.
> Но в данном случае вы говорили про ручное управление. Вас шатает из > стороны в сторону. Держитесь.
Простите, но связь между этими двумя понятиями — одно из самых больших
преимуществ. И вы после этого говорите, что знаете С++????
> Или хотите сказать, в Cyclone нельзя делать этого автоматически?
Нет. В Cyclone нет деструкторов с С++ной семантикой вызова.
> C>Нет, благодаря *средству языка* (а именно placement new) можно > C>реализовать свое управление памятью для объектов. И в частности данную > C>систему. > Вот этого я не понял. Хотите сказать, синтаксическая возможность > написать new (buffer) — это достижение и уникальная особенность?
Да (достижение, хотя и не уникальное). Как мне такое сделать в OCaml? Вы подумайте как это сделать, и что это за собой влечет для GC.
> C>И что? Можно и точный GC для С++ сделать, но это потребует > кооперации со > C>стороны программиста. В библиотеке Boost.Regex, например, есть такой > C>один (хотя и примитивный). > Нельзя.
Можно. Смотрите tracking_ptr.hpp из xpressive в Boost'е, например. В
xpressive используется простой _точный_ GC.
> Или покажите мне как взять например wxwidgets и запустить его под > инкрементальным GC который еще автоматом отучит каждый объект при > создании требовать указания родителя.
А нафига это в wxWidgets нужно? Там вполне хватает ручного управления
памятью.
> C>Да? Читаем: автоматические объекты — одна из центральных фич языка. > Это не фича, это баг.
Ну да. Их же нет в OCaml'е....
> C>Умные указатели — требуют перегрузки оператора разыменования, так что > C>это тоже языковая особенность. Placement new — одна из форм ключевого > C>слова new. > И таким образом все эти уникальные особенности сводятся к возможности > перегружать операторы?
Как мне в OCaml перегрузить оператор обращения к члену структуры?
> C>Вы не понимаете значение слова "гибкость"? Или наивно полагаете, что > C>можно предусмотреть все случаи использования заранее? > Это не гибкость, это затычки для тех дыр, которые можно кое как > заткнуть в С++. > Сделать такое хоть в хаскеле не представляется проблемой. > но там это просто _не нужно_.
Почему-то вы считаете GC — панацеей. И в упор не видите проблем, которые
он создает.
> C>Имеем: библиотека VTK, все объекты в ней создаются с помощью > C>статического метода New, а уничтожаются методом Delete. Требуется > C>написать функцию, которая будет создавать объект, чего-то с ним > делать и > C>возвращать его. При этом я не должен заботиться о необходимости ручного > C>вызова Delete. > Хотите сказать, где-то так нельзя?
Да.
Например в OCaml. Внимание на строчку про "не должен заботиться о
необходимости ручного
вызова Delete". В финализаторе, естественно, это делать тоже нельзя.
> Я вам там кидал ссылку на то, что в стандартной библиотеке хаскеля это > делает.
Ткните пальцем.
> C>Когда я в последний раз смотрел — еще не было. Теперь добавили, но все > C>равно с ограничениями. > Знаете, это не разговор. Ручное управление памятью — это очень низкого > уровня класс задач. > И Cyclone при этом дает ее выполнять с помощью гораздо более > высокуровневых инструментов, чем С++ > и гораздо мощнее.
Не вижу тучи проектов на этом супермощном языке. А лет ему немало уже —
я его в 2001 еще смотрел (если не раньше).
> C>Это _использование_ C через проксики, а не полноценная > C>интероперабельность с ним. А то так можно взять SOAP и сказать, что с > C>помощью него можно с С интероперировать. > Можно, а что вас не устраивает, кстати?
1. Скорость.
2. Уровень интеграции.
3. Трудоемкость сложной интеграции.
> C>Битовые поля? union'ы? #pragma pack? Поддержка __stdcall, __fastcall и > C>других calling conventions. Поддержка сторонних аллокаторов. > ЭЭ... foreign import stdcall в хаскеле? Ну и я там ссылку кидал на > модуль Foreign.*
А __thiscall с __fastcall'ом? В доке по FFI написано про всего две
конвенции — "по умолчанию" и stdcall. Я кстати еще про распространенную
pascal-конвенцию забыл.||*||*
> Что мешает _кому угодно_ завести такую поддержку?
Так ведь не сделали? Значит, что-то мешает.
> Да, C# движется, пока не дойдет до F# > а F# движется пока не дойдет до окамла.
> О чем вы там вообще? Что еще за JIT и каким образом это относится к > окамлу? > Ну и мельчайшие подробности. Вы откуда это взяли?
Кхм. Вообще-то JIT — это Just-In-Time компляция, не знать этого стыдно
(кстати, в OCaml'е оно есть для байт-кодов). И читайте всю тему, а не
одно сообщение.
> C>Не быстрее. Просто иногда помогает отсутствие алиасинга (о котором в > С++ > C>можно сказать компилятору с помощью слова restrict). > Бум! > все, приехали. просто отсутствие aliasing и то фигня — просто скажи > restrict и будет все в ажуре.
Ну да, если я уверен, что в моем коде нет алиасинга, то я могу дать хинт
оптимизатору с помощью атрибута restrict.
Типа так:
void some_func(restrict int *a, restrict int *b)
{
while(*b!=0)
*b++=*a++;
}
1.1.4 stable rev. 510
Какая чушь! Прогнила не наука, а максимум — система обучения. А Наука не приемлет государственных границ.
