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

R>Да в принципе и так варнинг есть:
R>

R>double eval(const expr* e)
R>{
R>    if (0 == strcmp("min", e->data.name) && 2 == e->data.count)
R>        return min(eval(e->data.params[0]), eval(e->data.params[1]));
R>    else if (0 == strcmp("max", e->data.name) && 2 == e->data.count)
R>        return max(eval(e->data.params[0]), eval(e->data.params[1]));
R>}
R>

Э нет... давай по взрослому.
Давай с несколькими опкодами, и чтобы Call был в свитче не первым.

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

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

R>>Да в принципе и так варнинг есть:
R>>

R>>double eval(const expr* e)
R>>{
R>>    if (0 == strcmp("min", e->data.name) && 2 == e->data.count)
R>>        return min(eval(e->data.params[0]), eval(e->data.params[1]));
R>>    else if (0 == strcmp("max", e->data.name) && 2 == e->data.count)
R>>        return max(eval(e->data.params[0]), eval(e->data.params[1]));
R>>}
R>>

WH>Э нет... давай по взрослому.
WH>Давай с несколькими опкодами, и чтобы Call был в свитче не первым.

double eval(const expr* e)
{
    switch (e->t)
    {
    case expr::Plus:
        return 0;
    case expr::Call:
        if (0 == strcmp("min", e->data.name) && 2 == e->data.count)
            return min(eval(e->data.params[0]), eval(e->data.params[1]));
        else if (0 == strcmp("max", e->data.name) && 2 == e->data.count)
            return max(eval(e->data.params[0]), eval(e->data.params[1]));
    }
}

'eval' : not all control paths return a value

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

А так?

double eval(const expr* e)
{
    switch (e->t)
    {
    case expr::Call:
        if (0 == strcmp("min", e->data.name) && 2 == e->data.count)
            return min(eval(e->data.params[0]), eval(e->data.params[1]));
        else if (0 == strcmp("max", e->data.name) && 2 == e->data.count)
            return max(eval(e->data.params[0]), eval(e->data.params[1]));
    case expr::Plus:
        return 0;
    }
}

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

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

VD>>>>Это ты про новый стандарт С++?

EC>>>Про OCaml.

VD>>Тогда бось, ты не верно понял remark-а. Он то про новые (гипотетические) мегафичи С++ говорил. Ну, мол ща им обомится и будут они в шоколаде... как эта как ту дуру из Дома 2 завут?

EC>Я расценил его слова как скепсис насчёт OCaml'а в задачах очень критичных по производительности,
EC>т.е. тех, где битовыжимание оправдано — OCaml плюсам там не конкурент.


Эффективная синхронизация это не о битовыжимании. Это о различии в производительности на порядки и о принципиальной способности к масштабированию.
Естественно это не относится к скриптам командной строки. А вот к компиляторам уже может относиться. Если распараллеливание идёт на уровне компиляции функций исходного кода, это составляет достаточно мелкозернистый параллелизм, и издержки на синхронизацию могут начать превышать полезную работу, плюс масштабируемость может оказаться со знаком минус. Хороший вопрос для размышления — почему MSVC распараллеливает компиляцию исключительно на уровне проектов, но даже не на уровне файлов.

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

R>>Поэтому же С используют крупнейшие опен-сорц проекты — linux, postgresql и т.д.
WH> Они его используют исключительно по историческим причинам. Ну написали когдато пара ребятишек мега ОСь UNIX и для того чтобы ее было проще портировать написали переносимый ассемблер ака С. И все начали это безобразие куда попало переносить...
WH>Правда потом ребята поняли свои ошибки и сделали и болие другую ОСь и создали для этого болие другой язык но миллионы мух досихпор продолжают тащить то самое безобразие которое получилось у этих ребят в начале.
То-то я смотрю на исходники Inferno и вижу, что все написано на С. И даже компилятор Limbo на C...
А ты, на мой взгляд, здесь смешиваешь две очень разные задачи — способ создания инструмента, и способ использования инструмента.

Вот чем реально могут помочь в задаче написания ядра операционной системы (ОС) такие языки как Nemerle или C#, которые работают поверх .NET? Конечно, можно на C# написать всю логику ядра ОС — планировщик процессов, управление ресурсами, загрузку/выгрузку программ, но как запускать это ядро? На .NET не запустишь, так как она не работает поверх голого железа (особенно нестандартного); брать какую-то микро-ОС, поверх которой запускать .NET, а на нем уже запускать нашу ОС... Это все хорошо, кроме того, что это не является решением поставленной задачи, так как задача состоит в том, чтобы написать упоминавшуюся микро-ОС (самую-самую базовую).

