LINUX.ORG.RU

Релиз D 2.076.0

 ,


1

6

Команда разработчиков D с великим удовольствием объявляет о выходе новой стабильной версии DMD: 2.076.0

D — это язык программирования общего назначения, мультипарадигменный, быстрый, стабильный.

Поддержка static foreach

import std.conv: to;

static foreach(i; 0 .. 10)
{

    // ‘static foreach’ не добавляет вложенной области видимости
    // (так же как и в ‘static if’).
    
    // следующее объявление mixin находится в области видимости модуля
    mixin(`enum x` ~ to!string(i) ~ ` = i;`); // объявляет десять переменных x0, x1, …, x9..., x9
}

import std.range: iota;
// все типы по которым можно итерироваться обычным ‘foreach’
// так же поддерживаются ‘static foreach’
static foreach(i; iota(10))
{
    // используем объявления сгенерированные ранее в 'static foreach'
    pragma(msg, "x", i, ": ", mixin(`x` ~ to!string(i)));
    static assert(mixin(`x` ~ to!string(i)) == i);
}

void main()
{
    import std.conv: text;
    import std.typecons: tuple;
    import std.algorithm: map;
    import std.stdio: writeln;

    // у 'static foreach' есть две формы: объявление и инструкция
    // (так же как у 'static if').
    static foreach(x; iota(3).map!(i => tuple(text("x", i), i)))
    {
        // создает три локальных переменных x0, x1 и x2
        mixin(text(`int `,x[0],` = x[1];`));

        scope(exit) // внутри области видимости 'main'
        {
            writeln(mixin(x[0]));
        }
    }
    
    writeln(x0," ",x1," ",x2); // результат выполнения
}

Улучшения -betterC

Много улучшений было добавлено к новой опции компилятора dmd -betterC, программы скомпилированные с -betterC не будут ссылаться на неиспользуемые части рантайм, asserts реализованы как C <assert.h> вызовы, а phobos (прим. пер. стандартная библиотека) не слинкована по умолчанию.

Хотите знать больше про Better C? Вам сюда.

Добавлена поддержка AVX2

Компилятор теперь может генерировать инструкции AVX2. Поддержка автоматически распознается с помощью -mcpu=native.

Изменения в стандартной библиотеке

std.base64.Base64URLNoPadding позволяет кодирование/декодирование без смещения

import std.base64 : Base64URLNoPadding;

ubyte[] data = [0x83, 0xd7, 0x30, 0x7b, 0xef];
assert(Base64URLNoPadding.encode(data) == "g9cwe-8");
assert(Base64URLNoPadding.decode("g9cwe-8") == data);

std.digest.digest переименовано в std.digest.

std.meta.Stride добавлен, позволяет выбрать подмножество шаблона по размеру шага и отступу

alias attribs = AliasSeq!(short, int, long, ushort, uint, ulong);
static assert(is(Stride!(3, attribs) == AliasSeq!(short, ushort)));
static assert(is(Stride!(3, attribs[1 .. $]) == AliasSeq!(int, uint)));

Был добавлен Config.detached флаг для spawnProcess, он позволяет запускать новые процессы независимо от текущего процесса. Нет нужды ждать их завершения, ведь они никогда не станут зомби процессами! Попытки вызвать std.process.wait или std.process.kill на обособленом процессе бросит исключение.

Теперь можно использовать std.range.chunks с непрямыми диапазонами, но с ограничениями, налагаемыми этими диапазонами.

import std.algorithm.comparison : equal;

int i;

// генератор не сохраняет состояние, так что он не может быть прямым диапазоном
auto inputRange = generate!(() => ++i).take(10);

// мы все еще можем его обработать по частям, но только за один проход
auto chunked = inputRange.chunks(2);

assert(chunked.front.equal([1, 2]));
assert(chunked.front.empty); // итерация по чанку сьедает его
chunked.popFront;
assert(chunked.front.equal([3, 4]));

