Я хоть и не программист, "но нихрена себе" !!!

int* x;

Esli v jazike est ykazateli, to eto pozavcherashnij den.
V obshem, nafig on nygen.

GC там е так что * очевидно для совместимости с Ц

> Поддерживаемые (протестированные) системы: Linux (Red Hat 7.2, 8)

а на слаке пойдет?

или опять все зависит от определенной версии glibc

если не умеешь программировать с умом и настроить кирилицу то ты вчерашний день

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

>> если не умеешь программировать с умом и настроить кирилицу то ты вчерашний день

Я умею, конечно, настроить эту хрень. Ты мне обьясни. пожалуйста, почему я должен ее НАСТРАИВАИТЬ????

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

Соберите сами. Исходники же есть.

Сравнение по ссылке там - отстой аццкий.

Function delegates в C/C++ нет, потому как даром не надо, там есть родные указатели на функции.

Nested functions - в GNU-тых расширениях есть.

>Esli v jazike est ykazateli, to eto pozavcherashnij den.
>V obshem, nafig on nygen.

А в каком языке нет указателей ?

Незнаю как в С# но в жаве кроме указателей вообще ничего нету только они там называются ссылками, но с точки зрения С++ эти "ссылки" чистой воды указатели.

Разве? А не ссылки (Object& a=b;) в терминах C++?

>Разве? А не ссылки (Object& a=b;) в терминах C++?
Это конечно дело спорное но помоему нет.
Имеем на Java:
Object a = new Object();
Object b = null;

Теперь C++:
Object *a = new Object();
Object *b = NULL;
Object c;
Object& d = c;
Object& e = *a;

а под виндой пойдет?

Вообще наверное да, ближе к указателям. Помнится, в C++ ссылку (&) нельзя переназначить на другой объект...

Расширим сравнение... ;-)

Сравним D с FPC/Delphi:

Garbage Collection: Нет. (Есть упрощённый аналог в компонентах).

Functions
Function delegates: Да. (По крайней мере, приведённый им пример очень похож на процедурные типы паскаля, только в паскале по разному чуть-чуть описываются для обычных и функций класса).
Function overloading: Да.
Out function parameters: Да.
Nested functions: Да.
Function literals: Нет. (По крайней мере мне такой способ неизвестен. Я пользовался этим в JavaScript - удобно, но не скажу, что бы отсутствие напрягало. Но факт есть факт).
Dynamic closures: Нет.

Arrays
Lightweight arrays: Х.З. (В его описании массивов легковесные не описаны...)
Resizeable arrays: Да
Arrays of bits: Нет. (Если честно - выгода сомнительна, когда начинаются битовые игры редко подходят универсальные алгоритмы, оптимальнее подбирать каждый раз своё)
Built-in strings: Да. (и давно. ;-) )
Array slicing: Да.
Array bounds checking: Да. (отключаемый по желанию)
Associative arrays: Нет. (Реализуется классами)
Strong typedefs: Да.
String switches: Нет. (И надо отметить, вот этого порой не хватало... ;-) )
Aliases: Да*. (Насколько помню, только алиасы типов)

OOP
Object Oriented: Ну... Да. ;-)
Multiple Inheritance: Х.З. (Не указано, что имеется ввиду. Если - вызов произвольного метода предка, то - да. Если вызов методов дальних предков, то официально - нет, но на самом деле RTTI предоставляет такую возможность, идущую, правда, на уровне грязного хака... ;-) )
Interfaces: Да.
Operator overloading: Нет*. (Я не проверял, может в FPC и добавили. Не требовалось...).
Modules: Да! ;-)
Dynamic class loading: типа, да... (опять же - что имел ввиду? загрузка классов из библиотек? В Delphi есть, реализовано пакетами. В FPC добавляли систему пакетов, но я не проверял ещё её).
Nested classes: М... Нет. (А зачем?)
Inner (adaptor) classes: Нет.
Covariant return types: Вроде да, хотя может я его и неправильно понял... :-\
Properties: Да.

Performance
Inline assembler: Да (Причём в FPC не только x86, понимается at&t стиль)
Direct access to hardware: Да* (Не указано, что надо, если доступ к портам, то есть, но только в тех рамках, в которых пускает ОС).
Lightweight objects: Да. (Причём даже есть старые объекты, именно как легковесные классы... ;-) )
Explicit memory allocation control: Да.
Independent of VM: Да.
Direct native code gen: Да.

Generic Programming
Class Templates: Нет*. (Максимум есть абстрактные методы в классах)
Function Templates: Нет.
Partial and Explicit Specialization: Нет. (Но это выкинули и из C# ;-) )
Value Template Parameters: Нет.
Mixins: Нет.
typeof: Да.
foreach: Нет. (Обычно этим "гордятся" только скриптовые языки... ;-) )

Reliability
Contract Programming: Да*. (По крайней мере, упоминаемый assert - присутствует).
Unit testing: Да*. (В Delphi 7+ есть. Перенесено ли в FPC - не знаю).
Static construction order: Да (Через initialization / finalization)
Guaranteed initialization:
RAII (automatic destructors): Нет*. (Но для наследников TComponent это возможно).
Exception handling: Да.
try-catch-finally blocks: Да.
Thread synchronization primitives: Да.

Compatibility
C-style syntax: Нет. (Хотя, если учитывать комментарии... ;-) )
Enumerated types: Нет.
Support all C types: Нет*. (Они есть, только называются по другому)
80 bit floating point: Да.
Complex and Imaginary: Нет.
Direct access to C: Нет.
Use existing debuggers: Да*. (FPC использует GDB)
Struct member alignment control: Да. (Но чуть менее гибко, чем в D).
Generates standard object files: Х.З. (По идее и Delphi (может) и FPC создают стандартные объектные файлы. Но линковать я их не пробовал).
Macro text preprocessor: Нет*. (Говорили, что в FPC добавили).

