static JNIEXPORT void JNICALL some_jni_method(JNIEnv *env

1. покажи мне этот вызов в своём примере.

2. «у нас в jni» где-то раньше написано так:

JNIEnv *jniEnv;
JavaVM *javaVM;
long flag;
flag = JNI_CreateJavaVM(&javaVM, (void**)&jniEnv,
   &vm_args);

3. так что к врачу — это тебе.

4. анонимуса отключить можно, но не нужно.

ЗЫ. Можно на LOR-е сделать так, чтобы анонимные комментарии были не видны вообще?

Да. Надо вкладку закрыть и никогда больше не открывать.

Ну как бы да. Для молодого раста есть, а для стареньких плюсов - нет.

Я уже как-то приводил пример с отсутствием либ для работы с XML и архивами в C++.

Для тех вещей, которыми оперирует браузер, того же FFmpeg'а почему-то вполне оказалось достаточно.

Когда аппаратное ускорение видео в этот браузер завезут?

Более того, с переходом на FFmpeg пропали дурацкие баги GStreamer'а аля: невозможно перемотать видео

В пре релизной ветке 0.10?

Например, у меня в системе одна версия FFmpeg

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

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

Ну вон, товарищи пишут, что в STLPort не смогли разобраться и поддерживать. Также и с метагалиматьёй: написано нормально, с документацией и кучей тестового покрытия - можно поддерживать. Написано левой ногой, as is - умрёт само.

А ты много «язычков» разработал? Трудоемкость представляешь?

eDSL на общелиспе очень просто сделать.

eDSL на общелиспе очень просто сделать.

Возможно, я не пробовал. Сильно подозреваю, что «очень просто» сделать синтаксическую часть (если оставаться в прокурстовом ложе лисп-подобного синтаксиса). Но я сейчас смотрю за Rust - там тоже есть мощная макросистема и уже пошла плеяда «eDSL». Что-то меня это не очень прикалывает - помимо базового языка, Rust, нужно изучать еще и доморощенные «eDSL». ХЗ, окупаются ли они в любом смысле.

Возможно, я не пробовал. Сильно подозреваю, что «очень просто» сделать синтаксическую часть (если оставаться в прокурстовом ложе лисп-подобного синтаксиса). Но я сейчас смотрю за Rust - там тоже есть мощная макросистема и уже пошла плеяда «eDSL». Что-то меня это не очень прикалывает - помимо базового языка, Rust, нужно изучать еще и доморощенные «eDSL». ХЗ, окупаются ли они в любом смысле.

Смотри на eDSL, как на API библиотеки. Помимо базового языка всё равно ведь с левыми библиотеками знакомиться надо?

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

Так возьми и выкинь неинтересные для себя ветки. Кто тебе мешает?

Удали операционную систему со своего компьютера и выйди в окно.

Может хоть попытаешься обосновать нужность проектов из портянок на 2М строк? Эти мегакомбайны никому на голову не налезут, нуб, который придёт в контору будет только год только въезжать в суть. Не стало разработчика и нету у тебя проекта. И ядра линукс это очень даже касается, там полно таких вещей, про которые знают только 1.5 человека.

Понимаешь, надо человекочитаемый. А человекочитаемый - это просто x + y

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

Если человек решительно не может с x + y переучиться на (+ x y) или хоть x y +, то в биореакторе от него пользы может быть больше. От Лиспа излом происходит гораздо более серьёзный совсем в других местах языка, а не в простеньком, в общем-то, синтаксисе.

А человекочитаемый - это просто x + y

Не надо путать человекочитаемость и привычность. Если б в школах вместо 2 + 2 = 4 учили писать что-то типа (= (+ 2 2) 4) то тебе б x + y был нечитаемым

Ваше мнение об C++ /путях развития, .../?

Не буду оригинальным. Единственный правильный путь - делать другой нормальный язык без кривых костылей, а C++ закапывать. Пусть доживает в легаси-болоте как какой-нибудь фортран или кобол

Смотри на eDSL, как на API библиотеки. Помимо базового языка всё равно ведь с левыми библиотеками знакомиться надо?

«Проект языка - это проект библиотеки и наоборот», я знаю. Но API библиотеки как-то спрятан за eDSL. В общем, я не уверен, что выгоды от eDSL окупают его стоимость. Может, я и неправ.

Там всё сложно %).
Вот так, например, выглядит обёртка вокруг GtkButton: button.ccg, button.hg.

Мне, как человеку, который никогда не работал с Gtk, сложно понять что там к чему. Но вот этот заголовочный файл — он вручную написан? И макросы _WRAP_METHOD вручную проставлены?

Ну как бы да. Для молодого раста есть, а для стареньких плюсов - нет.

Ну так Rust-оманам приходится к чему-то биндится, ибо своих GUI все никак. А в C++ Gtk мало кому вообще всрался, т.к. всегда хватало родных плюсовых GUI. Начиная от древних MFC, Qt, wxWidgets, FLTK и FOXToolkit, заканчивая модными и молодежными ImGUI и Nano.