Теперь std.socket.UnixAddress поддерживает абстрактные адреса. UNIX сокеты обычно идентифицируются по пути. Linux поддерживает непереносимое расширение этой схемы, известное как абстрактный адрес сокета, которое независимо от файловой системы. Начинается абстрактный адрес с нулевого байта.

auto addr = new UnixAddress("\0/tmp/dbus-OtHLWmCLPR");

Добавлена возможность использовать базовый класс когда производится автоматическая реализация интерфейса. Второй шаблон std.typecons.AutoImplement был добавлен, в отличии от существующего он принимает дополнительный параметр. Этот параметр позволяет уточнить класс от которого наследуемся во время автоматической реализация интерфейса.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: CYB3R (всего исправлений: 11)
Ответ на: комментарий от RazrFalcon

То есть 99% остальных либ/фреймворков по вашему жуткое говнище и вы все еще продолжаете верить в c++ ?

umren ★★★★★
() автор топика
Ответ на: комментарий от umren

в go

Ну, природу то не обманешь. Где-то там подвох, например паузы чаще. В любом случае оценить это нельзя, гуи на го что-то не пишут совсем.

bread
()
Ответ на: комментарий от bread

гуи на го что-то не пишут совсем.

Там такая же проблема как и в расте, нет наследования. а люди почему-то не умеют писать GUI без него.

pftBest ★★★★
()
Ответ на: комментарий от bread

Где-то там подвох, например паузы чаще

До тех пор пока несколько пауз не слились в одну проблем не будет

гуи на го что-то не пишут совсем.

qt, gtk биндинги есть

NextGenenration ★★
()
Ответ на: комментарий от pftBest

нет наследования. а люди почему-то не умеют писать GUI без него.

покажите наследование в motif? в tk? в xaw?

anonymous
()
Ответ на: комментарий от NextGenenration

В java тормозят

1) GC

2) Лишние уровни косвенности вызовов

3) Много лишних копирований кусков памяти ради безопасности на уровне API

4) Программисты, любящие сказки про «преждевременная оптимизация - корень всех зол»

Эффекты проявляются по-разному, но в целом, можно всё сделать достаточно нетормозящим, если вкинуть немножко мозгов и много человеко-часов.

А отрисовка окошек в AWT-based программах тормозит. Потому что сделана пионЭрами, которые мечтали делать всё в JVM (= user space).

dzidzitop ★★
()
Последнее исправление: dzidzitop (всего исправлений: 1)
Ответ на: комментарий от NextGenenration

сделаю, скажу. это немного сложнее, чем кукарекать про то, как «мы порвем с++» и раз за разом с 2005го года обсираться. ваша братия ведь не первый год с++ «уничтожает».

ckotinko ☆☆☆
()
Ответ на: комментарий от NextGenenration

Когда-то читал про такой язык как Cyclone. В том что он не взлетел виноваты именно те кто берут только кресты/си и не хотят брать ничего нового

Нее, это тоже ерунда. Каким бы замечательным не был язык, если (например) единственная реализация компилятора в половине случаев падает, то надо иметь очень веские основания чтобы с таким языком связываться.

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

Ну а Cyclone, насколько я знаю, был скорее исследовательским проектом.

DarkEld3r ★★★★★
()
Ответ на: комментарий от umren

ну да, именно поэтому гугл док так сильно сливал мс оффис и они побежали свой гуглодок сделать ака офис365?

Это, в первую очередь, желание перевести клиентов на подписку.

DarkEld3r ★★★★★
()
Ответ на: комментарий от eao197

Ну и да, покажите что-нибудь получше в языке без GC.

Ну в Swift (ARC не GC) можно map (и т.п.) выстроить в цепочку. А с transform так не получится. Хотя вот продвигают в стандарт такое чудо https://github.com/ericniebler/range-v3 (вероятно в C++20).

anonymous
()
Ответ на: комментарий от eao197