Можно попробовать скомпилировать программы на вышеупоминавшихся языках в native-код, однако это чисто теоритическая возможность, ведь, насколько я понимаю, официально с компиляцией .NET приложений в native-код есть некоторые сложности... Далее, я читало о ядре ОС, написанной на Haskell, но потом переписанном на C, так как на Haskell — медленно, и в Singularity ядро runtime'а на С/С++ написано... Даже Haskell (GHC), компилятор которого написан на Haskell, имеет RTS, написанную на С...

А теперь от задач абстрактных, к задачам конкретным. Сейчас я занимаюсь разработкой библиотеки асинхронного программирования act-o

Автор: Стэн
Дата: 27.11.07

. На данный момент она написана на C++ и используется только из C++. Не касаясь вопроса о том, что писать клиентские приложения на C++ — некошерно, обратимся к вопросу на чем писать runtime? Для новых эксперементальных runtime'ов я решил отказаться от С++ и писать на чистом C, так как он проще и дров наломать в нем сложнее... В связи с моральным устареванием С, как несколько раз я читал в этой теме, у меня вопрос — есть ли ему какая-то замена? Но только, чтобы программы компилировались в native-код, чтобы был полный и простой доступ к низкоуровневым API ОС и железу, чтобы программы получались быстрыми, и чтобы была возможность относительно легко портировать программы на разные ОС.

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

С>А теперь от задач абстрактных, к задачам конкретным. Сейчас я занимаюсь разработкой библиотеки асинхронного программирования act-o

Автор: Стэн
Дата: 27.11.07

. На данный момент она написана на C++ и используется только из C++. Не касаясь вопроса о том, что писать клиентские приложения на C++ — некошерно, обратимся к вопросу на чем писать runtime? Для новых эксперементальных runtime'ов я решил отказаться от С++ и писать на чистом C, так как он проще и дров наломать в нем сложнее... В связи с моральным устареванием С, как несколько раз я читал в этой теме, у меня вопрос — есть ли ему какая-то замена? Но только, чтобы программы компилировались в native-код, чтобы был полный и простой доступ к низкоуровневым API ОС и железу, чтобы программы получались быстрыми, и чтобы была возможность относительно легко портировать программы на разные ОС.

1) Modula — Oberon.
2) Forth
3) Кроме того есть вариант своего DSL или кодогенератора который генерирует код на си или например на http://www.cminusminus.org/

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

WH>Правда потом ребята поняли свои ошибки и сделали и болие другую ОСь и создали для этого болие другой язык но миллионы мух досихпор продолжают тащить то самое безобразие которое получилось у этих ребят в начале.

Видимо поэтому, Plan9 написанна на C?

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

С>Вот чем реально могут помочь в задаче написания ядра операционной системы (ОС) такие языки как Nemerle или C#, которые работают поверх .NET? Конечно, можно на C# написать всю логику ядра ОС — планировщик процессов, управление ресурсами, загрузку/выгрузку программ, но как запускать это ядро? На .NET не запустишь, так как она не работает поверх голого железа (особенно нестандартного); брать какую-то микро-ОС, поверх которой запускать .NET, а на нем уже запускать нашу ОС... Это все хорошо, кроме того, что это не является решением поставленной задачи, так как задача состоит в том, чтобы написать упоминавшуюся микро-ОС (самую-самую базовую).

Ну и, что ты хотел этим сказать? Что у C++ есть узкая ниша для написания загрузчиков managed-ОС? Ну так никто и не говорит, чтобы его выкинуть вообще. Но для написания 99% софта он и впрямь не очень-то подходит.

Здравствуйте, Стэн, Вы писали:
С>Вот чем реально могут помочь в задаче написания ядра операционной системы (ОС) такие языки как Nemerle или C#, которые работают поверх .NET? Конечно, можно на C# написать всю логику ядра ОС — планировщик процессов, управление ресурсами, загрузку/выгрузку программ, но как запускать это ядро?
Ядро компилируется в нативный код верифицирующим компилятором (см. тж. Bartok), и все дела.
Ты как-то невнимательно читал про Singularity. В его ядре:

