Хочу C++ без C++

Если писать с нуля транслятор Python (СТ) в код на C (не машинный, не llvm), какие там основные проблемы будут?

Уже написан: http://nuitka.net/

Но вообще-то сила Си++ - в шаблонах и вот этом всём.

https://habrahabr.ru/post/276895/

Qt 5 - лучший C++ без C++, рекомендовано лучшими собаководами

Если писать с нуля транслятор Python (СТ) в код на C (не машинный, не llvm)

А что скажешь о Vala?

Уже написан: http://nuitka.net/

Настолько я помню, это поделие еле концы с концами сводит, проигрывая даже CPython'у.

Настолько я помню, это поделие еле концы с концами сводит

«Едва сводить концы с концами» означает «быть бедным, нуждаться». Ты уверен, что хотел сказать именно это?

проигрывая даже CPython'у.

По скорости оно выигрывает у CPython. Но, естественно, при сохранении семантики Python тупой трансляцией в Си большого выигрыша не добиться.

А что скажешь о Vala?

Это нужно исследовать, спасибо

Слушай Александреску https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-...

Ты уверен, что хотел сказать именно это?

Именно это

О, да ты еще и путаешь CPython c Cython. Пиши на Vala.

Нет, не путаю, присмотрись внимательно к первому результату

Не вижу, какой тест Nuitka проиграл CPython.

Хотелось бы, что-то типа Python, но который не требует интерпретатора, как Cython, для своей работы.

Ну так возьми:
https://github.com/cython/cython/wiki/EmbeddingCython

http://i.imgur.com/HbhJQdW.jpg

Спасибо, не знал, буду пробовать

Nim baby http://nim-lang.org/

Go уже советовали?

Вот это уже интересно

Пока слабоват

Rust уже советовали?

Пиши на vala

PS

Тебе не C++ нужен, а C с классами, как я погляжу.

Именно

Безплюсового старшего брата сразу отметаем. Интерпретируемые/JIT-языки тоже отметаем. Языки типа D, в которых размер хелловорда около мегабайта отметаем так же.

Ты хоть расскажи по какой причине отметаешь каждый из трёх, чтобы не гадать что тебе нужно. Дай список конкретных требований. «хелловорлд меньше мегабайта» - это не конкретное. «Хелловорлд чтобы влез в мой спаянный на коленках контроллер с памятью 64кб» - достаточно конкретное.

В недавнем треде было установлено, что вместо Vala надо писать на Swift :)

Посмотри на Nim.

ПС: Ты Упорот!

По причине тормознутости и усложненности языка. На питоне делается быстрее, на плюсах работает быстрее. Нужно чтобы было все вместе. Разумеется, чем-то придется пожертвовать, но я сомневаюсь, что эта жертва будет настолько большой, чтобы оставлять все как есть.
Размер бинарника хелловорда в один метр показывает несерьезность подхода.

Qt /thread

Размер бинарника хелловорда в один метр показывает несерьезность подхода.

Ololo

У OCaml компилятор выдаёт маленькие быстрые бинарники, но у него проблема с параллельностью. Для Haskell GHC генерит быстрый код, но RTS у него жирен, и бинарник меньше мегабайта размером ты вряд-ли получишь. Есть ещё Rust, но от его синтаксиса хочется вырвать себе глаза, вскрыть вены на жопе и умереть, а так он вроде как неплох.

Да, ты таки реально упоротый. Школоло небось?

Самое серьезное это когда на ассемблере все

Все упомянутые языки(кроме Rust) обладают одним неприятным свойством - в них неотключаемый GC. Неотключаемый GC - плохо. Человек способен более грамотно распоряжаться памятью, при желании человек может даже свой специальный GC сделать в тех же плюсах (в фаерфоксе например есть GC) который будет эффективней, чем некий GC общего назначения, впиленный разрабами языка в рантайм

Неотключаемый GC - плохо.

Почему?

Человек способен более грамотно распоряжаться памятью

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

Все упомянутые языки(кроме Rust) обладают одним неприятным свойством - в них неотключаемый GC. Неотключаемый GC - плохо. Человек способен более грамотно распоряжаться памятью, при желании человек может даже свой специальный GC сделать в тех же плюсах (в фаерфоксе например есть GC) который будет эффективней, чем некий GC общего назначения, впиленный разрабами языка в рантайм

Выигрыш обычно минимален, а вот ошибок из-за ручного управления памятью куча.

В Nim GC отключается, но его сишный выхлоп пока меня немного пугает

Да, способен.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27663
http://govnokod.ru/19395
кто считает что компиляторы прям такие крутые что человеку их не переплюнуть - не читали выхлопы компиляторов

Неотключаемый GC - плохо.

Почему?

Потому что неэффективно, перерасход памяти, фризы при периодической сборке мусора, проблемы с реалтаймовостью

Потому что неэффективно

Пруф.

перерасход памяти

Насколько большой?

фризы при периодической сборке мусора

Хватит насиловать Java.

проблемы с реалтаймовостью

Если мы про Linux - он сам по себе не реалтаймовый. Решит у тебя кто-то заняться I/O по-взрослому и окажешься ты в полной заднице.

Чо ты писать-то собрался?

Потому что неэффективно

Пруф.

Сравнивать эффективность ручного управления памятью из Си(malloc/free) с GC из какого языка? http://lambda-the-ultimate.org/node/2552 вот статейка

перерасход памяти

Насколько большой?

https://benchmarksgame.alioth.debian.org/u64q/java.html смотрим на потребление памяти.

фризы при периодической сборке мусора

Хватит насиловать Java.

Проявляется не только в Java. Пруф http://rsdn.ru/forum/dotnet/4664675.hot

проблемы с реалтаймовостью

Если мы про Linux - он сам по себе не реалтаймовый.

Вроде никто четко не обозначил, в какой среде (Windows, Linux, QNX, VxWorks или что там еще) рассматриваюся проблемы, связанные с GC.

И в чём проблема поправить пару багов в компиляторе, чтобы он начал выдавать более эффективный код?

Я уже не говорю о том, что затраты на железо практически всегда ниже затрат на разработку софта.

https://benchmarksgame.alioth.debian.org/u64q/java.html смотрим на потребление памяти.

Сравни вот с этим: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ocaml&lang...

Все статьи ведут на обсуждения Java и dotnet. Да, GC в Java действительно отвратителен.

Brainfuck /thread

Deathstalker спасибо за ссылку на хабр. На фоне местного русификатора Лиспа радует что есть люди, которые сами что-то пишут.

Там замеряется пиковое потребление. В Си можно пробовать соптимизировать потребление ОЗУ, например взять этот код https://benchmarksgame.alioth.debian.org/u64q/program.php?test=mandelbrot&amp...

OCaml
	13.78 	5,492 	710 	54.89 	100% 100% 100% 100%
C gcc
	5.92 	32,464 	694 	22.81 	95% 100% 96% 95% 

Там есть всего 1 malloc

uint8_t * const pixels=malloc(image_Width_And_Height*
     image_Width_And_Height/8);

Qt 5 - лучший C++ без C++

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

А vala - вообще маргинальное недо-поделие...

Размер бинарника хелловорда в один метр показывает несерьезность подхода.

Смешно...

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

Круто. Как это относится к управлению памятью, и почему «писать файл кусками» нельзя в языках с GC?

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

Можно посравнивать какие-нибудь реализации деревьев, двусвязных списков, и прочего такого

Почему?

Потому что риалтайм писать нельзя.

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