Google дал оценку Java и C++

> памяти питон жрет в среднем меньше чем жаба

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=python3&lan...

П.С. если вам не нравятся эти бенчмарки - покажите другие

при том что я с ними сравниваю :) у тебя возражения?

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

легко могу сравнивать :) неужели ты мне в этом праве отказываешь, на каком основании? или ты не знал что так можно? :)

>>конкретно смотри на GArray, GByteArray, GPtrArray

Я видел их. Я пользовался ими.

мне кажется ты забыл капсом дописать «МНЕ ОНИ НРАВЯТСЯЯЯ!!!!!!11адинадин АРРРГГГХХХ!»

Теперь, уже в третий раз, спрашиваю тебя: покажи КОНКРЕТНО, где там костыли.

хм, думал будет понятно ещё прошлый раз, ну раз непонятно - копаем глубже

struct _GArray
{
  gchar *data;
  guint len;
};

struct _GByteArray
{
  guint8 *data;
  guint	  len;
};

struct _GPtrArray
{
  gpointer *pdata;
  guint	    len;
};

ничего не смущает?

и, как следствие:

GArray* g_array_new(/*blah*/);
GPtrArray* g_ptr_array_new(/*blah*/);
GByteArray* g_byte_array_new(/*blah*/);

здесь тоже ничего не смущает???

Я думаю гугль продвигает питон

>>Талмудов. Или ты ещё о чём-то подумал?

Почему не значит? Повторю тебе опять: ты сравнил эзотерическую хрень с языками высокого уровня.

>ты сравнил эзотерическую хрень с языками высокого уровня.

Ты сравнил основываясь просто на размере. Это, значит, не хрень? Какой пузатик. Если язык умеет больше, например, то и талмуд будет больше. Также зависит от автора (стиля текста). Так тоже не ясно?

Роб дело говорит, хоть и попаболь у ЦПЛЮСПЛЮСеров с ЖАВАфилами

> хоть и попаболь у ЦПЛЮСПЛЮСеров с ЖАВАфилами

и не говори - просто на говно исходят

легко могу сравнивать :) неужели ты мне в этом праве отказываешь, на каком основании? или ты не знал что так можно? :)

Можно много чего, но это не означает трезвость ума.

ничего не смущает?

Нет, потому что все реализации сделаны на основе GArray. Для удобства использования API. Но никто не мешает тебе все время пользоваться GArray - на здоровье. Только ты, сынок, забыл посмотреть ВСЮ реализацию GArray перед тем, как метанировать. Потому что если бы ты ее посмотрел, то увидел бы, что вся работа идет через другую структуру - общую для всех тобой указанных:

struct _GRealArray
{
  guint8 *data;
  guint   len;
  guint   alloc;
  guint   elt_size;
  guint   zero_terminated : 1;
  guint   clear : 1;
  volatile gint ref_count;
};

здесь тоже ничего не смущает???

А что там не так? Повторяю, это всего лишь для удобства API, ты всегда можешь напрямую для всех целей использовать GArray. Никто не запрещает. Так где костыли-то?

>>Если язык умеет больше, например, то и талмуд будет больше. Также зависит от автора (стиля текста). Так тоже не ясно?

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

> ты всегда можешь напрямую для всех целей использовать GArray. Никто не запрещает.

И потерять все проверки компилятора на совпадение типов. Ты вообще не в своем уме, или тупо троллишь?

Однако если язык умеет слишком мало, то см. пример с Brainfuck'ом. Сравнивать по размеру талмуда — глупость.

> Талму́д (ивр. תָלְמוּד‎, «учение, учёба») — многотомный свод правовых и религиозно-этических положений иудаизма

Евреи не одобряют ваш разговор.

Предлагаешь считать бинарные деревья и множества Мандельброта на мобилках? Да ты упоротый!

>>И потерять все проверки компилятора на совпадение типов. Ты вообще не в своем уме, или тупо троллишь?

А ты в своем? Я же не говорю использовать GArray напрямую там, где УЖЕ используются другие типы. Я говорю о том случае, когда ты на пути первоначального выбора, что использовать.

> volatile gint ref_count;

сборка мусора через подсчет ссылок удивляет

> Я же не говорю использовать GArray напрямую там, где УЖЕ используются другие типы. Я говорю о том случае, когда ты на пути первоначального выбора, что использовать.

Хм. Похоже, не в своем.

>>Хм. Похоже, не в своем.

Как всегда, аргументированно.

>>сборка мусора через подсчет ссылок удивляет