Sing#: 90%
C++:    6%
x86asm: 4%

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

K>Здравствуйте, Стэн, Вы писали:

С>>Вот чем реально могут помочь в задаче написания ядра операционной системы (ОС) такие языки как Nemerle или C#, которые работают поверх .NET? Конечно, можно на C# написать всю логику ядра ОС — планировщик процессов, управление ресурсами, загрузку/выгрузку программ, но как запускать это ядро? На .NET не запустишь, так как она не работает поверх голого железа (особенно нестандартного); брать какую-то микро-ОС, поверх которой запускать .NET, а на нем уже запускать нашу ОС... Это все хорошо, кроме того, что это не является решением поставленной задачи, так как задача состоит в том, чтобы написать упоминавшуюся микро-ОС (самую-самую базовую).

K>Ну и, что ты хотел этим сказать? Что у C++ есть узкая ниша для написания загрузчиков managed-ОС?
Вообще-то, все что я хотел сказать, я сказал абзацем выше:

То-то я смотрю на исходники Inferno и вижу, что все написано на С. И даже компилятор Limbo на C...
А ты, на мой взгляд, здесь смешиваешь две очень разные задачи — способ создания инструмента, и способ использования инструмента.

а все остальное было так, для примера.

K>Ну так никто и не говорит, чтобы его выкинуть вообще. Но для написания 99% софта он и впрямь не очень-то подходит.
Согласен. Просто я встретил несколько замечаний на тему, что мол С/С++ морально устаревшие языки, и решил обратить внимание, что есть области, где это далеко не так.

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

S>Здравствуйте, Стэн, Вы писали:
С>>Вот чем реально могут помочь в задаче написания ядра операционной системы (ОС) такие языки как Nemerle или C#, которые работают поверх .NET? Конечно, можно на C# написать всю логику ядра ОС — планировщик процессов, управление ресурсами, загрузку/выгрузку программ, но как запускать это ядро?
S>Ядро компилируется в нативный код верифицирующим компилятором (см. тж. Bartok), и все дела.
S>Ты как-то невнимательно читал про Singularity. В его ядре:
S>

S>Sing#: 90%
S>C++:    6%
S>x86asm: 4%
S>

Я читал этот абзац:

Like the previous Cedar [26] and Spin [4] projects, the Singularity project enjoys the safety and productivity benefits of writing a
kernel in a type-safe, garbage-collected language. Counting lines of code, over 90% of the Singularity kernel is written in Sing#.
While most of the kernel is type-safe Sing#, a significant portion of the kernel code is written in the unsafe variant of the language.
The most significant unsafe code is the garbage collector, which accounts for 48% of the unsafe code in Singularity. Other major
sources of unsafe Sing# code include the memory management and I/O access subsystems. Singularity includes small pockets of
assembly language code in the same places it would be used in a kernel written in C or C++, for example, the thread context
switch, interrupt vectors, etc. Approximately 6% of the Singularity kernel is written in C++, consisting primarily of the
kernel debugger and low-level system initialization code.

Однако, может быть я слишком широко употребил термин "ядро"... Я прекрасно понимаю, что как только мы написали сборщик мусора (GC), то программировать на полноценном С/С++ и использовать этот GC будет немного затруднительно, а скорее всего просто неразумно...

PS: А вот чего я действительно не заметил, так это конкретные значения количества строк кода на C/C++ и ASM?!

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


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

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

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

С>А теперь от задач абстрактных, к задачам конкретным. Сейчас я занимаюсь разработкой библиотеки асинхронного программирования act-o

Автор: Стэн
Дата: 27.11.07

. На данный момент она написана на C++ и используется только из C++. Не касаясь вопроса о том, что писать клиентские приложения на C++ — некошерно, обратимся к вопросу на чем писать runtime? Для новых эксперементальных runtime'ов я решил отказаться от С++ и писать на чистом C, так как он проще и дров наломать в нем сложнее... В связи с моральным устареванием С, как несколько раз я читал в этой теме, у меня вопрос — есть ли ему какая-то замена? Но только, чтобы программы компилировались в native-код, чтобы был полный и простой доступ к низкоуровневым API ОС и железу, чтобы программы получались быстрыми, и чтобы была возможность относительно легко портировать программы на разные ОС.


