Планы по выпуску GTK+ версии 3

> man fudgets

Скорее гугл. Посмотрю.

> Снова мы уткнулись в субъективность.

Статистически значимая субьективность считается объективностью;)

> Так что отпускаю её в свободное плавание.

Ну, Вы ее пропагандируете. Не так чтоб успешно...;)

> Я знаю минимум 1 ассемблер, который сам вставляет команды, которых не пишет программист :)

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

> "Кроссплатформенный ассемблер" - это метафора, она не обязана быть математически точной.

Ну тогда простим метафоре, что с неё взять :)

С уважением,

Евгений

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

инъекции!

>>> То что у тебя в одном cpp файле импортируется и <list> и <map> вообще довольно показательно -> полное отсутствие инженерной культуры.

>>Фигассе понятия об инженерной культуре.

> Что проще - добавить 4-8 байтов std::string'а в хвост std::vector или аллоцировать каждый раз мелкий объект для узла list?

Ыыыыы... причем это к "импорту" list и map, и инженерной культуре? Ну и от аллокатора зависит.

>>>ставим набор инструкций от 386 и получаем "ассемблер"? или я не прав?

А если поставить 686 то уже типа кранты всему ? 8) С уже перестал быть "асмом" ? 8) А если это не х86-like архитектура ? 8)

Всё зависит от степени "претензий" с понятию асм. Если совсем их не иметь, то можно назвать и С "кроссплатформенным ассемблером" 8)

>>>кстати насчет MMX, SSE и т.п. - никто не мешает использовать inline функции написанные на asm

Инлайнинг асма убивает напрочь первую слогана - "кроссплатформенный". Кроме того, если мне не изменяет склероз, то инлайнинг не стандартизован.

>причем это к "импорту" list и map, и инженерной культуре?

Ну, скажем так, "какой резон" тянуть два больших инклуда и инстанциировать два больших шаблона, которые ничего в данной ситуации не дают? Так, пара коллекций стрингов по ~10 элементов?

>Ну и от аллокатора зависит.

Аллокатор в stl - неудачная фича.

>> Так что отпускаю её в свободное плавание.

> Ну, Вы ее пропагандируете. Не так чтоб успешно...;)

Ну так болтать -- не мешки ворочать :)

> А если поставить 686 то уже типа кранты всему ? А если это не х86-like архитектура ? 8)

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

> если мне не изменяет склероз, то инлайнинг не стандартизован.

изменяет

>>причем это к "импорту" list и map, и инженерной культуре?

>Ну, скажем так, "какой резон" тянуть два больших инклуда и инстанциировать два больших шаблона, которые ничего в данной ситуации не дают?

Ну а вред какой? Только не надо про 4К кода на инстанциацию, ок?

> Так, пара коллекций стрингов по ~10 элементов?

Если он 10 элементов, то без разницы, что использовать. Если она имеет шансы разрастись до тысяч, то list и map могут быть предпочтительнее.

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

блин, ну когда же наконец сделают возможность редактирования мессаг..8(

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

>>>причем это к "импорту" list и map, и инженерной культуре?

>>Ну, скажем так, "какой резон" тянуть два больших инклуда и инстанциировать два больших шаблона, которые ничего в данной ситуации не дают?

>Ну а вред какой? Только не надо про 4К кода на инстанциацию, ок?

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

>> Так, пара коллекций стрингов по ~10 элементов?

>Если он 10 элементов, то без разницы, что использовать. Если она имеет шансы разрастись до тысяч, то list и map могут быть предпочтительнее.

Тысячи опций конфигурации у одного модуля?

да я не обижаюсь, по сравнению с общей массой сообщений на ЛОРе ваш пост просто идеал вежливости и корректности :)

насчет inline - я читал об этом не раз, что в 1999-м году его внесли стандарт, да вот и по гуглю сразу результаты:

http://www.greenend.org.uk/rjk/2003/03/inline.html :
GNU C (and some other compilers) had inline functions long before standard C introduced them (in the 1999 standard);

http://en.wikipedia.org/wiki/Inline_function :
C++, C99, and GNU C each have support for inline functions, although 1989 ANSI C, the dialect of C most commonly used in practice, does not

> Клиенту такого кучерявого кода придется компилировать половину stl

Если включить только vector, ему, бедняге, придется компилировать всего треть stl, он будет благодарен?

