Команда разработчиков языка D представила (http://forum.dlang.org/thread/oobpf2$14c1$1@digitalmars.com) новую версию компилятора 2.076 (http://dlang.org/D). Язык D использует статическую типизацию, обладает синтаксисом, схожим с C/C++, и обеспечивает производительность компилируемых языков, при этом заимствуя некоторые полезные возможности динамических языков в области эффективности разработки и обеспечения безопасности. Например, предоставляется поддержка ассоциативных массивов, косвенное определение типов, автоматическое управление памятью, средства параллельного программирования, опциональный сборщик мусора, система шаблонов, компоненты для метапрограммирования, возможность использовать библиотеки на языке C, а также некоторые библиотеки на C++ и Objective-C. Компилятор DDMD поддерживает системы GNU/Linux, Windows, OS X, FreeBSD, и архитектуры x86, x86_64, x64.Главным нововведением является режим "-betterC (https://dlang.org/blog/2017/08/23/d-as-a-better-c/)", который позволяет разрабатывать на D полностью совместимые с Си библиотеки, при этом ликвидируя огромное количество проблем чистого Си. Краткий список особенностей (https://dlang.org/changelog/2.076.0.html) данного режима:
- Отсутствие препроцессора
- Более высокая скорость компиляции
- Полноценная модульностью. Поддержка различных видов импорта (статический импорт, частичный импорт, ренейминг при импорте и тд)
- В момент компиляции возможна: генерация кода, интроспекция, проверка различных условий.
- Ветвление на этапе компиляции через "static if" и "static foreach"
- возможны работа блоков вида version(linux) { ... }
- возможность написания циклов вида: "foreach(i; 1 .. 11) { ...}"
- Шаблоны
- Аналог borrow checking из Rust через "scope pointers (scope T*)", "scope slices (scope T[])" и "scope references (scope ref T)"
- Поддержка модификаторов доступа "const" и "immutable"
- TLS по умолчанию
- Поддержка контрактного программирования
- Удобные массивы с поддержкой слайсинга
- Ускорение работы с массивами за счет SIMD
- Удобные unit-тесты
- Встроенная система профилирования
- User-defined атрибуты
- Встроенный и очень удобный генератор документации
- Привычный каждому программисту Си синтаксис
- Поддержка Unicode
- Лучшие чем у C средства безопасного доступа памяти (memory safety)
- Замыкания
- RAII
Код на Си:
/* Eratosthenes Sieve prime number calculation. */#define true 1
#define false 0
#define size 8190
#define sizepl 8191char flags[sizepl];
int main() {
int i, prime, k, count, iter;printf ("10 iterations\n");
for (iter = 1; iter ‹= 10; iter++) {
count = 0;
for (i = 0; i {= size; i++)
flags[i] = true;
for (i = 0; i {= size; i++) {
if (flags[i]) {
prime = i + i + 3;
k = i + prime;
while (k ‹= size) {
flags[k] = false;
k += prime;
}
count += 1;
}
}
}
printf ("\n%d primes", count);
return 0;
}Код в режиме betterC:
import core.stdc.stdio;extern (C):
__gshared bool[8191] flags;
int main() {
int count;printf("10 iterations\n");
foreach (iter; 1 .. 11) {
count = 0;
flags[] = true;
foreach (i; 0 .. flags.length) {
if (flags[i]) {
const prime = i + i + 3;
auto k = i + prime;
while (k ‹ flags.length) {
flags[k] = false;
k += prime;
}
count += 1;
}
}
}
printf("%d primes\n", count);
return 0;
}
Для включения данного режима в dub.sdl необходимо добавить строку:
dflags "-betterC"
Для dub.json строка будет:
"dflags" : ["betterC"],
Предыдущая версия получила так же возможность работы компилятора как библиотеки, что сделало возможным развитие средств качественного автодополнения. Частично данные возможности уже используются плагином (https://marketplace.visualstudio.com/items?itemName=webfreak...) для Visual Studio.
Кроме этого следует отметить выпуск компилятора LDC 1.4.0-beta1 (https://github.com/ldc-developers/ldc/releases/tag/v1.4.0-beta1) в котором появилась полная поддержка разработки под Android и режим кросскомпиляции. Для тех кто только начинает изучать программирование доступна (http://dlang.ru/book) альфа версия русской книги по программированию на D на русском языке.
URL: http://forum.dlang.org/thread/oobpf2$14c1$1@digitalmars.com
Новость: http://www.opennet.me/opennews/art.shtml?num=47120
> Главным нововведением является режим "-betterC"...:
> Отсутствие препроцессораИнтересно, они какую траву употребляют?!
>> Главным нововведением является режим "-betterC"...:
>> Отсутствие препроцессора
> Интересно, они какую траву употребляют?!А что не так? В "улучшенной Сишечке" этот костыль по-любому лишний.
Правда?
>>> Главным нововведением является режим "-betterC"...:
>>> Отсутствие препроцессора
>> Интересно, они какую траву употребляют?!
> А что не так? В "улучшенной Сишечке" этот костыль по-любому лишний.Ну не нравится - не используй - никто же не заставляет! Но зачем же выкидывать столь гибкий инструмент! Всё это так называемое улучшательство пока выглядит так, будто корова в посудной лавке побывала.
>> А что не так? В "улучшенной Сишечке" этот костыль по-любому лишний.
> Ну не нравится - не используй - никто же не заставляет!Инклудами тоже предлагаете не пользоваться?
> Но зачем же выкидывать столь гибкий инструмент! Всё это так называемое улучшательство
> пока выглядит так, будто корова в посудной лавке побывала.Все это так называемое защищательство Священной Коровы выглядит как "слаще морковки ничего не едали".
Чего только стоит "include", по сути вставляющий кусок текста целиком (привет инклудгвардам, привет выводам об ошибках в стопицотой строке, привет отсутствующему пространству имен и частичного импорта). Также привет "грязным" макросам с их кучей нюансов.
Все это наследие инструмента, который по задумке отрабатывает еще до компилятора.
Кстати, костыль этот прикрутили к си отдельно и чуть позже, о чем можно почитать
http://sites.harvard.edu/~lib113/reference/c/c_history.html (Dennis M. Ritchie)
И если для того времени решение было еще приемлимым компромиссом, то в современных реалиях оно смотрится блекло. Кстати, никто не предлагал выкинуть, просто сделать нормально.
Для тебя #include и #define одно и тоже?
> Для тебя #include и #define одно и тоже?С чего это вдруг я так считаю?
Может, просто ты не в курсе, что именно делает препроцессор?Возьми хелломир классический, прогони cpp и удивись
cat test.c
#include <stdio.h>
int main(void)
{
/* a comment */
puts("Hallo Welt");
return 0;
}
cpp test.c|more
# 1 "test.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "test.c"
# 1 "/usr/include/stdio.h" 1 3 4
... // 100500 строк спустяstatic __inline int __sputc(int _c, FILE *_p) {
if (--_p->_w >= 0 || (_p->_w >= _p->_lbfsize && (char)_c != '\n'))
return (*_p->_p++ = _c);
else
return (__swbuf(_c, _p));
}
# 504 "/usr/include/stdio.h" 3 4
extern int __isthreaded;
# 548 "/usr/include/stdio.h" 3 4
# 2 "test.c" 2# 2 "test.c"
int main(void)
{
puts("Hallo Welt");
return 0;
}
Это, конечно, всё правильно, но есть ли в этом вашем Д адекватные средства метапрограммирования, способные заменить макросы? Например, в Си можно создать мета-структуру данных, типа:VAR_START()
DEF_VAR(date, DATE, "дата", 0)
DEF_VAR(time, TIME, "время", 0)
DEF_VAR_RNG(loco_type, USHORT, "Тип локо.", 0, 0, 9999)
DEF_VAR_RNG(loco_num, USHORT, "№ локо.", 0, 0, 9999)
DEF_VAR_RNG(loco_driver, ULONG, "таб. номер", 0, 0, 99999999)
DEF_VAR(last_error_str, CSTR, "Посл.сбой", 0)
DEF_VAR(input_bits, BYTE, "дв.входы", 0)
DEF_VAR_RNG(dgu_num_cogs, USHORT, "зубья маховика ДГУ", 0, 1, 999)
DEF_VAR(dgu_freq, ULONG, "частота ДГУ", 0)
DEF_VAR(speed, SPEED, "Скорость", 0)
DEF_VAR(volume, VOLUME, "Объём", 0)
DEF_VAR(mass, MASS, "Масса", 0)
DEF_VAR(temper, TEMPER, "Темпер.", 0)
DEF_VAR(density, DENSITY, "Плотн.", 0)
//...
VAR_END()и потом, переопределяя макросы VAR_START, DEF_VAR, ... и делая #include, создавать из неё новые типы/структуры/функции/что угодно. Казалось бы, для этого существуют С++ и шаблоны, но шаблоны ВНЕЗАПНО иногда не умеют простейших вещей, которые умеют макросы. Я, например, могу сделать:
#define VAR_START() enum MY_VAR
#define DEF_VAR(name, type, strid, init) var_##name
//...и легко получить из этой мета-структуры:
enum MY_VAR {
var_date,
var_time,
var_loco_type,
var_loco_num,
//...
};Как бы я такое сделал на шаблонах? Так что, макросы все ругают, но от них даже в С++ так и не избавились. Такшта...
> Это, конечно, всё правильно, но есть ли в этом вашем Д адекватные
> средства метапрограммирования, способные заменить макросы? Например, в Си можно создать
> мета-структуру данных, типаЭм, причем тут замена или выкидывание макросов? Речь (в контексте ветки) в первую очередь о недостатках "макросов на препроцессоре" (то же отсутсвие гигиеничности/областей видимости, да и классические "грабли" https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html).
А так, есть сравнение:
https://dlang.org/pretod.html> Как бы я такое сделал на шаблонах?
А зачем прикостыливать пространства имен префиксами в плюсах? )
Ну и да, нормальные AST-макросы умеют и не в такое (там можно еще и типы выражений различать и самим AST манипулировать).
> Это, конечно, всё правильно, но есть ли в этом вашем Д адекватные
> средства метапрограммирования, способные заменить макросы?https://dlang.org/mixin.html
Первый пример:
For example, here we can create a template that generates a struct with the named members:template GenStruct(string Name, string M1)
{
const char[] GenStruct = "struct " ~ Name ~ "{ int " ~ M1 ~ "; }";
}mixin(GenStruct!("Foo", "bar"));
which generates:struct Foo { int bar; }
Потому что в D есть инструменты получше - модули и макросы - которые дают все возмлжности препроцессора без его проблем
Удивило, что разработчики написали учебник на русском.
Эти чудики никак не поймут причину популярности C и C++. Ну пусть думают дальше.
Ну и в чем же эта причина?
> Ну и в чем же эта причина?В том, что их проектировали далеко не полные идиоты. Иначе синтаксис Си сегодня не был бы слизан большей частью языков программирования.
Это слишком абстрактно для причины.
Это же следствие, а не причина
> Эти чудики никак не поймут причину популярности C и C++. Ну пусть
> думают дальше.Причина популярности C -- это популярность C. Если мы представим альтернативную вселенную в которой весь unix написан на pascal'е, то в той вселенной было бы столь же сложно слезть с pascal'я как в нашей с C.
С C++ чуть сложнее, в том смысле что аналогов нет в мировом производстве, и сложно поставить умозрительный эксперимент с альтернативной вселенной в которой C++ заменён на что-то иное. Наверное, из этих сложностей можно сделать вывод, что причины популярности C++ не столь прозаичны.
> Причина популярности C -- это популярность C. Если мы представим альтернативную вселенную
> в которой весь unix написан на pascal'е, то в той вселенной
> было бы столь же сложно слезть с pascal'я как в нашей
> с C.Хм. Тогда, по этой логике, причина популярности Юникс - это популярность Юникс, а причина популярности игры ГТА - это популярность игры ГТА... Я думаю, что всё-таки причина популярности С в том, что он 1) чрезвычайно гибкий и 2) не учит программистов, как им жить (хотя некоторых не мешало бы ;)).
> С C++ чуть сложнее, в том смысле что аналогов нет в мировом
> производстве, и сложно поставить умозрительный эксперимент с альтернативной вселенной
> в которой C++ заменён на что-то иное. Наверное, из этих сложностей
> можно сделать вывод, что причины популярности C++ не столь прозаичны.Ну, тут, по-моему, как раз всё просто - Страуструп взял самый распиаренный на тот момент язык и навесил на него свои костыли, а AT&T всё это продвинула :)
> Хм. Тогда, по этой логике, причина популярности Юникс - это популярность Юникс...Ну... В некотором смысле, да. Каждый уважающий себя программист должен написать свою операционную систему. Большинство из них не уходит дальше переключения задач и поддержки клавиатуры да какого-нибудь vga режима видеокарты. Но некоторые шли (и идут) дальше. Но у них шансов ровно ноль, какую бы блестящую архитектуру они не имели, потому что есть unix. Старый, местами уродливый, но вполне справляющийся со своими задачами.
> причина популярности игры ГТА - это популярность игры ГТА
Это может быть, не знаю. Я крайне плохо ориентируюсь в играх выпущенных в этом тысячелетии. GTA2 ничего так была, но она вроде не пользовалась какой-то особенной популярностью, о которой имело бы смысл говорить, да и надоела она мне где-то во втором, третьем городе. А все последующие GTA я не видел. И потенциальных конкурентов тоже не видел. Так что ничего не могу сказать.
> Я думаю, что всё-таки причина популярности С в том, что он 1) чрезвычайно гибкий и 2) не учит программистов, как им жить (хотя некоторых не мешало бы ;)).
Это _одна_ из причин, которая позволила C стать популярным в _прошлом_. Но лишь одна: без успеха unix он бы остался ничем. Но это в прошлом. Мы же сейчас говорим о настоящем.
Что мешает linux'у вытеснить венду совершенно и полностью? По сути единственная существенная причина -- это популярность венды. Если опять же чисто умозрительно, мы представим что винда магическим образом вдруг перестала существовать, то десктопные юзеры -- и домашние, и корпоративные, -- пострадают два-три года лет, пока экономика сориентируется, перенаправит денежные потоки в линуксодесктоп, пока программисты, UX-дизайнеры среагируют и приведут десктоп на линуксе в порядок, чтобы он в полной мере выполнял бы все те задачи, которые в нашей реальности выполняет венда, а потом всё вернётся на круги своя. Только что вместо наклейки с логотипом венды, на системник будет наклеена наклейка с пингвином.
Javascript -- невероятно дурацкий язык. Который случайно оказался в top10 языков программирования: если бы Брендана Эйха тогда не пинали бы, чтобы тот побыстрее выкатил бы прототип Java для браузера, он бы потратил более 10 дней на разработку того, что потом стало javascript'ом. Но Брендана Эйха пинали, и в результате он не запилил в Mosiac ни scheme, как планировалось исходно, ни джаву. Веб получил проклятие javascript'а. И теперь даже webassembly не сможет снять это проклятие. Webassembly может, в лучшем (недостижимом) случае, вытеснить js из браузера, но js уже и на серверах используется. И не потому, что js чем-то лучше того же python, lua, ruby и других, а просто потому, что js очень-очень популярный.
Эта та же самая "логика". И, я отмечу, как-то так получается, что в подавляющем большинстве ситуаций люди соглашаются с этой логикой, если им не нравится популярный продукт, и не соглашаются с ней, если им он нравится.
> Ну, тут, по-моему, как раз всё просто - Страуструп взял самый распиаренный на тот момент язык и навесил на него свои костыли, а AT&T всё это продвинула :)
Хорошо, когда всё просто: думать не надо.
> И теперь даже webassembly не сможет снять это проклятие.
> Webassembly может, в лучшем (недостижимом) случае, вытеснить js из браузера,
> но js уже и на серверах используется.
> но js уже и на серверах используется.Возражу справедливости ради. WebAssembly должен быть независимой от языка прослойкой. Т.е. и для JS напишут компилятор/транслятор в вебассембли-код. Никто не мешает js-программисту продолжать писАть на любимом js, деплоить на модернизированный node.js в сердце которого будет крутиться не V8, а WebAssembly-движок, написанный для хрома. В момент деплоя и будет происходить компиляция JS в WA.
>> И теперь даже webassembly не сможет снять это проклятие.
>> Webassembly может, в лучшем (недостижимом) случае, вытеснить js из браузера,
>> но js уже и на серверах используется.
>> но js уже и на серверах используется.
> Возражу справедливости ради. WebAssembly должен быть независимой от языка прослойкой.
> Т.е. и для JS напишут компилятор/транслятор в вебассембли-код. Никто не мешает
> js-программисту продолжать писАть на любимом js, деплоить на модернизированный node.js
> в сердце которого будет крутиться не V8, а WebAssembly-движок, написанный для
> хрома. В момент деплоя и будет происходить компиляция JS в WA.Но javascript при этом никуда не денется. Он останется в top10.
> Если мы представим альтернативную вселенную в которой весь unix написан на pascal'е, то в той вселенной было бы столь же сложно слезть с pascal'я как в нашей с C.1. Действительно, если бы не было бы Си - тогда программисты не писали бы на Си, всё правильно. Пришлось бы писать на чём-то другом.
2. Не думаю, что кроссплатформенную ОС, будет удобно писать на паскале.
Код для С явно калька с кода на D, сишник написал бы по другому.
Валяй свой вариант
Предыдущий коммент не мой, но...#include <stdbool.h>
#include <stdio.h>#define size 8190
int main() {
int count;puts("10 iterations");
for (int iter = 10; iter > 0; iter--) {
count = 0;
bool flags[size] = { [0 ... size-1] = true };
for (int i = 0; i < size; i++) {
if (flags[i]) {
int prime = 2 * i + 3;
int k = i + prime;
for (; k < size; k += prime) {
flags[k] = false;
}
count++;
}
}
}
printf ("\n%d primes\n", count);
return 0;
}Да, это C99.
- #define size 8190
+ #define size 8191Там в исходном примере явно кто-то пытался запутать читателя и использовал size не в смысле "количество элементов", а в смысле "самый большой индекс".
Да.
> [0 ... size-1]может быть gnu99 ?
#define SIZE 8190
А чем так принципиально было важно для "настоящего сишника" заменить i + i на 2 * i, и почему не i << 1?
Да пофиг. Ну почти пофиг, потому что с отключёнными оптимизациями 2*i может сэкономить такт.
> Да пофиг. Ну почти пофиг, потому что с отключёнными оптимизациями 2*i может сэкономить такт.Это на какой платформе IMUL шустрее простого ADD? o_O
Если умножение целого на 2, то компилятор автоматом преобразовывает в shl
> Если умножение целого на 2, то компилятор автоматом преобразовывает в shlСильно зависит от контекста (кроме платформы, само-собой) ;)
% echo "int test(int x) {return x*2;}"|gcc -S -masm=intel -fverbose-asm -o- -xc -
mov DWORD PTR [rbp-4], edi # x, x
mov eax, DWORD PTR [rbp-4] # tmp89, x
add eax, eax # D.1834
pop rbp #
.cfi_def_cfa 7, 8
ret% echo "int test(int x) {return x+x;}"|gcc -S -masm=intel -fverbose-asm -o- -xc -
mov DWORD PTR [rbp-4], edi # x, x
mov eax, DWORD PTR [rbp-4] # tmp89, x
add eax, eax # D.1834, tmp89
pop rbp #
.cfi_def_cfa 7, 8
ret% echo "int test(int x) {return x*2;}"|gcc -O2 -S -masm=intel -fverbose-asm -o- -xc -
test:
.LFB0:
.cfi_startproc
lea eax, [rdi+rdi] # D.1837,
ret
.cfi_endproc
.LFE0:
Конечно, зависит от того, на сколько всё может распараллелиться и прочих "мелочей". Ну и, как в примере, от ключа оптимизации. Даже и не спорю.
Если для Obfuscated C Contest - то да. Если нормальный индустриальный код - то примерно так и пишут по возможности.Другое дело, что они зачем-то на C89 пример привели, но он не особо много меняет.
> Если для Obfuscated C Contest - то да. Если нормальный индустриальный код
> - то примерно так и пишут по возможности.То есть тебя даже
#define size 8190
#define sizepl 8191исключительно ради того, чтобы написать <= вместо < не напрягает?
Ну залип человек на каком-то злобном (и замшелом) coding standard, не первый он такой и не последний. Собственно, это много по чему видно, начиная с дефайнов для true/false.
Сколько там еще букв осталось для языков в одну букву?
Язык изначально вообще Mars назывался. Просто коллеги разраба в шутку звали его дишечкой и название прижилось.
код на выходе из под д компилятора быстрее работает, чем из под си? размер исполняемого файла получается меньше? нет. тогда это ненужно совершенно.
А проверить сначала?
Получается идентичное, используя фишки языка D. Если бы оно было быстрее и с другим синтаксисом, причем был бы здесь C?
> Если бы оно было быстрееНе уверен на счет betterC, но иногда D может быть действительно быстрее C: https://togototo.wordpress.com/2013/08/23/benchmarks-round-t.../
Ну, в варианте betterC он в принципе может что-то распараллелить на foreach, но не думаю, что это будет заметно. А вот в плане безопасности - да, выигрыш будет.
> Ну, в варианте betterC он в принципе может что-то распараллелить на foreach,
> но не думаю, что это будет заметно.foreach от for не так уж сильно отличается. Блок внутри foreach, как я понимаю, может вполне себе содержать сайд-эффекты. О каком распараллеливании тут можно тогда говорить?
По-моему основная фишка D в том, что сборка происходит значительно быстрее, чем на C, где основное время пожирает как раз препроцессор. Да и вообще с модулями жить как-то спокойнее. Можно быть уверенным, что имена не пересекутся, что приятно.
10 итераций? :-)
Ну и вообще-то пример полон ошибок.
Хм, кажется, что-то со знаками "<" сотворило что-то плохое - где на юникод заменило, где на фигурные скобки. Но, поправив и подкрутив константы чтобы подольше крутилось, получил пракрически одно и то же время выполнения и размер файла (хотя дишный, конечно, линкуется к libphobos).С другой стороны - не представляю, зачем оно нужно. extern "C" для взаимодействия с сишным кодом в D был всегда, а те, кто как огня боится классов, испугаются и шаблонов, замыканий, foreach и прочих дишных удобств.
> Язык @LANG@ использует статическую типизацию, обладает синтаксисом, схожим с C/C++, и обеспечивает производительность компилируемых языков, при этом заимствуя некоторые полезные возможности динамических языков в области эффективности разработки и обеспечения безопасности.Максим, поменяй уже шаблон.
Где Книга? Сайт упал?
Отличный язык, особенно на фоне вырвиглазного Хруста.
Но проблема та же - не нужны эти убийцы C, С++ в их нишах.Ни IDE, ни полноценных фреймворков, ни игровых движков. А в вебщине-аппликухе тем более не нужны.
Я вот думаю, сегодня заказчик хочет сразу готовый продукт и не готов платить и ждать долго. Значит взяв C или D это продукт или компания либо делает небольшой продукт либо делает его давно и имеет деньги и мощьности написать свой язык и скорее всего какие-то поделия уже в этом имеет.Для кого в целом все эти проделки GO, Rust, D и т.д.?
В целом - для тех, для кого конкретно их соотношение достоинств и недостатков подходит.На том же Go уже достаточно написано, так что ниша для него нашлась (в основном, конечно - компилируемая/типизированная замена Питону).
Rust - поглядим, рано ещё... кое-что на нём пишут, через пару лет соберётся какой-то фидбек, там ясно будет. Может и правда окажется, что его безопасность - не липа и стоит его извращённости.
D - мой любимец но, кажется, оказался сложноват для мейнстрима и время хайпа (когда был D1) его разработчики упустили. А так - он даже сейчас хорошая замена тем же плюсам, код куда чище выходит, собирается быстрее... для большого проекта будет куда удобнее.
А насчёт "быстро"... библиотеки и опыт работы с новыми языками накапливаются, так что "быстро" может и получиться. А кому-то не "быстро" надо, а "fute proof", например. Или надёжность. Или ещё что...
Почему они auto считают достижением? Пришлось в начале программы искать используемую в выражении переменную, чтобы определить тип
Оно и есть достижение. Во-первых, им пользуются там, где нужен просто "правильный" тип, а какой конкретно - не важно. Во-вторых, IDE при необходимости тип покажет, если уж совсем невмоготу. Но при корректном использовании в этом нужды нет, и так видно.
> Почему они auto считают достижением?Я не знаю, зачем это в D, потому что с D знаком на уровне "как-то раз пролистал википедию", но вообще в этом есть бонус: код становится полиморфизм-френдли. Допустим, есть у тебя какой-нибудь контейнер, для которого тип объявляется "по науке". Тебе нужен итератор, ты пишешь что-то типа: auto iter = v.iter();. Если ты потом меняешь тип контейнера (либо потому что он параметризованный, либо перебивая руками сорцы), тебе не надо переписывать объявление переменной iter. Если ты меняешь итератор: auto iter = v.reverse_iter(), или v.iter().filter(|x| x > 0), тебе не надо выяснять как в результате будет называться тип итератора. При этом любому, кто будет работать с этим кодом, совершенно не важно как называется этот тип, важно что он делает, а что он делает описано справа от знака равенства.
Плюс это по мелочи удобно и для примитивных типов. Если я делаю open, то какого типа я получаю результат? int? int32_t? int64_t? fd_t? Да мне плевать, если по-хорошему, я задумываюсь чтобы сделать хорошо компилятору и не спровоцировать ненужных и потенциально ошибочных преобразований типов -- ну, если я напишу что-то типа int64_t fd = open(...);, то всё будет работать, но потом этот fd будет приводится к int32_t при каждом использовании; компилятор наверное соптимизирует; но зачем проверять?
А классы-то можно использовать режиме -betterC ?
> А классы-то можно использовать режиме -betterC ?
Подскажите, нормальный дебаггер там запилили? Пытался вкатиться пару лет назад, язык понравился, а вот от тулчейна все опустилось. GDB емнип работал через раз и даже полей в структуре не показывал.
> GDB емнип работал через раз
> и даже полей в структуре не показывал.Компиляторы d (dmd, gdc, ldc) генерируют немного по-разному дебаговую информацию. Когда я работал над включением поддержки d в gdb, основной упор был сделан на gdc (так как он самый совместимый с gdb).
Сейчас поддержку gdb ведет Iain Buclaw, он же автор gdc. Так что для дебаговых сборок по-прежнему лучше использовать gdc. https://github.com/ibuclaw/gdb
> в gdb, основной упор был
> сделан на gdc (так как он самый совместимый с gdb).Не надо уходить так глубоко в рекурсию.
>LDC 1.4.0-beta1 в котором появилась полная поддержка разработки под Androidможно писать под андройд на D ?
а под iOS нельзя ?
Под iOS пока нельзя
Если "под Андройд", тогда уже и "под йOS"
__gshared в примере всё меняет. Если для простейшего примера в виде алгоритма потребовались два подчеркивания в начале имени, то вот именно поэтому и не взлетел, и вот именно поэтому когнитивный диссонанс "ну я же столько времени потратил, ну может взлетит" и не отпустит вас