На немерле зато строк кода будет меньше. А на OCaml всё будет математически выверенно. Ну и что, что работать не будет

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

R>Здравствуйте, Стэн, Вы писали:

С>>А теперь от задач абстрактных, к задачам конкретным. Сейчас я занимаюсь разработкой библиотеки асинхронного программирования act-o

Автор: Стэн
Дата: 27.11.07

. На данный момент она написана на C++ и используется только из C++. Не касаясь вопроса о том, что писать клиентские приложения на C++ — некошерно, обратимся к вопросу на чем писать runtime? Для новых эксперементальных runtime'ов я решил отказаться от С++ и писать на чистом C, так как он проще и дров наломать в нем сложнее... В связи с моральным устареванием С, как несколько раз я читал в этой теме, у меня вопрос — есть ли ему какая-то замена? Но только, чтобы программы компилировались в native-код, чтобы был полный и простой доступ к низкоуровневым API ОС и железу, чтобы программы получались быстрыми, и чтобы была возможность относительно легко портировать программы на разные ОС.


R>На немерле зато строк кода будет меньше. А на OCaml всё будет математически выверенно. Ну и что, что работать не будет

На OCaml будет работать, если бы не требование

простой доступ к низкоуровневым API ОС и железу

то Ocaml вполне подходит.

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

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

R>>Здравствуйте, Стэн, Вы писали:

С>>>А теперь от задач абстрактных, к задачам конкретным. Сейчас я занимаюсь разработкой библиотеки асинхронного программирования act-o

Автор: Стэн
Дата: 27.11.07

. На данный момент она написана на C++ и используется только из C++. Не касаясь вопроса о том, что писать клиентские приложения на C++ — некошерно, обратимся к вопросу на чем писать runtime? Для новых эксперементальных runtime'ов я решил отказаться от С++ и писать на чистом C, так как он проще и дров наломать в нем сложнее... В связи с моральным устареванием С, как несколько раз я читал в этой теме, у меня вопрос — есть ли ему какая-то замена? Но только, чтобы программы компилировались в native-код, чтобы был полный и простой доступ к низкоуровневым API ОС и железу, чтобы программы получались быстрыми, и чтобы была возможность относительно легко портировать программы на разные ОС.


R>>На немерле зато строк кода будет меньше. А на OCaml всё будет математически выверенно. Ну и что, что работать не будет

FR>На OCaml будет работать, если бы не требование

простой доступ к низкоуровневым API ОС и железу

то Ocaml вполне подходит.


Можно ли трактовать такую фразу как-то ещё, кроме как:
Подходит, если не... == не подходит
?


А как, кстати, касательно производительности? Гарантий использования памяти? Возможности контролировать локальность размещения объектов в памяти?
Если есть GC — то тоже не подходит, т.к. скорее всего Стэн'у придётся заняться своим кастомным GC.

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

R>Можно ли трактовать такую фразу как-то ещё, кроме как:
R>Подходит, если не... == не подходит
R>?

Трактовать можно как угодно, только кроме флейма из этого ничего не получится

R>А как, кстати, касательно производительности? Гарантий использования памяти? Возможности контролировать локальность размещения объектов в памяти?
R>Если есть GC — то тоже не подходит, т.к. скорее всего Стэн'у придётся заняться своим кастомным GC.

Производительность хорошая, чуть шустрее java C# и чуть мендленее C++.
GC есть, говорят один из самых шустрых и нежадных к ресурсам. Оптимизатор очень хорош, почти везде где можно обойтись без GC обходится без него.

Насчет рантайма, не знаю может и не подойдет, зависит от того насколько низкий уровень ему нужен. Если слишком низкий то си альтернатив практически нет.

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

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

R>>Можно ли трактовать такую фразу как-то ещё, кроме как:
R>>Подходит, если не... == не подходит
R>>?

FR>Трактовать можно как угодно, только кроме флейма из этого ничего не получится


А это разьве раздел не для флейма?


R>>А как, кстати, касательно производительности? Гарантий использования памяти? Возможности контролировать локальность размещения объектов в памяти?
R>>Если есть GC — то тоже не подходит, т.к. скорее всего Стэн'у придётся заняться своим кастомным GC.

FR>Производительность хорошая, чуть шустрее java C# и чуть мендленее C++.
FR>GC есть, говорят один из самых шустрых и нежадных к ресурсам. Оптимизатор очень хорош, почти везде где можно обойтись без GC обходится без него.