Other
Conditional compilation: Да.
Unicode source text: Нет*. (Только Delphi понимает UTF-8 на входе... )

;-) В целом даже поближе будет. И надо было, спрашивается создавать D? Проще было бы добавить несколько фич в паскаль... ;-)))

Вобщем то, что в других языках реализуется за счет библиотек, здесь запихнули в язык... По сути были в истории подобные истории (каламбур) - это PL/1 Тоже напихали в язык все что можно и нельзя... И никто его не мог выучить...

Нахрена он нужен когда есть жаба? Жаба - язык языков. Супер. Ничего ненада кроме он. Все на ЖАБА. А ты перешел на ЖАБА?

> а под виндой пойдет?

http://www.cygwin.com/ Пакет с GDC уже замечен. :)

C, D, Жаба .. Васик - рулит однозначна ! :) А вобще зачем этот D нужен ? Есть и так уже туева куча языков налюбой вкус, любого уровня, начиная от ASM и заканчивая всякими shell'ами и прочими TCL'ами. Кто на этом D чего будет писАть ? Ну разве что для приколу ...

Как язык он может и хорош, но вот только Java и C# представляют собой еще и платфрму с кучей готовых библиотек. Для C/C++ таких библиотек тоже хоть отбавляй. А как с этим у D? Они гордятся тем, что у них нет тяжелого наследия С, тогда получается что они будут создавать очередной клон уже написанных либов.

Ну, наконец-то нормальный язык программирования создали. Не прошло и
сорока лет... Вот сейчас бы программить и программить, но на пенсию уже пора ;)

Хороший язык. Я только не до конца понял, что у него с поддержкой тредов в Linux и не навернётся ли при этом Garbage Collector? Так же стоило бы сделать GC отключаемым, а то автор сам признаётся, что GC может тормозить работу всей программы в произвольный момент времени, а это не всегда приемлемо. Не очень удачно у него сделано игнорирование библиотек на C++, мог бы придумать тул для их импорта. В общем, мне страшновато тредовое сетевое C++ приложение пытаться переписать на D, хотя некоторые фишки (GC, Strings, Arrays) привлекают.

>> а под виндой пойдет?

>http://www.cygwin.com/

Автор D - автор Zortech C (C++) на его сайте и свободный вариант Zortech C++ под win32 есть и конечно исходники D под win32/linix и бинарный пакет с D под win32 и linux.

кто не вкурил - читайте это сообщение ещё и ещё.

>а на слаке пойдет?

на слаке не пойдёт. потому как слаки давно нет.она кончилась еще году в 95м. клон bsd в linux остался жалким клоном. наличие XXX дистрибутивов linux это доказывают (число дистрибутивов bsd с тех под не изменилось)

Multiple inheritance - это наследование от нескольких классов на одном уровне. Dynamic class loading - это reflections в Java. То есть что-то вроде Class.LoadClassByName("MyClass"); (не помню я точно, как это в Java делается). В общем, загрузка класса в runtime по имени и возможность потом создавать объекты этого класса опять же, зная его имя только в runtime.

это также и минус. до сих пор приходиться ;%;?%;тся делая рутинные операции, прежде чем причешешь систему. это вполне мог взять на себя инсталлятор. монополия и отсутствие конкуренции - это отсутствие эволюции

Тллько для Си.

Nested functions are not supported for GNU C++.

http://www.dis.com/gnu/gcc/Nested-Functions.html

Согласен, пока что это всего лишь ЯП, а не платформа, D приобретает популярность (посмотрите например на RSDN).

> Multiple inheritance - это наследование от нескольких классов на одном уровне.

Понятно, тогда его нет. ;-)

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

А это есть. ;-)

Kstati, dlja informazii, razrabotchik jazika D, eto ne kto inoj, kak Walter Bright, kotorij bil osnovnim razrabotchikom takih izvestnih optimizirujushih C/C++ kompiljatorov, kak Zortech C/C++. Posle uhoda s Zortech, on vikupil prava na ih dalnejshuju razrabotku. Na stranize http://www.digitalmars.com mozhno skachat svobodnie (ne bez ishodnikov) C/C++ kompiljatori pod imenem Digital Mars C/C++. Eto dalnejshee razvitie Zortech kompiljatorov.

Nu, a jazik D, eto to chem Walter zanimaetsja v svobodnoe ot razrabotki DigitalMars kompiljatorov vremja ;-)

Непонятно зачем часть C++ STL пихать в язык и объявлять это новым языком? Практически все "преимущества" D делаются через С++ STL (ну за исключением действительно языковых конструкций, польза от которых сомнительна). И зачем для этого придумывать новый язык - и С++ толком мало кто знает досконально?

> Непонятно зачем часть C++ STL пихать в язык и объявлять это новым языком?

Из-за кривого синтаксиса приплюснутых шаблонов, убивающего читабельность кода на С++?

> Практически все "преимущества" D делаются через С++ STL (ну за исключением действительно языковых конструкций, польза от которых сомнительна).

Ну сделай хотя бы Slicing как в D (С ИМЕННО ТАКИМ синтаксисом) через STL.

А вообще говоря ты прав: D - очередная С/C++-образная ерунда, отличия чисто косметические.

жаба это жаба а си это си! скока раз надо это базарить чтобы жабу не закакивали

Можно ссылку на место в документации про runtime загрузку классов ?