Я, кстати, могу предложить вариант. Напишите браузер на MLTon, будет быстрее плюсов и память не потечёт.

Vudod ★★★★★
()
Ответ на: комментарий от Vudod

Вариант интересный. А к этому варианту вы могли бы придумать объяснение, почему еще никто так не сделал?

Ну этот вопрос, имхо, гораздо проще, чем вопросы по поводу вашей уверенности в «будет быстрее плюсов» и «память не потечёт».

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Правильный ответ на этот вопрос: «никто не собрался сделать». Я вижу целый ворох объективных проблем от неразвитости инфраструктуры и отсутствия библиотек до высокого требования к специалистам-разработчикам. Но для проекта такого уровня, как современный браузер, если кто-то решит сделать новый, это всё преодолимо. Просто пока никому не нужно.

Vudod ★★★★★
()
Ответ на: комментарий от Vudod

Правильный ответ на этот вопрос: «никто не собрался сделать».

Мне вот интересно: неужели вы думаете, что в современных условиях при старте нового проекта (особенно важного и сложного), никто не проводит никаких прикидок на тему выбора подходящего инструмента? Люди типа просто решают: «Ну вот мы стартуем браузер, который станет одним из наших флагманов на ближайшие несколько лет. Поскольку мы сами старые C++ники, то ничего другого больше искать не будем». Так?

Не, я понимаю, что хипстеры в стартапах могут начать пилить что-то на Node.js или Go просто потому, что ничего другого в принципе не видели. Но когда большая корпорация собирается вложить десятки миллионов долларов в новый продукт...

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Когда решение принимают боссы большой корпорации, они всегда будут копировать уже существующий успешный опыт --- это правило бизнеса. Просто для успеха у них должно быть ещё больше денег, тогда конкурент будет задавлен. Технологии они не умеют оценивать, т.к. неграмотны и доверяют своему бизнес чутью однозначно больше, чем любой экспертизе и квалифицированному мнению программистов и инженеров, а тем более учёных. Вспомните Андроид, он был куплен Гуглом уже когда был практически готов и было совершенно ясно, что это успешный проект. Движок Хрома был переделкою KHTML, никто с нуля его в Гугле не проектировал. А это ведь две их самые знаменитые поделки. Т.е. выбор средства разработки для этих успешных проектов был сделан не в Гугле, а малыми группами инициативных разработчиков.

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

Vudod ★★★★★
()
Последнее исправление: Vudod (всего исправлений: 1)
Ответ на: комментарий от Vudod

Когда решение принимают боссы большой корпорации, они всегда будут копировать уже существующий успешный опыт - это правило бизнеса.

Ёптыть, когда программисты начинают рассказывать свое видение того, как бизнесмены принимают решения, то это уже просто туши свет.

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

Во-первых, вы сами себе противоречите. Приводите пример того, как технические решения принимают отнюдь не «боссы». Хотя раньше говорили о другом. И если вы думаете, что Jane Street — это такое счастливое исключение, то вы не правы. Например, в Morgan Stanley (???) активно используют Haskell. В WhatsUp — Erlang. В Sociomantic — D. В LinkedIn — Scala. За примерами, когда технологический стек выбирают вменяемые профи, которые несут ответственность за реализацию принятых бизнесом решений, далеко ходить не нужно.

Во-вторых, с чего вы взяли, что использование OCaml в Jane Street — это финансово успешный проект?

UPD. Возможно, на счет Morgan Stanley я не прав и подзабыл. Пару лет назад была новость что какой-то крупный банк целую платформу для себя на Haskell написал. Но что это за банк сейчас не вспомню.

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от Xroft

А публикация где-то планируется? Хотя бы на Хабре.

а я тут при чём? статья не моя. Кстати, кто-то этот перевод уже перепечатывал

glebiao
()
Ответ на: комментарий от Vudod

Движок Хрома был переделкою KHTML, никто с нуля его в Гугле не проектировал.