А что удивительного? В GObject это обычное дело, хотя GArray и не относится к нему.

> Как всегда, аргументированно.

Напиши мне выборку элемента из _GRealArray.

>>Однако если язык умеет слишком мало, то см. пример с Brainfuck'ом. Сравнивать по размеру талмуда — глупость.

Причем тут мало умеет? Я сравнил языки высокого уровня, брейнфак к ним не относится.

и да, раз уж ты такой умный, предложи способ написания обобщённого контейнера в Си :) мне это нужно, да

Просто. Береж java.collections, пишешь свой код, компилишь, берешь javap, смотришь полученный байткод, переносишь на C. профит

>Я сравнил языки высокого уровня

Ты так говоришь, как будто это что-то меняет.

>>Напиши мне выборку элемента из _GRealArray.

GRealArray - это приватная структура, описанная в garray.c, а потому не доступная для работы из вне. Непонятно, где ты собрался ее применять. На ее основе сделаны GArray, GPtrArray и GByteArray.

>>Ты так говоришь, как будто это что-то меняет.

Ты так говоришь, будто писать на асм и жабе - одно и то же.

Ну, не так уж и тонко, на /. 683 коммента уже

> GRealArray - это приватная структура, описанная в garray.c, а потому не доступная для работы из вне. Непонятно, где ты собрался ее применять.

Афигеть %) Пациент путается в показаниях. Это ты сказал вот эту глупость:

ты всегда можешь напрямую для всех целей использовать GArray.

напрямую

для всех целей использовать

Я с удовольствием посмотрю, как ты будешь выпутываться :D

дело мужик говорит

>>ничего не смущает?

Нет, потому что все реализации сделаны на основе GArray. Для удобства использования API.

а меня смущает, потому что удобство API - это всё хорошо, но для пользователя, а в моём случае API писать буду я и три раза писать одно и то же - это застрелиться и не встать

Вы таки не поняли что дело не в критике glib, она то как раз хорошая, к ней вопросов нет :) критика к тому что приходится писать постоянно кучу подпорок, например Вы видели что происходит внутри gvarianttype (а отнюдь не gvalue как Вы предлагали) - это застрелите меня что там происходит и так со всем и везде

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

Только ты, сынок

ты это, рамсы чёт совсем попутал, давай полегче тут, не дома на диване

Только ты [..] забыл посмотреть ВСЮ реализацию GArray

struct _GRealArray 
{ 
  guint8 *data; 
  guint   len; 
  guint   alloc; 
  guint   elt_size; 
  guint   zero_terminated : 1; 
  guint   clear : 1; 
  volatile gint ref_count; 
};

во-первых не забыл, просто движение должно осуществляться поступательно

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

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

непомешало бы иметь конструкторы и деструкторы в glib для их динамических объектов а то помимо glib в функции надо освободить ресурсы так еще приходится и следить чтоб вся память из по этих в кавычках динамических структур была освобождена в итоге не код а одно осовождение ресурсов получается

Один из ведущих инженеров Google

s/Один из ведущих инженеров Google/Один из ведущих быдлокодеров Google

PS ниже эпичная новость: «ffvp8 уделал оригинальный гугловский декодер, будучи еще на довольно раней стадии разработки»

>>Афигеть %) Пациент путается в показаниях. Это ты сказал вот эту глупость:

Ты упоротый что ли? GArray и GRealArray - это две разных структуры. Я ничего не спутал. Ты хоть glib видел в глаза, или так, пометанировать захотелось? Ты можешь при желании использовать GPtrArray и GByteArray, но (!), если тебя в них что-то не устраивает, ты ВСЕГДА для ВСЕХ целей можешь воспользоваться более общим вариантом - GArray. GRealArray был приведен к метанированию о костылях в реализации другого пациента.

Я с удовольствием посмотрю, как ты будешь выпутываться :D

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

У инженеров Гугл ЧСВ овер 9000 по умолчанию.

> Ты упоротый что ли?

Я - нет, а ты?

GArray и GRealArray - это две разных структуры.

Напиши мне выборку элемента любого типа, кроме char, из любого из них.

>>а меня смущает, потому что удобство API - это всё хорошо, но для пользователя, а в моём случае API писать буду я и три раза писать одно и то же - это застрелиться и не встать

Используй GArray и не парь людям мозги.

критика к тому что приходится писать постоянно кучу подпорок, например Вы видели что происходит внутри gvarianttype (а отнюдь не gvalue как Вы предлагали) - это застрелите меня что там происходит и так со всем и везде

