[16:11:45] <valexey'> Замечательно. Новые недокументированные возможности языка и ББ: http://forum.oberoncore.ru/viewtopic.php?f=2&t=2835
[16:11:53] <valexey'> внизу.
[16:56:32] <vlad2> Угу. СИСТЕМ навсегда.
[16:57:36] <vlad2> Я тут баг один ловил...
[16:57:39] <vlad2> 7 часов...
[16:57:47] <vlad2> Потому долго думал...
[16:57:51] <vlad2> потом
[16:59:20] <vlad2> самое главное в современном ЯП в любом применении (от контроллеров до интерпрайза) - это диагностика.
[16:59:52] <vlad2> Потом все остальное - функциональщина, императивщина, безопасность.
[17:00:58] <vlad2> Сам баг был - банальный UB. Усугубился он тем, что это проявлялось только на PowerPC.
[17:01:19] <vlad2> Но UB - фигня.
[17:02:13] <vlad2> 99% времени было потрачено на получение вменяемого отладочного билда, который бы падая показал - где он, собственно, упал.
[17:02:32] <vlad2> (причем повезло, что проблема проявлялась и на дебаговом билде)
[17:02:53] <vlad2> Впрочем "проявление только в релизе" - это тоже все из области диагностики.
[17:03:42] <vlad2> Так вот. С++ - безнадежно морально устарел по этому параметру.
[17:03:59] <vlad2> C#/Java - безусловно делают тшаг вперед.
[17:04:39] <vlad2> Оброн со своими неинициализированными переменными и ковырянием в дизассэмблере (как писал Ильин) - шаг назад.
[17:05:52] <vlad2> UB был не совсем обычный (первый раз столкнулся).
[17:06:55] <vlad2> void f(std::auto_ptr<int> p, int i);
[17:07:12] <vlad2> std::auto_ptr<int> p(new int(3));
[17:07:29] <vlad2> f(p, *p + 1); // UB
[17:09:53] <vlad2> Тут даже не порядок вычисление аргументов в чистом виде, а порядок + передача.
[17:11:09] <vlad2> На визуале - тогже работало.
[17:12:11] <valexey'> жесть
[17:12:31] <valexey'> vlad2: насколько я понимаю, в ББ с диагностикой вроде как все хорошо.
[17:12:44] <valexey'> в том числе благодаря отсутствию оптимизации как таковой
[17:32:08] <vlad2> Да, хорошо - особенно для тех лет :)
[17:32:50] <vlad2> Хотя, конечно свободное использование СИСТЕМ и неинициализированные переменные тоже могут неплохо "усугубить".
[17:34:03] <vlad2> Кроме того, там диагностика сделана довольно жетско в ущерб оптимизации (которой там просто нет).
[17:37:02] <vlad2> Кстати, пока разбирался с этим багом столкнулся с изъяном в дизайне конструкторов в C++, который раньше удавалось обходить, но в данном случае - не получилось.
[17:37:17] <vlad2> Код был примерно такой:
[17:37:25] <valexey'> ну, скажем так, в яве тоже диагностика так себе. после jit'a то, да в далвике...
[17:38:05] <vlad2> struct Base { Base(std::auto_ptr<int> p, int); }; // та самая функция f()
[17:38:35] <vlad2> struct X { X(std::auto_ptr<int>); };
[17:38:54] <vlad2> struct X : Base { X(std::auto_ptr<int>); };
[17:39:27] <vlad2> X::X(std::auto_ptr<int> p) : Base(p, *p + 1) {}
[17:39:45] <vlad2> Вопрос на засыпку: как разрулить данный UB.
[17:40:07] <vlad2> Без изменения сигнатур контсрукторов.
[17:40:27] <vlad2> Мое решение кажется мне "неизящным".
[17:40:34] <vlad2> Может ты лучше придумаешь :)
[17:40:49] <valexey'> ща, погодь. схожу в магазин и подумаю :-)
[17:42:15] <vlad2> Грубо гворя - не хватает временной переменной, куда можно снала вычислить второй аргумент.
[17:43:36] <valexey'> да я понял.
[17:44:19] <valexey'> чтобы внезапно мусор не оказался после того как p потеряет обладание :-)
[17:44:25] <vlad2> Угу.
[17:45:00] <vlad2> Там даже не мусор - там вполне определенный NULL :)
[18:38:12] <valexey'> vlad2: я не понял. у нас что, две разных структуры X - одна унаследованная от Base, а другая нет?
[18:38:24] <valexey'> или строка struct X { X(std::auto_ptr<int>); }; была ошибкой.
[18:38:25] <valexey'> ?
[18:42:21] <valexey'> и еще вопрос - что я могу менять?
[18:42:25] <valexey'> конструктор X?
[18:42:29] <valexey'> конструктор Base?
[18:42:33] <valexey'> что-то еще?
[18:52:07] <vlad2> X - одна, унаследованная, просто я наследование первый раз забыл написать.
[18:52:42] <vlad2> Сигнатуры конструкторов желательно не менять.
[18:52:56] <vlad2> Сами классы менять можно.
[18:54:59] <valexey'> а если сигнатуры поменять обратно совместимым образом?
[18:55:36] <valexey'> ну, то есть самая попоболь будет в перекомпиляции всего что от них зависило.
[18:55:55] <valexey'> но кот ручкаме менять не нужно будет
[19:04:02] <valexey'> vlad2: вот один из вариантов:
[19:04:16] <valexey'> struct Base { Base(std::auto_ptr<int> p, int) }; // та самая функция f()
struct X : Base { X(std::auto_ptr<int>, int tmp=0); };
X::X(std::auto_ptr<int> p, int tmp) : Base((tmp=*p+1, p), p.get() ? *p+1 : tmp) {}

