Oberon space
General Category => Общий раздел => Тема начата: valexey от Ноябрь 28, 2011, 07:56:20 am
-
Может кому любопытно будет:
Я тут пытаюсь использовать D. Воткнулся в отсутствие нормальной
модульности (хотя она декларирована).
В частности - там нет разделения на спецификацию и реализацию модуля.
Что в некоторых случаях жутко не удобно.
То есть с этим там хуже чем в С++ (там хотя бы это более-менее
прилично эмулируется). В D с этим вообще никак.
Кроме того типы из private секции модуля и класса/структуры радостно
утекают во вне, то есть их можно использовать извне.
Примерчик:
// Implementation
module test;
public {
void foo() {foo_helper();}
struct Boo
{
public:
void boo() {S ss; foo_helper();}
private:
struct S {};
}
}
private {
struct HelperStruct {};
void foo_helper() {HelperStruct s;}
}
Specification (generated by dmd -H test.d -c) -- test.di file
// D import file generated from 'test.d'
module test;
public
{
void foo() {foo_helper();}
struct Boo
{
public
{
void boo() {S ss; foo_helper();}
private struct S{}
}
}
}
private
{
struct HelperStruct{}
void foo_helper(){HelperStruct s;}
}
Usage:
import test;
void main() {
foo(); // ok
Boo b; // ok
b.boo(); // ok
Boo.S ss; // ok (wtf?)
HelperStruct s; // ok (wtf?!)
}
Видим что сгенереная для модуля спецификация выглядит просто как
копи-паста реализации модуля. В С++ же это будет выглядеть так:
// test.hpp file
#ifndef _test_hpp_
#define _test_hpp_
void foo();
struct Boo
{
public:
void boo();
private:
struct S {};
};
#endif
// file test.cpp
#include "test.hpp"
struct HelperStruct {}; // private struct for this module only
static void foo_helper() {HelperStruct s;}
void foo() { foo_helper(); }
void Boo::boo() { S ss; foo_helper(); } // method implementation in
implementation side, not in specification!
// file main.cpp
#include "test.hpp"
int main() {
foo(); // ok
Boo b; // ok
b.boo(); // ok
Boo::S ss; // error: struct Boo::S is private
HelperStruct s; // error: HelperStruct was not declared in this scope
return 0;
}
В общем, я ожидал от D в плане модульности бОльшего... Посмотрим что
на это ответит Брайт и Александреску, ибо такая ситуация прямо
противоречит тому, что писал Александреска в своей статье case for D:
"D has a true module system that supports separate compilation and
generates and uses module summaries (highbrowspeak for "header files")
automatically from source, so you don't need to worry about
maintaining redundant files separately, unless you really wish to, in
which case you can. Yep, that stops that nag right in mid-sentence."
-
Да нет здесь какой-то проблемы с модульностью. Как себя должны вести приватные типы - не очевидно. В том же C++, насколько я помню, это не сразу устаканилось (разные компиляторы по разному понимали приватные типы).
P.S. Да, можно сказать, что приватные типы никаким образом не должны присутствовать в интерфейсе модуля. Очевидно в такой постановке есть проблемы на практике. Поэтому, как всегда, пошли на компромисс.
-
Да нет здесь какой-то проблемы с модульностью. Как себя должны вести приватные типы - не очевидно. В том же C++, насколько я помню, это не сразу устаканилось (разные компиляторы по разному понимали приватные типы).
Это очевидно протеворечит спеке на язык. Алсо это признали таки да, багом компилятора.
Между прочим, если это не править, то например радостно отваливается техника opaque pointers. То есть скрытых, локальных, приватных типов нет вообще.
P.S. Да, можно сказать, что приватные типы никаким образом не должны присутствовать в интерфейсе модуля. Очевидно в такой постановке есть проблемы на практике. Поэтому, как всегда, пошли на компромисс.
И какие же тут есть очевидные проблемы? Мы ведь про типы говорим, а не про поля класса. Забудь на минуточку про то что существуют классы и объекты, а также методы. Вот у тебя есть модуль. Внутри и только внутри модуля требуется для пары фунций общий тип, который ни коем образом не должен торчать из модуля. Сейчас это сделать не возможно. А вот в С/С++ -- можно и с успехом делается. То есть ДАЖЕ в C/C++. Я не говорю уже про Аду или там модулу.
PS. Да, пусть оно присутствует в интерфейсе, но пусть этот тип никто извне модуля не сможет использовать. А тут ведь можно...
-
P.S. Да, можно сказать, что приватные типы никаким образом не должны присутствовать в интерфейсе модуля. Очевидно в такой постановке есть проблемы на практике. Поэтому, как всегда, пошли на компромисс.
И какие же тут есть очевидные проблемы?
Например. Есть модуль с f1() и f2(). Я хочу вернуть из f1() "херню", которую (потом) принимает только f2(). За пределами "модуля" "херня" смысла не имеет, ее смысл - связать вызововы f1 -> f2. Внутри "херни" я хочу иметь нужные потроха для работы f2(). И конечно я не хочу, чтоб кто-то эти потроха видел, кроме модуля. Как ты представляешь (можно гипотетически или в применении к D) простое/ эффективное/выразительное решение. В частности - какой тип будет иметь"херня"?
-
P.S. Да, можно сказать, что приватные типы никаким образом не должны присутствовать в интерфейсе модуля. Очевидно в такой постановке есть проблемы на практике. Поэтому, как всегда, пошли на компромисс.
И какие же тут есть очевидные проблемы?
Например. Есть модуль с f1() и f2(). Я хочу вернуть из f1() "херню", которую (потом) принимает только f2(). За пределами "модуля" "херня" смысла не имеет, ее смысл - связать вызововы f1 -> f2. Внутри "херни" я хочу иметь нужные потроха для работы f2(). И конечно я не хочу, чтоб кто-то эти потроха видел, кроме модуля. Как ты представляешь (можно гипотетически или в применении к D) простое/ эффективное/выразительное решение. В частности - какой тип будет иметь"херня"?
Это явный случай opaque pointer'a: http://en.wikipedia.org/wiki/Opaque_pointer
-
Это явный случай opaque pointer'a: http://en.wikipedia.org/wiki/Opaque_pointer
opaque pointer - одно из возможных решений. Причем не самое эффективное. Да и к простоте есть претензии. Ближе всего к эффективно/просто/наглядно подошел... внимание... Да, оберон! :) Там это будет запись с неэкспортированными полями. На плюсах можно замутить структуру с приватными полями - но это уже не так кошерно, потому что придется френдов прописывать (причем тут же в хедере). Ну и, конечно, всегда остаются различные вариации с поинтером.
-
Хотя стоит оговориться, что поскольку в обероне нормально возвращать записи нельзя, то там это будет выглядеть гхм... несколько многословно. Впрочем оберонщикам не привыкать.
-
opaque pointer - одно из возможных решений. Причем не самое эффективное. Да и к простоте есть претензии. Ближе всего к эффективно/просто/наглядно подошел... внимание... Да, оберон! :) Там это будет запись с неэкспортированными полями. На плюсах можно замутить структуру с приватными полями - но это уже не так кошерно, потому что придется френдов прописывать (причем тут же в хедере). Ну и, конечно, всегда остаются различные вариации с поинтером.
В D (после того как пофиксят багу с приватом) это будет публичная структура с приватными полями. Френдов прописывать не надо будет - приват там не скрывает приватное от тех кто объявлен в том же модуле.
-
to Valexey- ну и какое впечатление от языка? чисто технически обучать ему проще чем С++ и почему?
-
to Valexey- ну и какое впечатление от языка? чисто технически обучать ему проще чем С++ и почему?
Когда допилят, будет проще. А то сейчас может быть ситуация, когда ты говоришь студенту, что вот тут будет вот так. Он пишет программу, проверяет, а компилятор выдает нечто другое.
-
to Valexey- ну и какое впечатление от языка? чисто технически обучать ему проще чем С++ и почему?
Когда допилят, будет проще. А то сейчас может быть ситуация, когда ты говоришь студенту, что вот тут будет вот так. Он пишет программу, проверяет, а компилятор выдает нечто другое.
так что допилят - 1. компилятор (кстати какой юзали?), 2. стандартные библиотеки, 3. язык программирования, 3. иде? или всего понемногу(если последнее , то можно оценить в процентах сколько конкретно от каждого пункта по -вашему не хватает для нормальной работы)?
-
Когда допилят, будет проще. А то сейчас может быть ситуация, когда ты говоришь студенту, что вот тут будет вот так. Он пишет программу, проверяет, а компилятор выдает нечто другое.
так что допилят - 1. компилятор (кстати какой юзали?), 2. стандартные библиотеки, 3. язык программирования, 3. иде? или всего понемногу(если последнее , то можно оценить в процентах сколько конкретно от каждого пункта по -вашему не хватает для нормальной работы)?
В основном компилятор. Использовал dmd последний. Но это без разницы на самом деле, ведь фронтенд и у gdc и у ldc тот же самый (ну, иногда отстает на 1-2 версии).
Стандартна либа неплоха. Документация к ней тоже. Проблем с поиском и использованием нужного было много меньше чем в том же ББ.
IDE мне не нужно. Ну, то есть я использовал Sublime (http://www.sublimetext.com/), иногда nano. Мне вполне хватает. Вообще при изучении нового языка обычно предпочитаю щупать его без специализированной IDE.
Но в принципе есть на базе eclipse IDE для D. Народ пользуется и развивает. Но лично я не щупал.
-
Когда допилят, будет проще. А то сейчас может быть ситуация, когда ты говоришь студенту, что вот тут будет вот так. Он пишет программу, проверяет, а компилятор выдает нечто другое.
так что допилят - 1. компилятор (кстати какой юзали?), 2. стандартные библиотеки, 3. язык программирования, 3. иде? или всего понемногу(если последнее , то можно оценить в процентах сколько конкретно от каждого пункта по -вашему не хватает для нормальной работы)?
В основном компилятор. Использовал dmd последний. Но это без разницы на самом деле, ведь фронтенд и у gdc и у ldc тот же самый (ну, иногда отстает на 1-2 версии).
Стандартна либа неплоха. Документация к ней тоже. Проблем с поиском и использованием нужного было много меньше чем в том же ББ.
IDE мне не нужно. Ну, то есть я использовал Sublime (http://www.sublimetext.com/), иногда nano. Мне вполне хватает. Вообще при изучении нового языка обычно предпочитаю щупать его без специализированной IDE.
Но в принципе есть на базе eclipse IDE для D. Народ пользуется и развивает. Но лично я не щупал.
Спасибо... Правильное следствие - ребята из Digital Mars не смогли допилить за 4 года D ( с момента выпуска официальной "стабильной" версии) - в том смысле, что лаги вылазят у новичков при "шапочном" знакомстве , или юзалась альфа?
-
Спасибо... Правильное следствие - ребята из Digital Mars не смогли допилить за 4 года D ( с момента выпуска официальной "стабильной" версии) - в том смысле, что лаги вылазят у новичков при "шапочном" знакомстве , или юзалась альфа?
Есть нюанс - есть D1 и есть D2. Стабильный - D1. Я писал на D2. Это другой язык, хоть и похожий на D1. Он не совместим обратно (в общем случае) с D1. D2 еще не допилили, но именно он мне интересен.
-
Кстати, в следующем релизе либо через релиз D2 научится 64битам под MacOs X. То есть примерно в феврале-марте.
-
Пощупал IDE (DDT) - вполне вменяемо. Основной минус - нет поддержки дебеггера. А так - навигация по коду на уровне. AST есть. Автокомплит есть. Расцветка синтаксиса есть. Инкрементальный билд и подсветка ошибок на лету (без запуска компилятора вручную) - есть.
-
Зарисовка на полях:
Есть enum. Ну, все знают что такое enum -- перечисляемый тип, младший брат алгебраического типа данных.
В D у enum'a есть понятие базового типа. Если у двух типов-енумов базовый тип одинаков, то их можно сравнивать, а вот присваивать нельзя. Пример:
enum A : int {A, B, C} // int -- базовый тип
enum B : int {A, B, C} // но его можно было и не писать, ибо int базовый тип по умолчанию
A a; // a == A.a -- по умолчанию инициализируется первым значением
B b;
a == b; // можно
a = b; // нельзя
Причем в переменной типа enum (в примере - a, либо b) не содержится каких-либо дополнительных тэгов. То есть там по честному просто int Будет лежать (или какой там у нас базовый тип). Никакого дополнительного оверхеда.
В качестве базового типа может быть любой тип данных. лишь бы там была определена операция <. То есть мы можем определить какой-нибудь свой тип (структуру, класс) и подсунуть его в виде базового типа данных в enum.
Ну, например можно строку:
enum Strings : string {A = "A", B="B"}
Strings s = Strings.B;
Как и все остальное в D у меня здешние enum'ы не вызывают wow-эффекта. Например искаропки у enum'a нельзя на этапе компиляции (вроде бы) и на этапе исполнения узнать какие у него вообще есть компоненты-константы. По крайней мере нет простого способа это узнать. С другой стороны, через свой базовый тип это делается довольно таки просто.
В общем, смешанные чувства, как и от всего остального в D. И, возможно, это и есть правильно. (wow-эффект всегда настораживает, по крайней мере лично меня).
-
update: Попробовал IDE на базе eclipse (ddt) - вполне себе ничего. По исходникам ходить умеет (то есть ctrl+click на интересной функции или типе и оно показывает то место где оно было объявлено, в том числе и по стандартным либам ходит), автокомплит есть, фолдинг есть, есть замашки "структурного редактора" - буду отучать, а то оно считает что лучше знает как мне форматировать код. Работает с любой системой сборки.
Из минусов - нет дебагера.
-
Оставлю ка я тут вот эту штучку: http://vibed.org
http://habrahabr.ru/post/142964/
Вдруг кому-то пригодится. :-)
-
http://www.digitalmars.com/d/archives/digitalmars/D/Why_is_D_slower_than_LuaJIT_125080.html
-
http://www.digitalmars.com/d/archives/digitalmars/D/Why_is_D_slower_than_LuaJIT_125080.html
2010 год. Неплохо бы перепроверить.
-
Основной компилятор D будет переписан на D (сейчас он на С++ писан):
http://www.linux.org.ru/news/opensource/8906434
Проект набирающего популярность языка D стал достаточно зрелым чтобы отказаться от использования С++. Как сообщает один из его авторов, Андрей Александреску (Andrei Alexandrescu), в ближайшее время будет начат проект по переписыванию компилятора языка D с С++ на D. Это позволит не только более полно использовать весь потенциал самого D, но и решить ряд проблем местами не слишком красивой архитектуры компилятора.
Проект будет разбит на три этапа. На первом будет написано приложение, позволяющее генерировать корректные заголовки для С++ из модулей D. На втором кодовая база на языке D будет увеличиваться, результатом чего будет существование совместно С++ и D-кода, а на третьем этапе все модули с С++ будут переписаны на D, что в результате даст компилятор D, написанный на самом D.
http://dlang.ru/d-budet-perepisan-s-s-na-sam-d