Страниц: 1 [2]
  Печать  
Автор Тема: Люди, что Вы думаете о языке Digital Mars?  (Прочитано 13897 раз)
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #15 : Октября 29, 2002, 11:58:00 am »

Бред - не бред - какая разница, вы делите шкуру неубитого медведя - C/C++ есть уже давно, D - его еще нет в удобоваримом виде. Так зачем спорить ? Честно - устал читать это, та же ADA хоть реально существует и ее можно, хоть и с опаской юзать, а вот D ... когда выйдет стэйбл, тогда и поговорим ...
Записан

int19h
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #16 : Октября 29, 2002, 12:29:00 pm »

Вопрос стоит - ждать или не ждать (или же еще шире: участвовать или нет).
Записан
klalafuda
QOR.Team
****
Offline Offline

Сообщений: 1


Просмотр профиля
« Ответ #17 : Октября 29, 2002, 12:43:00 pm »


int19h пишет:
Вопрос стоит - ждать или не ждать (или же еще шире: участвовать или нет).


скорее, вопрос стоит - на сколько сложно вести поддержку подобных средств разработки 3-х фирм под QNX. для примера, Watcom 11x и DigitalMars C++ или D.

имхо трудность не столько в сборки самого компилятора в исполняемый файл [тем более, если он нарисовам на с или c++] сколько в том, что дальше с ним делать ? как подключить к собранному компилятору библиотеки обвязки как и какие ? попробовать сделать библиотеку на основе вызовов в существующие DLL из поставки QNX ? взять исходники с cvs.qnx.com и на их основе сделать свои библиотеки обвязки ? что-то среднее или другое ?

исходные тексты на cvs.qnx.com afaik изрядно устарели, и мягко говоря поддерживаются без фанатизма со стороны QSS. если вообще поддерживаются. если базироваться на вызовах в системные DLL, с очередным патчем вы рискуете попасть в ситуацию несовместимости. опять что-то переделывать,
долго и нудно вытягивать из разных источников, что-же именно там
поменялось и т.д. вообщем, в обоих случаях, идти заведомо на поводу у QSS и заведомо *за* ней, каждый раз непиятно удивляясь, что же там опять поменялось.

*имхо* это очень неблагодарная задача. равно как и требующая массы времени и сил.

// wbr
Записан
RISC
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #18 : Октября 29, 2002, 01:05:00 pm »


int19h пишет:
in, out, inout - И вовсе даже не бред, а практически IDL! =)
Уж всяко лучше, чем сишные & и const &...

Кому как. Я не хочу, чтобы какая-то фигня в мой наймспэйс свои параметры втухивала. Чем плохо простое и явное присваивание?
Можно и так написать:
class MyClass {

int[char[]], double[char[]] theMethod(int[] x, double[] y, char[] z){
// ...
}
}
(int[char[]] iha, double[char[]] dhb) = theMethod(...);

Ну, или что-то похожее?


А может лучше заняться GNU D? И заодно втихаря провести в язык свои идеи, как делает Burton Radons со своим проектом DLI (D/Linux) =)

А вот это правильно! А там и signals & slots протащить в язык... еще чего там ...  

P.S. ИМХО
Записан
int19h
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #19 : Октября 30, 2002, 09:50:00 pm »


имхо трудность не столько в сборки самого компилятора в исполняемый файл [тем более, если он нарисовам на с или c++] сколько в том, что дальше с ним делать ? как подключить к собранному компилятору библиотеки обвязки как и какие ? попробовать сделать библиотеку на основе вызовов в существующие DLL из поставки QNX ? взять исходники с cvs.qnx.com и на их основе сделать свои библиотеки обвязки ? что-то среднее или другое ?


Дело в том, что D настолько близок к C, что большая часть хорошо написанных C header'ов почти без модификаций компилируется. Основная проблема - препроцессор, вот там уже приходится ручками... но в целом, OpenGL и сокеты я в свое время портировал относительно безболезненно.

[quote
если базироваться на вызовах в системные DLL, с очередным патчем вы рискуете попасть в ситуацию несовместимости. опять что-то переделывать,
долго и нудно вытягивать из разных источников, что-же именно там
поменялось и т.д. вообщем, в обоих случаях, идти заведомо на поводу у QSS и заведомо *за* ней, каждый раз непиятно удивляясь, что же там опять поменялось.
[/quote]

Это, к сожалению, применимо к любым не C/C++ средствам разработки под QNX. D в этом плане еще не худший вариант - тут хотя бы возможен некий автоматический .h -> .d конвертер.
Записан
int19h
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #20 : Октября 30, 2002, 09:58:00 pm »


Кому как. Я не хочу, чтобы какая-то фигня в мой наймспэйс свои параметры втухивала. Чем плохо простое и явное присваивание?


Эээ... а при чем тут вообще namespaces??? Какое отношение они имеют к ссылочным параметрам?


int[char[]], double[char[]] theMethod(int[] x, double[] y, char[] z){
// ...
(int[char[]] iha, double[char[]] dhb) = theMethod(...);

Ну, или что-то похожее?


В принципе tuples - штука хорошая... но вот насколько быстро это все будет работать?

А еще это не замена in-out параметрам.


А вот это правильно! А там и signals & slots протащить в язык... еще чего там ...  


Вообще-то сигналы&слоты уже давно там (только они называются delegates, а ля C#). Правда пока только по одному обработчику на каждый слот, но всегда можно сделать класс-обертку, перегрузив соответствующие операторы - я так и сделал в WinD.
Записан
RISC
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #21 : Октября 31, 2002, 05:50:00 pm »


int19h пишет:
Эээ... а при чем тут вообще namespaces??? Какое отношение они имеют к ссылочным параметрам?


Т.е. не это , а т.к. метод не возвращает значение, то все это дело впихивается в переменные текущего блока... или я чего-то там недопонял?


В принципе tuples - штука хорошая... но вот насколько быстро это все будет работать?

А еще это не замена in-out параметрам.

Я же не говорю, чтобы перл переписывать - реализовывать то надо с головой. Программер и так резберется: надо оно ему фича или нет.
А in-out-ы надо тщательнее продумать хотябы, а то там такие дебаты разгорелись...


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

Может тогда и все ручками а-ла Срр? Зачем вообще вводить что-то не полностью функциональное? Надо давать отдых рукам - они не железные.


[ Это Сообщение было отредактировано: RISC в 2002-12-10 12:05 ]
Записан
Страниц: 1 [2]
  Печать  
 
Перейти в: