Книга «Programming in D» доступна в бумажном варианте

запись в регистры и дёрганье системных вызовов остаются в ассемблере потому, что Си должен оставаться архитектурно независимым языком, очевидно же

--- И что? Как это мешает «стандартному» коду быть --- переносим между платформами?

--- Тем, что гольный стандартный код нежизнеспособен --- без ASM-вставок. Другое дело, что на разных архитектурах --- может не быть регистров cr0,cr3 или вообще понятия «системный вызов».

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

Сейчас без языка нельзя. Пропадёшь сразу, или из тебя шапку сделают, или воротник, или просто коврик для ног.

Конкретно перевод TDPL не отличается высоким качеством, проще прочитать на английском.

дык вы чего тут делаете, то?

указатель на 2 множите что-ли?

В предчувствии жирного юмора нажал на кнопку «показать удаленные», и был жестоко разочарован: ни одного сообщения там нет. Коллеги, да что же это такое творится-то?! :(

Теперь по теме: надеюсь, что книга на напечатана на мягкой бумаге, и покупателям не придётся долго мять страницы перед использованием?

D не так маниакально безопасен, как Rust, например, поэтому вместо перехода на D можно продолжать использовать C++

Поправил. Можешь не благодарить.

Pure C - это достаточно компактный язык

ORLY? Что же стандарт тогда 600 страниц занимает?

Ди - это как раз тот «преемник», которого давно все ждут.

Ждём. С лопатами.

Да ладно, прекрасный перевод, я из него всё понял. Можно пример того, что я потерял, не обратившись к оригиналу?

Ди - это как раз тот «преемник», которого давно все ждут.

Он с 2000-го года примерно живет и до сих пор «ждут»?

как код может быть нежизнеспособен при переносе без ASM-вставок?

Вот так, нежизнеспособен.

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

При том, что помимо POSIX есть еще и железо. В треде речь как раз и идет о том, что за каким-то хреном язык C пихают как низкоуровневый язык для разработок под платформы. А он для этого и не предназначен. Поэтому и получается, что в язык через библиотеки проникают жуткие костыли в виде типов с платформонезависимыми фиксированными размерами данных. И постоянно лезут проблемы разрядности платформ, которых быть впринципе не должно.

Ты рассказываешь про переносимость в контексте POSIX, так этой переносимости по факту нет, попробуй запустить C-шный код, писаный под 32 бита на платформе 16 бит. А нет совместимости именно из-за аппаратных различий.

В предчувствии жирного юмора нажал на кнопку «показать удаленные», и был жестоко разочарован

И, судя по постам, срочно решили восполнить этот пробел.

стандарт тогда 600 страниц занимает

Мелочи жизни по сравнению с крестами.

Pure C - это достаточно компактный язык

ORLY? Что же стандарт тогда 600 страниц занимает?

Мелочи жизни по сравнению с крестами.

Давай скатимся в точные числа:
* Си ( isoiec9899.pdf ) — 550 станиц
* С++ ( isoiec14882.pdf ) — 739 страниц

Ты действительно настаиваешь, на том, что 550 страниц — это «компактно» и вообще «мелочи»?

У меня немного другая информация

http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4527.pdf

1367 страниц

+ о чем мы спорим? О том, компактен ли C, или о том, целесообразна ли совместимость с ним на уровне ABI? Второе у меня сомнений не вызывает, первое - на ваш вкус, некомпактен так некомпактен.

+ о чем мы спорим? О том, компактен ли C

У меня возражения вызвала вот эта твоя фраза: «Pure C - это достаточно компактный язык».

целесообразна ли совместимость с ним на уровне ABI?

Если ты не можешь заинклудить в свой код си-шный хидер и начать пользоваться си-шной библиотекой непосредственно из своего кода, то от ABI-совместимости не очень много проку: тебе для этой библиотеки придётся генерировать биндинг, и за одно ничто не мешает в этом биндинге подтянуть ABI.

Если же си-шный хидер напрямую инклудится в д-шный исходник, то ... речь идёт о совместимости не только на уровне abi, так?

Да, так. Я могу написать

 extern (C) int strcmp(char* string1, char* string2);

А потом

import std.string;
int myDfunction(char[] s)
{
    return strcmp(std.string.toStringz(s), "foo");
}

А если написать
#include <jpeglib.h>
то оно будет «из коробки» работать?

Нет, так не будет.

Ну и что толку тогда на уровне языка от совместимого ABI? Было бы гораздо логичнее задачу корректного бинарного вызова си-шного (или крестового, или какого еще угодно) кода не делегировать биндингам, а не тащить в сам язык.

Возможность бесшовного использования С-шной стандартной либы, тривиальность написания биндингов.

s/кода не делегировать биндингам/кода делегировать биндингам/

+ возможность использовать в «обратную сторону» D-код из С

Мне кажется, что эти вещи не исключают друг друга.

Возможность бесшовного использования С-шной стандартной либы

Спорный design goal. Си-шная стандартная либа довольно убога.

тривиальность написания биндингов

Имхо, это библиотеками примитивов должно обеспечиваться, а не самим языком. Тогда биндить удобно будет не один только Си, но и множество других языков.

библиотеками примитивов должно обеспечиваться

Насколько я знаю, обеспечивается для других языков (в частности, Python). Но это сложнее все же. Сейчас на D много биндингов к С-либам, и не в последнюю очередь благодаря легкости их написания. Мне кажется, овчинка все же стоила выделки. + когда это решение принималось, D был очень молодой язык, и это позволило сразу получить некоторое количество «батареек» минимальными усилиями.

Ты рассказываешь про переносимость в контексте POSIX, так этой переносимости по факту нет, попробуй запустить C-шный код, писаный под 32 бита на платформе 16 бит. А нет совместимости именно из-за аппаратных различий.

Это зависит от кода, а не от языка. Гляньте на код NetBSD например.

Не совсем понятно, почему вы считаете типы с фиксированным размером костылями. Думаете, что если сделать размер основных типов зависимым от платформы, то это решит проблемы переносимости? Уверяю вас, проблемы только умножатся.

Привет! Я сходу не вспомню. Могу и ошибаться за давностью лет, но у меня неприятный осадок от русского перевода TDPL.

Хотя Ди - это как раз тот «преемник», которого давно все ждут.

Что-то слабо ждут, судя по всему.

Ты не ответил на вопрос.

Давай скатимся в точные числа:
* Си ( isoiec9899.pdf ) — 550 станиц
* С++ ( isoiec14882.pdf ) — 739 страниц
Ты действительно настаиваешь, на том, что 550 страниц — это «компактно» и вообще «мелочи»?

Ты стандарты-то открой, школьник. Плюсовый включает в себя сишный за малым исключнием.

Мелочи жизни по сравнению с крестами.

Ну ты и лалка ))) Выпиши все что есть в D в стандарт, и получишь текста на порядок больше. Если конечно все будет описано так же детально как в С и С++.