Где эти подпорки? Если ты называешь подпорка то, что в glib прикрутили ООП - то это твои проблемы, что ты не осилил ООП и тебе хочется быдлокодить на крестах и джабе.

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

Ты так и не объяснил, в чем заключается костыльность данной реализации. Почему другие работают и не говорят о нехватке каких-то ресурсов?

>>непомешало бы иметь конструкторы и деструкторы в glib для их динамических объектов а то помимо glib в функции надо освободить ресурсы так еще приходится и следить чтоб вся память из по этих в кавычках динамических структур была освобождена в итоге не код а одно осовождение ресурсов получается

Беги на жабу.

>>Я - нет, а ты?

Нет, а ты?

Напиши мне выборку элемента любого типа, кроме char, из любого из них.

Она уже 10 лет назад была написана - посмотри в исходниках glib g_array_index ().

Да ее можно сделать вообще на чем угодно.

Проблема в том, что мне нужен язык, у которого есть такая сущность как память. У явы, например, нет. У Плюсов с stl тоже ее нет. И как тут жить?

У erlang, кстати, тоже, как и у haskell.

а меня смущает, потому что удобство API - это всё хорошо, но для пользователя, а в моём случае API писать буду я и три раза писать одно и то же - это застрелиться и не встать

Используй GArray и не парь людям мозги.

неужели не понятно, что использовать glib не всегда возможно?

Где эти подпорки? Если ты называешь подпорка то, что в glib прикрутили ООП - то это твои проблемы, что ты не осилил ООП и тебе хочется быдлокодить на крестах и джабе.

какие то взаимоисключающие параграфы ни о чём - пропускаем

Ты так и не объяснил, в чем заключается костыльность данной реализации.

костыльность в чём? - в костылях,а в чём же ещё

когда Вы поучаствуете в написании достаточно большого проекта на си с нуля в котором нельзя будет использовать GPL/LGPL код и всё это будет в условиях существенно ограниченного времени (а так оно так практически всегда), то я верю что у Вас таких вопросов больше возникать не будет

>будто писать на асм и жабе - одно и то же.

Не угадал. goto start

>>неужели не понятно, что использовать glib не всегда возможно?

По лицензионным или техническим аспектам? Если ты пеняешь в С на то, что в нем ничего нет по умолчанию - это другое дело. Да, там нету многих вещей по умолчанию, на уже написанных либ - вагон. Зато переносимость на порядок выше. Если тебе нужны скорость разработки, а не качество кода и его быстродействие - С не для тебя. На липу залезть, и жопу не ободрать не получится.

костыльность в чём? - в костылях,а в чём же ещё

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

когда Вы поучаствуете в написании достаточно большого проекта на си с нуля в котором нельзя будет использовать GPL/LGPL код и всё это будет в условиях существенно ограниченного времени (а так оно так практически всегда), то я верю что у Вас таких вопросов больше возникать не будет

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

>>Не угадал. goto start

Зациклился? Не переживай, бывает.

неужели не понятно, что использовать glib не всегда возможно?

По лицензионным или техническим аспектам?

а что, есть какая-то разница?

Если ты пеняешь в С на то, что в нем ничего нет по умолчанию - это другое дело.

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

Если тебе нужны скорость разработки, а не качество кода и его быстродействие - С не для тебя.

нужно эти 3 показателя иметь сбалансированными :) и замедлять разработку путём выбора неправильного ЯП - это называется ССЗБ

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

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

а если нет нужного велосипеда - что тогда? а я скажу - сидеть и есть кактус, надеясь что успеешь

Петросян, перелогиньтесь.

ниже эпичная новость: «ffvp8 уделал оригинальный гугловский декодер, будучи еще на довольно раней стадии разработки»

Очевидно же, в гугле просто не занимались преждевременной оптимизацией, а писали код, который хоть както декодирует VP8

А вот когда они перепишут его на Go.....

ты сравнил языки программирования по объему талмудов, а это есть глупость

> А вот когда они перепишут его на Go.....

самому не смешно?

>И этот специалист возьмет ваш код, покачает головой, поцокает языком и скажет «не-не-не, мне дешевле переписать это все с нуля, чем оптимизировать отдельные участки»

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

tailgunner> И нас всех спасет Go?

Goсподу-у-у помолимся-а-а, братия-а-а.

Не дезинформируйте людей: это не гугл дал оценку, а Роб Пайк.

>> И нас всех спасет Go?

Goсподу-у-у помолимся-а-а, братия-а-а.

ЛММ не даст нас в обиду, спасет от маразматика Пайка и его дебильного кролика %)