[19:12:22] <vlad2> Хэчно, но вариант. Только там на самом деле не int, а более сложная фигня.
[19:12:56] <vlad2> И страшно что ж он там нагенерит в итоге...
[19:13:15] <valexey'> это да...
[19:13:21] <valexey'> ща будет второй вариант :-)
[19:14:00] <vlad2> В смысле я легко могу представить - что у компилятора вообще башню снесет от такой конструкции.
[19:14:19] <valexey'> думаю не снесет. они нонче и не такое умеет
[19:14:24] <valexey'> но я знаю у какого снесет :-)
[19:14:29] <valexey'> У Кейла снесет
[19:14:38] <vlad2> Кто такой?
[19:14:39] <valexey'> Впрочем, у него и просто от auto_ptr'a снесет :-)
[19:14:53] <valexey'> Ембеддед :-) для msp430 компилятор
[19:14:56] <valexey'> самый лучший
[19:14:56] <vlad2> А :)
[19:15:29] <valexey'> остальные или код генерят совсем говенный (типа gcc), либо еще хуже по фронтенду и по кодогенерации одновременно
[19:19:16] <valexey'> вариант нумбер два:
[19:19:20] <valexey'> struct Base { Base(std::auto_ptr<int>& p, int); std::auto_ptr<int> mp; int i;};
struct X : Base { X(std::auto_ptr<int>); };

Base::Base(std::auto_ptr<int>& p, int a) : mp(p), i(a) {}
X::X(std::auto_ptr<int> p) : Base(p, *p+1) {}