Насколько я знаю, хром использовал webkit, который вообще-то принадлежит Apple, и от KHTML они отпочковались в далёком 2001-м.

А причина использования C++ довольно проста: на тот момент, да и сейчас, любой крупный продукт с жёсткими требованиями к производительности можно писать только на C++. Альтернатив нет.

Но вы продолжайте верить в боссов-дураков.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

А причина использования C++ довольно проста: на тот момент, да и сейчас, любой крупный продукт с жёсткими требованиями к производительности можно писать только на C++. Альтернатив нет.

Напоминает лозунги Чубайса и Гайдара: когда нужно переводить экономику на конкурентные рельсы, альтернатив шоковой терапии нет. Сталин: когда нужно проводить в стране индустриализацию, альтернатив ГУЛАГу нет. Вы себя в зеркало видели?

Ваш же товарищ выше написал, как во многих успешных проектах используется совсем не C++. Фотошоп версии 1 был написан на Паскале. И сейчас его никто не мешает использовать. Будут и плюсы и минусы. Есть Ада, сложный, но весьма годный язык, избавленный от многих проблем крестов и по уровню абстракции не уступающий им, притом компилируемый оптимизирующим компиляторов в машинный код и имеющий гораздо более высокую надёжность. Есть компилируемые языки с ГЦ и они, внимание, во многих ресурсоёмких задачах не хуже, тот же D. Если нужно писать для космических кораблей и жёсткого реального времени, а Ада не устраивает по идеологическим соображениям, есть Модула2. Да, она не столь продвинута, модна и молодёжна, но Роскосмос её активно использует и ненарадуется на свои Прогрессы, которые в отличие от американских Шатлов летают по сей день. Отличная замена для Си с классами, т.е. для ранней версии плюсов. Есть MLton --- компилятор ML, имеющий очень высокую производительность и высокую надёжность. Его производительность на больших проектах существенно выше плюсов, притом уровень абстракций там не меньше. Да, там выше требования к программисту и нужно по долгу ждать, пока проект соберётся, ну так и кресты с их макросами не идеал скорости разработки. Есть OCaml, не самый лучший выбор для веба, зато вон в соседней ветке приведён очередной пример сложной алгоритмически софтины для дехасемблирования, написанной на Окамле. Для физиков, математиков есть Фортран, во многих отношениях гораздо более приятный язык.

Но у вас по-прежнему нет выбора. Я не говорю, что во всех случаях нужно избегать Си++. Умеете, предпочитаете, ради бога. Но вещать, что выбора нет и все должны страдать, записываясь в пророки, просто идиотизм, вызванный ложным чувством илитизма и высокомерием.

Vudod ★★★★★
()
Ответ на: комментарий от Vudod

Божечки... Сталин-то тут при чём?

Если нужно писать для космических кораблей

Куда вас понесло?.. Разговор про браузеры и другой тяжелый «настольный» софт.

Есть MLton --- компилятор ML, имеющий очень высокую производительность и высокую надёжность.
Его производительность на больших проектах существенно выше плюсов, притом уровень абстракций там не меньше.

А какие-либо пруфы вы предоставить можете? Всё что я смог найти, так это то, что этот mlton пишут два человека уже лет 10, и язык всё ещё в глубокой альфе. Никто, в здравом смысле, его использовать не будет.

зато вон в соседней ветке приведён очередной пример сложной алгоритмически софтины для дехасемблирования, написанной на Окамле

Если я начну приводить примеры сложных софтин на C++, то мы до завтра не управимся.

во многих отношениях гораздо более приятный язык
фортан

Тут уже нужно всерьез задуматься о вашем психическом здоровье.

Да, C++ - не подарок, но и вменяемых альтернатив нет.

RazrFalcon ★★★★★
()
Ответ на: комментарий от Vudod

Да, она не столь продвинута, модна и молодёжна, но Роскосмос её активно использует и ненарадуется на свои Прогрессы, которые в отличие от американских Шатлов летают по сей день.