В таких условиях сам факт существования биндинга к Gtk — это вообще удивительно.

Я уже как-то приводил пример с отсутствием либ для работы с XML

Ну вот совсем нет, даже взгляд бросить некуда. Верю вам сразу на все 146%.

В таких условиях сам факт существования биндинга к Gtk — это вообще удивительно.

Если правильно понял, его пилят сами разработчики GTK+.

Если человек решительно не может с x + y переучиться на (+ x y) или хоть x y +, то в биореакторе от него пользы может быть больше.

Мой ЧСВ-метр сломался. Вам мозг не жмет?

Не надо путать человекочитаемость и привычность

Это одно и то же.

Если б в школах вместо [...]

Если бы.

Ну вон, товарищи пишут, что в STLPort не смогли разобраться и поддерживать.

Там не это было написано. А вот это:

При переходе на стандарт C++14 мы рассматривали такие варианты:

1. Поднимать модифицированный нами STLPort на стандарт C++14. Опция очень непростая, т.к. поддержка STLPort была прекращена в 2010 году, и поднимать весь его код нам пришлось бы самостоятельно.

...

Первый вариант был отвергнут сразу из-за слишком большого объема работ.

Между «не смогли разобраться» и «не стали делать из-за большого объема работ» очень большая разница. Но если человек привык писать сложение через задницу, то может он и на другие вещи смотрит через задницу.

Лисп умеет быть без скобок?

Такой лисп называется FORTH

Вам не надо - никому не надо. Всё ясно.

Это одно и то же.

Нет. Текст на китайском я не прочитаю т.к. китайского я не знаю (мне непривычно). Но текст на китайском вполне себе человекочитаем.

А если текст на русском сделать как картинку формата JPEG, перевести в base64, потом напечатать на принтере и дать мне, то я нихрена не пойму, хоть я отлично знаю русский. Это пример «нечеловекочитаемости»

нет

bash

#!/bin/bash

your_code > ./exec; sed -i ./exec ... ; something something; ./exec

Ну я как бы пользовался тремя разными XML-парсерами на плюсах. Так что лишь вы с вашей ахриненной и неоднократно подтвержденной компетенцией в C++ способны убедить меня в отсутствии оных для C++. Вам верю безоговорочно.

Стыд и срам, но на хабре более адекватные комментарии у этой статьи, чем здесь.

Ну ты сравнил, информационно-развлекательный ресурс и напыщенно-технический

Список в студию.

Xerces, TinyXML, PocoXML. Еще под ногами в свое время болтался XML из Qt, но не помню, чтобы его когда-то где-то приходилось использовать.

Что нужно в C++ по моему мнению:
7. Нормальная работа с юникодом.

а что не так с юникодом?

Конечно каждый имеет право высказать свое мнение.
Только вот не понятна ценность мнения тех кто в обсуждаемом вопросе мало что понимает.

Одни знакомые лица.

Xerces

Легаси + Си с классами.

TinyXML

Примитивный. Не умеет DTD. «It does not rely on exceptions, RTTI, or the STL.». Опять Си с классами.

PocoXML

Фреймворк.

Еще под ногами в свое время болтался XML из Qt

Тоже не шибко хорош. Медленный.

Вы бы ещё libxml2 вспомнили, который все и используют.

Ничего другого ждать и не приходилось.

Не надо путать человекочитаемость и привычность

Это одно и то же.

Нет.

Да.

Текст на китайском я не прочитаю т.к. китайского я не знаю (мне непривычно). Но текст на китайском вполне себе человекочитаем.

Нет. Текст на китайском читаем специально обученным человеком. Так же, как текст на Лиспе читаем специально обученным человеком.

А если текст на русском сделать как картинку формата JPEG, перевести в base64, потом напечатать на принтере и дать мне, то я нихрена не пойму

Потому что тебя не научили понимать JPEG в base64. А научили бы - ты бы понял.

Потому что тебя не научили понимать JPEG в base64. А научили бы - ты бы понял.

Не факт что этому можно научить. Вполне может быть, что это за пределами возможностей человека, и решить это можно разве что вживлением в мозг какого-нибудь чипа, который бы, распознавал текст из зрительного нерва, декодировал base64, потом декодировал jpeg и выводил изображение в мозг. Или ГМО-человека сделать, который бы мозгами это всё мог сделать, своими мясными человеческими мозгами.

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

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

Ну, короче, у glibmm есть свой препроцессор.

Так вообще любой текст читаем только специально обученным человеком. Даже машкод. Так и запишем: нечеловекочитаемых языков нет, потому что человека можно обучить читать любой язык.

Между «не смогли разобраться» и «не стали делать из-за большого объема работ» очень большая разница. Но если человек привык писать сложение через задницу, то может он и на другие вещи смотрит через задницу.