[19:19:44] <valexey'> mp и i введены для пущей наглядности
[19:20:19] <valexey'> да, все варианты я на компилябельность проверял
[19:20:37] <valexey'> $ g++ --version
g++ (Debian 4.4.5-8) 4.4.5
[20:25:04] <vlad2> Да, про вариант со ссылкой я тоже думал.
[20:25:10] <vlad2> Скорее всего он прокатит.
[20:25:28] <vlad2> Но против него тоже есть некоторые возражения.
[20:26:00] <vlad2> В-первых, он легко ломается первым залетевшим дятлом (да, можно поставить коммент, но тем не менее).
[20:27:52] <vlad2> Во-вторых, в слуае константной ссылки/временного орбъекта, компилятор таки имеет право чего-то там копировать (точное место в стандарте не скажу).
[20:28:22] <vlad2> Впрочем вариант с неконстантной ссылкой должен по идее гарантировать, что ничего капироваться не будет.
[20:29:11] <vlad2> Мое "неизящное", но дубово работающее рещение:
[20:29:58] <vlad2> struct Y { Y(int *p); int *p; };
[20:30:16] <vlad2> struct X : Y, Base ...
[20:31:06] <vlad2> X::X(std::auto_ptr<int> p, int i) : Y(p.get()), Base(p, *Y::p + 1) {}
[20:31:44] <vlad2> Самая большая претензия - никому ненужный мембер :)
[20:32:29] <valexey'> угу. я тоже про это думал. решил сэкономить и разместить ненужный "мембер" на стеке. так родился первый вариант :-)
[20:33:24] <vlad2> Также я подумал на тему того, что ж "можно допилить" в языке.
[20:34:13] <vlad2> Туплы, которые можно передавать как список аргументов спасли бы этот пример.
[20:35:32] <vlad2> tuple<std::auto_ptr<int>,int> helper(std::auto_ptr<int> p) { int tmp = *p + 1; return tuple(p, tmp); }
[20:35:37] <valexey'> в D это решаемо в принципе. То есть там можно написать шаблонную прослойку которая вначале вычислит все аргументы (принимая все по ссылке) и уже вычисленные значения передаст нужной функции.
[20:36:00] <vlad2> X::X(std::auto_ptr p) : Base(%heler(p)) {}
[20:36:35] <vlad2> Где значок "%" означает, что туплу надо рассматривать как список аргументов, а не как отдельный аргумент.
[20:37:21] <valexey'> тут еще мешает конечно, что в плюсах конструктор не является нормальной функцией.
[20:37:33] <valexey'> Я не помню, но по моему на конструктор нельзя получить указатель.
[20:37:37] <valexey'> или можно?
[20:38:47] <vlad2> Судя по тому, что ни разу этого не делал - нельзя :)
[20:39:07] <vlad2> Что вполне понятно :)
[20:39:24] <vlad2> Размер возможных грабель внушает страх :)
[20:40:17] <valexey'> гм. а чем это страшно?
[20:40:36] <vlad2> Вызвать конструктор для существующего объекта.
[20:40:39] <valexey'> запихать получение указателя на конструктор в SYSTEM и всего делов! :-D
[20:41:12] <vlad2> Не, нах. Специальная форма оператора new решает проблему без всяких систем.
[20:41:50] <vlad2> Да, она тоже может привести к большим граблям :)
[20:42:18] <vlad2> Но про нее обычно не знают те, кто не знает про эти грабли :)
[20:43:17] <valexey'> погоди, это ведь означает что у Оберона большие проблемы - ведь там конструктором обычно выступает обычная функция.
[20:43:31] <valexey'> А про обычные функции там знает каждый школьник.
[20:44:05] <valexey'> двойное открытие какого-нибудь ресурса в результате (скажем файла, или мьютекса) - плевое дело.
[20:46:18] <vlad2> В орбероне проблема с фугкциями-конструрами записей. О чем я неоднократно говорил. Потому что там нельзя нормально вернуть запсись - только неявно в виде аргумента. С объектами в куче там все хорошо - два раз для одного и того же объекта ты не вызовешь конструктор.
[20:47:07] <vlad2> Ресурсы - известные проблемы языков без деструкторов и их аналогов. Оберон здесь ничем особо не специяичен.
[20:49:23] <valexey'> погоди. почему не вызову? init(a); init(a); -- легко! все же размещение в памяти переменной и её инициализация должны быть разнесены (в плюсах так оно и есть). выделение памяти и получение на нее указателя - это одно. инициализация - другое.
[20:49:35] <valexey'> в обероне будет все хорошо только если слепить эти два действия воедино.
[20:56:35] <vlad2> Дык, ты привел пример для записей. Там все плохо. С хипом там все нормально: p_a := init();
[21:44:56] <valexey'> А теперь внимание вопрос - какое собачье дело инициализаторуа где именно у меня размещена структура?
[21:56:43] <vlad2> Дык!!! :) Я ж про ето говорил же ш! Возврат записей сделать - ничего не стоит. А профит реальный :)
[21:58:01] <vlad2> Сразу можно было бы сделать контроль инварианта для структур. Без потери в эффективности.
[22:27:43] <valexey'> vlad2: я вот подумал про embedded&oberon.. я хз насколько он там будет хорошо смотреться. Потому как использование динамической памяти в оной встроенке - плохой тон. сборщика мусора - тоже. а вот прямое обращение по адресам в памяти - наоборот, хороший :-)
[22:28:22] <valexey'> И если уж использовать динамическую память, то наверняка свой аллокатор нужен будет. А в Обероне NEW зашит в язык (и в компилятор). То есть с Си как-то проще в этом плане.
[22:28:38] <vlad2> Дык, таки в обероне можно что-то делать и без хипа - на записях.
[22:29:47] <valexey'> Дык это ж будет стэк. То есть все на стэке. А это тоже не шибко удобно. И ты учти, что в embedded ты должен уметь размещать в том числе и записи четко по нужным адресам.
[22:29:54] <valexey'> А не где компилятору вздумается
[22:30:52] <vlad2> Ну СИСТЕМ никто не отменял.
[22:31:23] <valexey'> Тут системом не обойдешься. У тебя и статические (глобальные) переменные должны лежать по нужным адресам.
[22:31:35] <valexey'> То есть придется расширять язык всякими прагмами или чем-то подобным.
[22:32:45] <valexey'> Либо не расширять, а, как это принято у оберонщиков, создать новый диалект языка, ни с кем не совместимый :-) Зато делающий хорошо свою работу в данной области.
[22:34:35] <valexey'> Вообще, этот embedded - страна непуганых идиотов. В смысле там по ощущениям индустрия отстала от десктоп-сервера лет на двадцать минимум. Там совершенно дикие угребищные компиляторы при этом стоящие невменяемых денег (3 килобакса за отчаянно глючащее поделие).
[22:34:49] <valexey'> Опенсурсом и не пахнет вообще никак и нигде.
[22:35:04] <valexey'> На стандарт языков кладется огромадный болт.
[22:35:24] <valexey'> И средства разработки в основном только под маздай
[22:37:07] <vlad2> Дык, надо туда оберонщиков :)
[22:37:18] <vlad2> Которые за две недели напишут компилятор :)
[22:37:27] <vlad2> Под контроллер специфичный :)
[22:38:12] <valexey'> Знаешь как там быстродействие алгоритма оцениваем? Думаешь через таймер, или какой-нибудь rtc? А вот хрен! В программе до старта измеряемой функции пишем единичку по определенному адресу, в результате микроконтроллер подает напряжение на одну из своих ног. А после отработки функции пишем туда нолик - напряжение убирается. После чего цепляемся к этой ноге осцилографом и смотрим длительность импульса :-)
[22:39:05] <valexey'> Осцилограф - лучший профилировщик!!1
[22:40:08] <valexey'> Впрочем, в качестве дебаггера тоже он же используется ;-)
[22:42:07] <valexey'> Осцилограф как интерфейс! И никакого текста ;-)
[22:45:48] <vlad2> Всяк лучше, чем светодиод :)
[22:46:33] <valexey'> светодиоды тоже задействованы :-)
[22:46:46] <valexey'> правда только тогда, когда не проводим тесты на энергопотребление
[22:47:34] <valexey'> смотришь - о, мигает как-то не так. завис чоле? тыкаешь - так оно и есть. завис, собака.
[22:48:13] <vlad2> А вот если бы вы на обероне там писали, да еще с правильными циклами... :)
[22:48:42] <valexey'> то оно просто не влезло бы в прошивку!
[22:48:44] <valexey'> :-)
[22:49:33] <valexey'> /me вспоминает как с помощью препроцессора там инлайнил "функции"
[22:49:57] <valexey'> а то вызов функции штука дорогая!
[22:50:34] <valexey'> а цикл, кстати, тоже разворачива руками. причем делал руками порядок вычисления таким, чтобы не было целочисленных переполнений.
[22:50:52] <valexey'> на заданном диапазоне входных значений.
[22:51:04] <valexey'> (плавающей точки там совсем нет)
[22:51:16] <vlad2> А модули динамически грузить не было потребности? :)
[22:52:26] <valexey'> издеваешься, да? :-)
[22:54:41] <valexey'> откровенно говоря, даже на таком жирном дивайсе как андроидопланшет, или iPhone, не возникает надобности что-то там динамически грузить и, тем более, выгружать.
[22:56:47] <valexey'> Гм. Интересно, а что так господа оберонщики молятся на РБНФ? Вон, народ им стращать пытаются. Штука то простая по сути, и не шибко мощная.
[23:06:24] <valexey'> "Автору рекомендация: идти при размышлениях об изменениях языка СНАЧАЛА со стороны компиляции (хотя бы просто РБНФ, как сказал Евгений). Только "фича", прошедшая отбор со стороны удобства реализации, может быть обдумана на тему "а нужна ли"."
[23:12:08] <vlad2> Потому что про EBNF писал сам Вирт :)
[23:12:19] <vlad2> И от нее, собственно, плясал.
[23:18:53] <valexey'> ну, Вирт же не бог. и не единственный создатель языков :-)
[23:19:17] <valexey'> по моему, с точки зрения теории грамматик много интересней работы связанные с формализацией Алгола-68
[23:19:50] <valexey'> Это дало существенно бОльший толчок этому направлению.