> Тысячи опций конфигурации у одного модуля?

Почему нет?

Я, наверное, не совсем корректно выразился - я имел ввиду именно инлайнинг асма.

Ну давайте, родные, поднажмите! Столлмана с его OLPC уже догоняем, до субботы надо выбиться на верх :)

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

Проблемы гентушников шерифа не особо беспокоят.

> Тысячи опций конфигурации у одного модуля?

Мы ж говорим о сферических модулях в вакуме, там всё может быть.

> Тысячи опций конфигурации у одного модуля?

Придется написать ынтерпрайз gconf!

> Что проще - добавить 4-8 байтов std::string'а в хвост std::vector или аллоцировать каждый раз мелкий объект для узла list? std::map тоже нужна только если в нее что-то постоянно класть/удалять в режиме 24/7.

Насчёт std::list согласен, но std::map - это же ассоциативный массив, без него никак.

> Тысячи опций конфигурации у одного модуля?

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

> Ну давайте, родные, поднажмите!

Мы стараемся, а вот ты шлангуешь :/

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

>> Клиенту такого кучерявого кода придется компилировать половину stl

>Если включить только vector, ему, бедняге, придется компилировать всего треть stl, он будет благодарен?

Я бы все же попросил на вход минималистичный абстрактный интерфейс типа StringEnum.

>> Тысячи опций конфигурации у одного модуля?

>Почему нет?

При этом они кстати постоянно должны модифицироваться. Конфиги в основном читаются.

> std::map - это же ассоциативный массив, без него никак.

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

>Насчёт std::list согласен, но std::map - это же ассоциативный массив, без него никак.

Взять Loki::AssocVector. В отличие от остальной части творчества Александреску он написан удивительно, даже феноменально, просто.

> Мы стараемся, а вот ты шлангуешь :/

Да чё-то провокации в треде кончились... :(

Оффтопик: а у нас тут относительно недалеко реактор потёк :) На одном новостном сайте пишут, что ТВЭЛ разрушился и загрязнил первый контур охлаждения, и, типа, ниче серьёзного, а на другом сайте пишут, что разрушился первый контур и произошла утечка охлаждающей жидкости, и тоже ниче особо серьёзного. Если сложить обе новости, то можно предположить, что разрушился ТВЭЛ, разрушился контур охлаждения, и вместе произошла утечка топлива за пределы реактора :)

> При этом они кстати постоянно должны модифицироваться. Конфиги в основном читаются.

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

Да оно есть практически кругом. Каждый лепит что-то своё. Почему и уточнял.

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

А что программе делать, если это демон на далёком сервере? Плохая программа, без окон?..

ну тут конечно прийдется #ifdef'ами обнимать код - выбора нет

У меня триггер больше щёлкнул на то, что в хорошей программе должно быть окно :)

ну если это настолько плохая программа :) тогда можно и однажды прочитать, но к таким похим программам обычно пишут хорошие - фронтэнды для правки конфигов, а вот они должны уже уметь писать, причем если эта хорошая программа настолько хороша, что написана под МакОС, то она обязана после каждого чиха переписывать конфиг, т.к. кнопок Apply/OK нет :)

а если серьезно, то мы сами пишем сервер БД( я больше занимаюсь гуи к нему ), и конфиг конечно читается один раз, но это не значит, что значения прочитанные из него железно константы, клиентская прога через API/SQL может сменить их, и после изменения "ключа" необходимо выполнить действия аналогичные - сохранить его, "рассказать" об этом необходимым обьектам, разве что в файл не записать, таким образом тут имеем дело с конфигом в памяти, только и всего, зачем дублировать код по его загрузке/сохранению на две копии?

>Там о том что

>class Bar {
>public:
>void foo(double f);
>private:
>void foo(int f);
>};

>Bar bar;
>bar.foo(21);

>Даст ошибку вида "неоднозначная конструкция", т.к приватные методы и
>данные компилятор рассматривает равноправно с публичными и отвергает
>в самый последний момент, при проверке прав доступа.

Да ты чоооо?

А мой компилятор говорит мне "void Bar::foo(int) is private". У меня
неправильный компилятор? Или это у тебя неправильный компилятор? Или
для тебя "С++ == VC++"? Жги ещё %)))

скажем так у хорошей программы, к которой приделали окно и ей приходится с этим мириться :)