У меня просто очень широкий кругозор, от RTL до Common Lisp. Другим порядком операции и операндов меня не смутишь.

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

Мой ЧСВ-метр сломался. Вам мозг не жмет?

Принимаю, как должное, что человек к новому и более логичному синтаксису привыкает быстро и без особых проблем. Это не суперспособность какая-то. Если кто-то из программистской братии утверждает, что x + y кардинально лучше (+ x y) или x y + - это вызывает вопросы к такой персоне. А уж тем более, когда при этом до банальных клише скатывается...

чему ваша история ещё одно подтверждение.

Моя история? Это вы о чем?

А уж тем более, когда при этом до банальных клише скатывается...

Знаете, многоопытный вы наш, когда-то давно, в бытность студентом второго курса, довелось мне помогать одному дипломнику сделать расчетную программу. Формула, по которой итерационно велось вычисление, была настолько объемная, что Turbo Pascal 5.0 ее отказывался компилировать вообще. Вот прямо практически так и говорил: слишком большое выражение, я не справляюсь.

Самое важное в контексте вашего выпендрежа про (+ x y) было то, что формула была вполне себе обозримая и ее несложно было разделить на подвыражения, с которыми Turbo Pascal 5.0 уже мог справится. Это потому, что она была в нормальной, математической нотации.

Вы, видимо, никогда дел с вещами сложнее (+ x y) не имели. Поэтому вам кажется, что вы свои мозги изнасиловали и стали воспринимать (+ x y) как акуительное достижение. Такое, которым нужно обязательно гордится и позволять себе пассажи про биореактор.

Самое важное в контексте вашего выпендрежа про (+ x y) было то, что формула была вполне себе обозримая и ее несложно было разделить на подвыражения, с которыми Turbo Pascal 5.0 уже мог справится. Это потому, что она была в нормальной, математической нотации.

Кстати, как раз нормальную математическую нотацию типа $\frac{abc}{4x}$ проще переписывать в лисповом стиле (/ (* a b c) (* 4 x)), а не (a * b * c) / (4 * x), особенно когда формула на 8-9 строк раскидывается (в лиспе у неё нормально видна структура), а дроби в строку, особенно когда в числителе и знаменателе есть свои дроби, почти нечитаемы.

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

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

Самое важное в контексте вашего выпендрежа про (+ x y) было то, что формула была вполне себе обозримая и ее несложно было разделить на подвыражения, с которыми Turbo Pascal 5.0 уже мог справится. Это потому, что она была в нормальной, математической нотации.

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

Вы, видимо, никогда дел с вещами сложнее (+ x y) не имели. Поэтому вам кажется, что вы свои мозги изнасиловали и стали воспринимать (+ x y) как акуительное достижение. Такое, которым нужно обязательно гордится и позволять себе пассажи про биореактор.

«Свои мозги изнасиловали»? Если органом не пользоваться, не тренировать его, он атрофируется. Таковы законы природы.

Как выше уже отметили, развесистмая мат.формула в s-expression парсится глазом проще, т.к. уже изначально структурирована в дерево вычислений.

Кем она парсится проще? Упоротые лисперы на форумах еще и не то могут рассказать. Причем такое ощущение, что вы сами в это верите.

А вот поработаете с математиками, пусть даже и теми, кто вычислительной математикой и вычислительными методами занимается, вряд ли когда-нибудь увидите в их работах s-expression. И уж тем более они не будут менять (a*b*c)/(x-z) на так милую лисперам (/ (* a b c)(- x z)).

Если органом не пользоваться, не тренировать его, он атрофируется. Таковы законы природы.

Мозгами можно пользоваться не только для того, чтобы приучать себя видеть (- x y) там, где остальным привычнее (x-y). И, что самое важное, вовсе не обязательно кичиться своими интеллектуальными достижениями. Но у лисперов же так не получается, вы же не такие как все. Вам же нужно из себя илитку состроить, а остальных в биореактор определить.

А доводилось работать с российскими компиляторами языка C++?

Нет, не припомню такого. Плотно доводилось работать с Borland-овскими, Watcom-овскими, MS-ными компиляторами, GCC и clang. На разных платформах. Менее плотно с Zortech/Symantic, Metrowerks, Sun.

А доводилось работать с российскими компиляторами языка C++? Если да, то какие впечатления?

Мне доводилось - с тем самым зуевским (или его потомком). Впечатлений особо никаких - компилятор и компилятор. Правда, мы использовали его практически в режиме Си.

Ну, я немного тоже использовал Borland, совсем чуточку Watcom и MS в образовательных целях, а потом довольно плотно и много на двух работах имел дело с GCC и еще пару раз запускал clang, чтобы понять, чего же мне хотел сказать GCC :) Еще digital mars у меня где-то валялся.

А тут интерес именно к российским. Эх, так просто не пощупать их, видимо.