«Смешались в кучу кони-люди...» В случае с Прогрессами и Шатлами все дело, конечно же, в использовании Modula-2. И двух мнений быть не может.

Отличная замена для Си с классами, т.е. для ранней версии плюсов.

Это какой версии плюсов Modula-2 является хорошей заменой? Той, что была только у Страуструпа в 1983-ом году, или даже раньше?

Есть MLton --- компилятор ML, имеющий очень высокую производительность и высокую надёжность. Его производительность на больших проектах существенно выше плюсов, притом уровень абстракций там не меньше.

И сколько этих самых проектов? Где они в дикой природе?

Вы блин, до сих пор не можете взглянуть правде в глаза и откровенно ответить самому себе: сам по себе язык мало где важен и мало где все упирается именно в язык. Гораздо чаще все решает инфраструктура и прочие вещи, которые уже есть вокруг языка, включая рынок рабочей силы.

И вот где это все для OCaml, Modula-2 или MLton?

Для C++ есть, для Java есть. Для C# и VisualBasic на Windows есть. А для экзотики — нет.

Отдельные коллективы могут позволить себе создавать целую инфраструктуру вокруг языка (как Ericsson для Erlang-а, JaneStreet и Inria для OCaml, Sociomantic для D). Только вот никто не говорит, во что им это обходится. А обходится это сильно недешево. Поэтому очень многие разработчики ПО предпочитают брать готовое, а не создавать собственные велосипеды.