>> При этом они кстати постоянно должны модифицироваться. Конфиги в основном читаются.

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

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

>Вижуал ?

>Потому что gcc-4.1 говорит

Да у него где ни копни чуть глубже --- везде мелкомягкие уши вылезают. Когда детство безнадёжно покалечено Вижуал Сиплюсплюсом --- остаётся только посочувствовать.... =\

class Bar { public: void foo(long f); private: void foo(short f); };

int main(int, char**) { Bar b; b.foo(21);

return 0; }

main.c: In function ‘int main(int, char**)’: main.c:12: ошибка: вызов перегруженной ‘foo(int)’ имеет неоднозначную трактовку main.c:4: замечание: претенденты: void Bar::foo(long int) main.c:6: замечание: void Bar::foo(short int)

class Bar { public: void foo(long f); private: void foo(short f); };

int main(int, char**) { Bar b; b.foo(21);

return 0; }

main.c: In function ‘int main(int, char**)’: main.c:12: ошибка: вызов перегруженной ‘foo(int)’ имеет неоднозначную трактовку main.c:4: замечание: претенденты: void Bar::foo(long int) main.c:6: замечание: void Bar::foo(short int)

class Bar
{
 public:
   void foo(long f);
 private:
   void foo(short f);
};

int main(int, char**)
{
    Bar b;
    b.foo(21);

    return 0;
}

main.c: In function ‘int main(int, char**)’:
main.c:12: ошибка: вызов перегруженной ‘foo(int)’ имеет неоднозначную трактовку
main.c:4: замечание: претенденты: void Bar::foo(long int)
main.c:6: замечание:              void Bar::foo(short int)

"Вижуал Сиплюсплюс" просто оболочка с компилятором( причем достаточно качественная после установки VisualAssist ) - она не заставляет писать кривой код :) есть более страшные IDE, xCode например - жутко раздражают его тормоза, ограниченность и глюки, "повбывав бы" (с)

>Ну вообще, по стандарту он должен отвалиться в "неоднозначностью", т.к есть неявная конверсия int->double.

Ух ты!!! Да ну?? А-бал-дееееть.... А Страуструп в курсе?

P.S.: только не вздумай ему писать --- помрёт же дядька....

сразу видно - человек решил осилить по порядку весь наш бред, что мы тут написали :)

>То что у тебя в одном cpp файле импортируется и <list> и <map> вообще довольно показательно -> полное отсутствие инженерной культуры.

Блин, я начинаю догадываться.... Это такая новая тактика спора: заставить оппонента умереть от смеха, да? :D

P.S.: я начинаю коллекционировать твои перлы

>Фигассе понятия об инженерной культуре.

Ну а фигли ты хотел? За использование std:: --- расстрел, для каждого типа контейнеров нужно обязательно написать свой велосипед. И вообще хватит одного только вектора, ассоциативные массивы не для джедаев! Вот это настоящая инженерная культура, а не то что некоторые %)))

> За использование std:: --- расстрел

Кстати, я даже понял, откуда растут уши у stl-ненавистничества: в 6-й студии с stl-ем были проблемы :)

>"Вижуал Сиплюсплюс" просто оболочка с компилятором( причем достаточно качественная после установки VisualAssist )

"Кролик --- это не только ценный мех, но и 2-3 кг легко усваиваемого диетического мяса". Так, о чём это я.... ах, да: Вижуал Сиплюсплюс это не только IDE, но ещё и довольно... хм... своеобразная реализация стандарта (понятно же, что имелся в виду не сам devenv.exe, а всё его сопутствующее хозяйство вроде cl.exe сотоварищи....)

>своеобразная реализация стандарта

безупречная реализация стандарта Microsoft C++

//fixed

> Вижуал Сиплюсплюс это не только IDE, но ещё и довольно... хм... своеобразная реализация стандарта

Емнип, к тому самому devenv.exe можно и mingw-g++ прикрутить.

>Кстати, я даже понял, откуда растут уши у stl-ненавистничества: в 6-й студии с stl-ем были проблемы :)

Погрепай комментарии вида "// XXX:" в коде stlport. В GNU C++ stdlib грустных комментариев тоже достаточно.

Нечего там грепать. Страуструп сказал - stl, значит - stl, и точка. А страуструп - бох, ага