Я вообще-то говорил о стандарте C в сравнении с С++, при чем тут сообще стандарт D?

Я вообще-то говорил о стандарте C в сравнении с С++

Так ты и тут лалка, выше уже написали почему.

при чем тут сообще стандарт D?

Не причем, конечно, его же нет и не будет.

Аноним как-то особенно сильно тупит этим чудным августовским вечером...

Плюсовый включает в себя сишный за малым исключнием.

Капитан, у вас обострение?

Зачем ты сравниваешь сумму и слагаемое? Ты норкоман? У меня нет других рабочих гипотез.

Не совсем понятно, почему вы считаете типы с фиксированным размером костылями.

Потому что в C мы имеем взаимоисключающие параграфы. С одной стороны нам говорят - вы должны писать программы независимо от особенностей платформы. С другой стороны говорят - вот вам целочислительный тип int, но помните, что на разных платформах у него разный размер!

Думаете, что если сделать размер основных типов зависимым от платформы, то это решит проблемы переносимости?

Конечно, не решит. Нужно наоборот, иметь основные типы независимые от платформы. Тогда и будет переносимость. И даже переносимость «вниз», на более низкоразрядную платформу не вызовет никаких проблем (про проблемы переносимости на более высокий разряд я тоже в курсе).

Потому что в C мы имеем взаимоисключающие параграфы. С одной стороны нам говорят - вы должны писать программы независимо от особенностей платформы. С другой стороны говорят - вот вам целочислительный тип int, но помните, что на разных платформах у него разный размер!

Не слишком ли назойливо будет предложить... D, где int един для всех платформ?

Между тем, пока суть да дело, релиз состоялся и финальную версию книги уже можно скачать - http://ddili.org/ders/d.en/