Тут нужны не традиционные оптимизации, которые нужны в прикладном коде. Например по поводу GC имеется в виду, не то, что если объект создан и используется только локально в функции, то для него можно сделать синхронное удаление без помощи GC. Имеются в виду как раз самые что ни на есть активно разделяемые между разными потоками объекты.
Или с чем я постоянно сталкиваюсь в аналогичной задаче — надо разместить множество объектов строго последовательно в памяти в определённом порядке или стопроцентно гарантировать, что какие-то 2 объекта лягут или наоборот не лягут в одну строку кэша. Я так понимаю, что в языках с GC и объектными ссылками через двойные указатели, этого не добиться принципиально.


FR>Насчет рантайма, не знаю может и не подойдет, зависит от того насколько низкий уровень ему нужен. Если слишком низкий то си альтернатив практически нет.


Низкий, не низкий — сложно сказать, вопрос терминологии. Но так скажем — большая часть кода это не традиционный прикладной код, от которого всё, что нужно это лишь функциональность. Вопросы временной сложности, вопросы объёмной сложности, вопросы масштабируемости идут на равне с вопросом голой функциональности. И тут главное, что бы язык/рантайм не ограничивал тебя ни в чём, и не привязывал ни к каким "встроенным" решениям — а это в той или иной мере присуще всем "управляемым" языкам.
По поводу С. В принципе С++ при разумном использовании тоже вполне подходит. Единственное, что иногда разумное — это использование только более строгой типизации, перегрузки функций и ссылок. Но зачастую можно и виртуальными функциями побаловаться

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


R>А это разьве раздел не для флейма?




R>Тут нужны не традиционные оптимизации, которые нужны в прикладном коде. Например по поводу GC имеется в виду, не то, что если объект создан и используется только локально в функции, то для него можно сделать синхронное удаление без помощи GC. Имеются в виду как раз самые что ни на есть активно разделяемые между разными потоками объекты.
R>Или с чем я постоянно сталкиваюсь в аналогичной задаче — надо разместить множество объектов строго последовательно в памяти в определённом порядке или стопроцентно гарантировать, что какие-то 2 объекта лягут или наоборот не лягут в одну строку кэша. Я так понимаю, что в языках с GC и объектными ссылками через двойные указатели, этого не добиться принципиально.

Для такого уровня конечно да пролетает.

FR>>Насчет рантайма, не знаю может и не подойдет, зависит от того насколько низкий уровень ему нужен. Если слишком низкий то си альтернатив практически нет.


R>Низкий, не низкий — сложно сказать, вопрос терминологии. Но так скажем — большая часть кода это не традиционный прикладной код, от которого всё, что нужно это лишь функциональность. Вопросы временной сложности, вопросы объёмной сложности, вопросы масштабируемости идут на равне с вопросом голой функциональности. И тут главное, что бы язык/рантайм не ограничивал тебя ни в чём, и не привязывал ни к каким "встроенным" решениям — а это в той или иной мере присуще всем "управляемым" языкам.
R>По поводу С. В принципе С++ при разумном использовании тоже вполне подходит. Единственное, что иногда разумное — это использование только более строгой типизации, перегрузки функций и ссылок. Но зачастую можно и виртуальными функциями побаловаться

C++ конечно подходит, только шаблоны на низком уровне точно полезней чем виртуальный функции

Здравствуйте, Константин Л., Вы писали:

КЛ>Лезть в отладчик для определения типа это мощно. Вот вам и вывод типов (про такие же проблемы в с++ знаю, так что это палка о двух концах).

Не только для этого. В отладчике ты видишь контекст и можешь трассировать исполнение. Это очень хорошо проясняет картину. Иногда от знания типа толку — ноль.

VD>>А вот Рефлектор на Немерле падает.

КЛ>редко, но бывало

Постоянно если тело фунции содержит рекурсию и сложные матчи.

КЛ>Использовать отладчик для борьбы с выводом типов? Мдя...

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

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

EC>Concepts эту задачу решают. Некий аналог классов типов Хаскеля.

До Хаскелевских классов типов шаблонам С++ никогда не дорости.
Да, и не решают они ничего. Они позволяют прояснить интерфейс параметра типа. Но не зсаставляют использовать их везде. Что создает недетерминизм.