И поэтому, кстати говоря, хорошо взлетают те, у кого большой денежный мешок за спиной, на средства которого можно эту самую инфраструктуру создавать (см. примеры Java, C# и Go, хотя и с Ada и протекционизмом вокруг нее была похожая ситуация).

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Вопрос звучал так: если есть жёсткие требования к производительности, альтернатив Си++ нет. Сами же говорите, что есть, только деньги нужно вложить. Как в своё время вложили в C#, вокруг которого не было ровным счётом ничего, или Go. Теперь уже есть.

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

Может быть, и вовсе не нужно новый браузер писать, достаточно существующих. Но если писать, как Мозилла, то на другом языке. Возьмёте ли что-то уже существующее и построите инфраструктуру, либо сделаете с нуля, как сделали Ржавчину, --- вопрос отдельный. Взлетит ли Servo, неизвестно, но сам по себе подход разумный. Переписывать всё с нуля на Си++XY нет никакого смысла.

Vudod ★★★★★
()
Ответ на: комментарий от Vudod

Сами же говорите, что есть, только деньги нужно вложить.

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

Как в своё время вложили в C#, вокруг которого не было ровным счётом ничего

MS не стала бы вкладывать деньги в C#, если бы Sun ей в свое время не перекрыла кислород с самостоятельным развитием Java под Windows. А т.к. Java создавала совершенно новую нишу, то MS не могла остаться в стороне и не попытаться откусить от этой ниши.

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

Вы бы это, с небес на землю спустились бы. Мы здесь таки более-менее приземленные вещи обсуждаем, а не ваши филосовские взгляды на разработку ПО.

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

Я сам в свое время перешел с Паскаля на C++. Но не потому, что Паскаль был медленнее, а потому, что Паскаль не позволял делать собственные удобные абстракции под задачу. А C++ — позволял. И, что еще более важно, C++ позволял опуститься на самый низкий уровень там, где производительности не хватало (причем это можно было спрятать за высокоуровневыми и крайне дешевыми абстракциями).

Так что альтернатив нет (а зачастую их реально нет) не потому, что Паскаль чуть медленнее.

Переписывать всё с нуля на Си++XY нет никакого смысла.

Если у вас уже есть работающий код на C++, то его переписывание (точнее модернизация) на C++11/14/17 может иметь гораздо больше смысла, чем переписывание на любом другом языке. Даже если у вас какой-то древний (или не очень) проект на другом языке, который вам по тем или иным причинам нужно и переписать, и получить высокую производительность, то использование современного C++ так же может иметь больше смысла, чем выбор какого-нибудь OCaml-а или MTton-а. Вот, например.

Другое дело, что в каждом конкретном случае нужно взвешивать плюсы и минусы, а не рубить с плеча «С++ старое говно и должен умереть». Поскольку на C++ можно писать сильно по разному. И типобезопасность некоторых подходов может не сильно уступать каким-нибудь OCaml-ам, но практически ничего не стоить в run-time.

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от Vudod

жёсткие требования к производительности
C#
Go

/0

писать новый браузер на Си++ нет никакого смысла, т.к. уже есть несколько и лучше не выйдет.

У вас есть какое-то обоснование данному тезису? Или тараканы в голове нашептали?

И напишут самодельный аллокатор памяти.

Как что-то плохое.

Все ваши страхи перед C++, типа адресной арифметики, есть и в Rust, который использует мозила. Они там сильнее огорожены, но никуда не пропали. И это при том, что «обратной совместимости» с Си, на которую вы тут ссылаетесь, у Rust нет.

А потом будут расхлёбывать и рассказывать, что альтернативы не было.

Приведите примеры альтернатив.

RazrFalcon ★★★★★
()
Ответ на: комментарий от Vudod

В силу дизайна языка и привычек разработчиков на нём, которые смешают в коде все версии Си++ с их недостатками

Зависит от разработчиков и культуры разработки. У нас, например, после перехода на С++11, был проделан большой объем работы по обновлению старого кода, а для нового есть стандартный выписанный в доке стиль, которого все придерживаются. Скоро, вероятно, тоже самое для С++17 сделаем.

anonymous
()
Ответ на: комментарий от RazrFalcon

сейчас, любой крупный продукт с жёсткими требованиями к производительности можно писать только на C++. Альтернатив нет.

C? Rust?

umren ★★★★★
() автор топика
Ответ на: комментарий от umren

C?

Каков был самый большой проект на C, в котором вам довелось серьезно поучаствовать? Хотя бы его объем?

eao197 ★★★★★
()
Ответ на: комментарий от umren

C? Rust?

C - возможно, причем почему бы и не в связке с С++. А Rust маловероятно, т.к. если опытных сишников и сиплюсников найти не проблема, то хороших разработчиков на Rust даже не известно как отбирать. Особенно, если в качестве единственного крупного проекта есть только кривой исследовательский servo.

anonymous
()
Ответ на: комментарий от anonymous

Кому нужны ваши цепочки (из проксей), которые 1) невозможно дебажить 2) не имеют нормально оцениваемой производительности?

dzidzitop ★★
()
Ответ на: комментарий от Vudod

Это где браузеры на C++? Те, в которых всё выполняется на жабаскрипте внутри - от рендеринга страниц, до показа менюшек?

dzidzitop ★★
()
Ответ на: комментарий от dzidzitop

всё выполняется на жабаскрипте внутри - от рендеринга страниц

Cool story, bro.

anonymous
()
Ответ на: комментарий от dzidzitop

Вот граждане вокруг говорят, что все браузеры написаны на Си++, что так было и будет всегда, и альтернативы нет. Я сам, честно говоря, полагаю, что там только движок на Си++, а большую часть времени они исполняют тот самый жабаскрипт код и от него-то и тормозят. А на стороне сервера работают PHP, Python, Ruby и прочие. Но я не специалист в браузерописании. Судя по их комментариям, для них это жизненно значимая и актуальная задача. В конце концов, Мозилла решила сделать целый новый язык без ГЦ ради браузерного движка, видимо, там есть-таки, что переписывать с Си++.

Vudod ★★★★★
()
Ответ на: комментарий от Vudod

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

Как бы граждане говорят несколько другое. А вот почему вы не понимаете — это отдельный вопрос.

eao197 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.