Изобретение велосипедов

[Igors]

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

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

Когда Вы берете нечто "общее" - с готовыми решениями все прекрасно. Тот же слот-сигнал. Помню Вы сделали свой, действительно поделка (в хорошем смысле этого слова, я бы в жизни не написал такое), никакой конкуренции бусту и/или Qt она не составляет. Чисто в целях самосовершенствования (что хорошо).

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

Вообще, почему хаять велосипедизм считается хорошим тоном?

..но боюсь что велосипед сей..

меня огорчает необходимость писать велосипеды..

И.т.д. И.т.п. Чего же хотелось бы? Вероятно нахватать готовых классов и слепить из них. Хорошо если такая возможность есть - но ее часто может и не быть. И что тогда будет делать хающий? И почему в голову не приходит простая мысль - масса людей тоже хотят "по-готовому", а значит и цена этому "рупь-ведро"

[vulko]

убого?))
это называется продуманно!

Конечно, убого! Как только хоть какой-то performance из Java надо выжимать, сразу вся ее стандартная библиотека на помоечку идет: http://java-performance.info/use-case-optimizing-memory-footprint-of-read-only-csv-file-trove-unsafe-bytebuffer-data-compression/

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

Пока не нужен performance и используются готовые кубики, из которых собирается очередной enterprise, оно так и есть. Например, для задача типа таких как у Igors никакие "удобства разработчика" не позволят решать их эффективно на java.

Читаем summary по твоей ссылке:

If you want to keep a large number of read-only records in memory, consider storing them in the most possible compact form in a ByteBuffer (or using sun.misc.Unsafe).
Use Trove maps for indices.
Check if you need to keep your ID field values as maps keys (you can still check ID field stored in ByteBuffer) or hash code is sufficient as a key.
If you know the possible query keys in advance – don’t store IDs at all – hash code is sufficient replacement for map keys in a lot of situations.

это касается и плюсов тоже.

вообще хз че ты хотел этой ссылкой сказать, долго наверное гуглил её...))

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

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

далеко ходить не надо. сравни работу с сокетом на плюсах (не qt) и на жабе. попробуй распарсить xml на плюсах. таких примеров куча.
это называется продуманность.

а не подход в стиле икеи. купите склеенные опилки и соберите это говно сами.

[kamre]

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

Конечно, и плюсов касается. Только в плюсах абстракции позволяют работать с одним сплошным куском памяти и не терять производительность как при работе с классами из JDK.
Ссылка давно в закладках )) Мне Java/Scala во многом нравятся, но в моих задачах, где performance важен, они не очень подходят.

[Old]

далеко ходить не надо. сравни работу с сокетом на плюсах (не qt) и на жабе.

Давайте. Покажите как это делается в java, а я покажу как это красивенько сделать на boost.asio.

попробуй распарсить xml на плюсах. таких примеров куча.

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

Код

XML
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE avset-list>
<avset-list ver="1.0">
	<producer name="Fuck, Inc">
		<item name="Good shit">
			<v>79</v>
			<d>8,0</d>
		</item>
	</producer>
</avset-list>
 

Как на java получить значение v и d, а так же атрибута name у тега item?

это называется продуманность.

Очень хочется увидеть эту продуманность.

[vulko]

далеко ходить не надо. сравни работу с сокетом на плюсах (не qt) и на жабе.

Давайте. Покажите как это делается в java, а я покажу как это красивенько сделать на boost.asio.

попробуй распарсить xml на плюсах. таких примеров куча.

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

Код

XML
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE avset-list>
<avset-list ver="1.0">
	<producer name="Fuck, Inc">
		<item name="Good shit">
			<v>79</v>
			<d>8,0</d>
		</item>
	</producer>
</avset-list>
 

Как на java получить значение v и d, а так же атрибута name у тега item?

это называется продуманность.

Очень хочется увидеть эту продуманность.

boost это 3rd party. давай лучше без буста


На жабе способов много. Можно например вот так:

Код:

                parser = new XmlPullParcer();
		String prodTag = "producer";
		String itemTag = "item";
		String vTag = "v";
		String dTag = "d";
		while ((event = parser.next()) != XmlPullParser.END_DOCUMENT) {
		    if (event == XmlPullParser.START_TAG) {
		        if (prodTag .equals(parser.getName())) {
		        	System.out.println("producer name:" + parser.getAttributeValue(null, "name"));
		        } else if (itemTag.equals(parser.getName())) {
		        	System.out.println("item name:" + parser.getAttributeValue(null, "name"));
		        } else if (vTag.equals(parser.getName())) {
		        	System.out.println("v: " + parser.nextText());
		        } else if (dTag.equals(parser.getName())) {
		        	System.out.println("d: " + parser.nextText());
		    }
		}

[Old]

boost это 3rd party. давай лучше без буста

Вы хотите использовать всю мощь и красоту всех ява библиотек, и хотите ограничить меня в использовании boost, который по сути является песочницей для проверки решений, которые в будущем попадут в стандарт?

На жабе способов много. Можно например вот так:

Наверное это не самый лучший. Так же с xml можно работать с помощью того же QXmlStreamReader.
Совсем не удобное и не подходящее решение для обозначенной мной задачи.
Может есть что поудобней? Или это предел возможностей явы с ее чудо библиотекой. И что там с красивыми сокетами? Если в таком же стиле, как и работа с xml то остается только сожалеть за яву.

[vulko]

Очень хочется увидеть эту продуманность.

чтобы увидеть, нужно изучить жабу, покодить на ней. и тогда станет ясно.
это повсюду и во всем.
ну взять те же коллекции, которые уже успели похаять тут...
продуманны:
- возможность сортировки любой коллекции с помощью интерфейса Comparator
- возможность простой и удобной сериализации/десереализации чего угодно
- удобное апи, в отличие от того же stl, где чтобы вставить элемент в мэп, нужно создавать какую-то там Pair... а чтобы получить значение из итератора, нужно делать танцы с бубном, т.к. перегруженный оператор -> не поддерживает автодополнения. почему нельзя было сделать методы T getValue() и void add(T key, T value) методы?

таких мелочей дикое множество.

в самом языке тоже есть няшки. тот же interface, это куда удобнее чем abstract class.
да даже эти говна остатки древних мамонтов в виде h и cpp... зачем?! кому?! для чего?!

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

[vulko]

boost это 3rd party. давай лучше без буста

Вы хотите использовать всю мощь и красоту всех ява библиотек, и хотите ограничить меня в использовании boost, который по сути является песочницей для проверки решений, которые в будущем попадут в стандарт?

чудо библиотека не идет отдельно от jdk или jre.
а вот буст не идет в комплекте со студией или qt. 3rd party оно и в африке 3rd party.

разницу чувствуешь?

Наверное это не самый лучший. Так же с xml можно работать с помощью того же QXmlStreamReader.
Совсем не удобное и не подходящее решение для обозначенной мной задачи.
Может есть что поудобней? Или это предел возможностей явы с ее чудо библиотекой. И что там с красивыми сокетами? Если в таком же стиле, как и работа с xml то остается только сожалеть за яву.

QXmlStreamReader это не с++. Это Qt. Ты на плюсах напиши то же самое.

Есть много чего. Для поставленной задачи это более чем подходит.
XmlPull API подразумевает много чего, те же nextTag() и т.п. Все что угодно можно найти в рамках одной итерации while(), если тебя это беспокоит.

[Old]

чудо библиотека не идет отдельно от jdk или jre.
а вот буст не идет в комплекте со студией или qt. 3rd party оно и в африке 3rd party.

разницу чувствуешь?

Нет, не чувствую.
Я не вижу в этом проблемы. Если в проекте нужен boost (а он изумительно дополняет стандартную библиотеку), то его нужно использовать.

QXmlStreamReader это не с++. Это Qt. Ты на плюсах напиши то же самое.

А Qt это не C++?

Есть много чего. Для поставленной задачи это более чем подходит.

Но только для такой простой задачи это слишком многословно и очень сложно сопровождать, при изменении формата xml файла. И здесь еще нет проверки корректности всего xml файла.

Вот с помощью boost делаю так:

Код

C++ (Qt)
namespace pt = boost::property_tree;
 
pt::ptree xml;
pt::read_xml( "file.xml", xml );
 
string v = xml.get<string>( "producer.item.<xmlattr>.name" );
int v = xml.get<int>( "producer.item.v" );
double d = xml.data<double>( "producer.item.d" ); 
 

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

Вот это я называю удобно.
С ява сокетами и boost.asio думаю будет та же ситуация.

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

[vulko]

Нет, не чувствую.
Я не вижу в этом проблемы. Если в проекте нужен boost (а он изумительно дополняет стандартную библиотеку), то его нужно использовать.

Ну тогда давай сюда ещё Java EE приплетем. Буст уже не спасет

А Qt это не C++?

Нет. Фреймворк и SDK это все таки разные вещи.

Но только для такой простой задачи это слишком многословно и очень сложно сопровождать, при изменении формата xml файла. И здесь еще нет проверки корректности всего xml файла.

Вот с помощью boost делаю так:

Код

C++ (Qt)
namespace pt = boost::property_tree;
 
pt::ptree xml;
pt::read_xml( "file.xml", xml );
 
string v = xml.get<string>( "producer.item.<xmlattr>.name" );
int v = xml.get<int>( "producer.item.v" );
double d = xml.data<double>( "producer.item.d" ); 
 

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

Ну если xml файл состоит из одного элемента producer/item, мой код можно сократить до тех же размеров.
Так то я написал конструкцию для распарсивания файла с любым количеством записей producer и item.
А для хранения одной записи можно и без xml обойтись.

Исключения жаба отлично умеет выкидывать и выкидывает. У плюсов такой же механизм.

Вот это я называю удобно.
С ява сокетами и boost.asio думаю будет та же ситуация.

какая?)

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

Ява это была первая попытка сделать на основе с++ нечто удобное для разработчика. Такое, где будет все ему нужное и этим будет удобно пользоваться.
Причем сделать хотели именно ООП язык, а не полу-ООП, как с++. Это сейчас С++11 слегка подрос, правда все это опять же не кроссплатформенно и не везде поддерживается.
Тогда никаких бустов и в помине не было.
Это огромный конструктор, где нет нужды в чужих деталях. Можно собрать что угодно, когда угодно и где угодно (run once, run anywhere ).

Думать не требуется дворникам.
То что с++ это для умных а жаба для дебилов, это все холивар-срач "аргументы". Думать нужно всегда и везде.
В c# тоже думать не надо? Оно тоже для дебилов?

Тут люди на Qt пытаются под андройд кодить... это все потому что жаба говно, а плюсы круто?)) Или может потому что им лень изучить жабу, вместо дрочева с JNI?

[Old]

Ну тогда давай сюда ещё Java EE приплетем. Буст уже не спасет

Давайте. Это что?

Нет. Фреймворк и SDK это все таки разные вещи.

Можно выдернуть класс QXmlStreamReader из Qt и использовать в обычном C++. Только это никому не надо, потому что есть средства поудобней.

Так то я написал конструкцию для распарсивания файла с любым количеством записей producer и item.

Здесь с этим тоже нет проблем:

Код

C++ (Qt)
for( const pt::ptree::value_type &it : xml.get_child( "producer" ) )
{
    if( it.first == "item" )
    {
        const pt::ptree &item = it.second;
        string v = item.get<string>( "<xmlattr>.name" );
        int v = item.get<int>( "v" );
        double d = item.data<double>( "d" ); 
    }
}
 

какая?)

Как с обработкой xml.
Думаю там работа с сокетами такая как в Qt. У asio с этим получше.

То что с++ это для умных а жаба для дебилов, это все холивар-срач "аргументы".

Я такого не говори. Я хотел сказать что не корректно сравнивать яву и с++, цели у них разные.
И, как вы видите сами, ява со всем ее счастьем, не смогла заменить с++. Она заняла свою нишу, о которой я и написал.

[vulko]

Ну тогда давай сюда ещё Java EE приплетем. Буст уже не спасет

Давайте. Это что?

Нет. Фреймворк и SDK это все таки разные вещи.

Можно выдернуть класс QXmlStreamReader из Qt и использовать в обычном C++. Только это никому не надо, потому что есть средства поудобней.

Так то я написал конструкцию для распарсивания файла с любым количеством записей producer и item.

Здесь с этим тоже нет проблем:

Код

C++ (Qt)
for( const pt::ptree::value_type &it : xml.get_child( "producer" ) )
{
    if( it.first == "item" )
    {
        const pt::ptree &item = it.second;
        string v = item.get<string>( "<xmlattr>.name" );
        int v = item.get<int>( "v" );
        double d = item.data<double>( "d" ); 
    }
}
 

какая?)

Как с обработкой xml.
Думаю там работа с сокетами такая как в Qt. У asio с этим получше.

То что с++ это для умных а жаба для дебилов, это все холивар-срач "аргументы".

Я такого не говори. Я хотел сказать что не корректно сравнивать яву и с++, цели у них разные.
И, как вы видите сами, ява со всем ее счастьем, не смогла заменить с++. Она заняла свою нишу, о которой я и написал.

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

java ee это расширение java se (standart edition) как раз для клиент-серверных бизнес решений где нужно быстро накидать софт.
https://ru.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition

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

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

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

Код:

const pt::ptree &item = [b]it.second[/b];

почему second? кто придумал такую хрень?
почему нельзя сделать it.value? или ещё что-то понятное?

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

но вот такой код читать куда приятнее. И писать его приятнее.

Код:

for( const ValueType &it : xml.getChild("producer") )
{
    if( it.getKey == "item" )
    {
        XmlItem &item = it.getValue();
        String v = item.getName("name");
        int v = item.getInt("v");
        double d = item.getDouble("d"); 
    }
}

[Old]

почему second? кто придумал такую хрень?
почему нельзя сделать it.value? или ещё что-то понятное?

Это пара - std::pair. Там есть first и second. Они равноправны. Какой из них предлагаете назвать value?

но вот такой код читать куда приятнее. И писать его приятнее.

Точно. Он практически ничем не отличается от моего бустовского и очень далек от вашего явовского.
И это я еще не предлагаю поменять структуру xml, как это часто бывает при эволюции проекта.

[vulko]

почему second? кто придумал такую хрень?
почему нельзя сделать it.value? или ещё что-то понятное?

Это пара - std::pair. Там есть first и second. Они равноправны. Какой из них предлагаете назвать value?

но вот такой код читать куда приятнее. И писать его приятнее.

Точно. Он практически ничем не отличается от моего бустовского и очень далек от вашего явовского.
И это я еще не предлагаю поменять структуру xml, как это часто бывает при эволюции проекта.

Нахрена мне в xml std::pair? Какая равноценность, когда пара тэг-значение никогда не равноценна!
Даже first и second не равноценны, т.к. один первый, другой второй.

просто когда человеку, как в жабе, "думать не надо", он делает такую хрень.

если бы те кто делал std, boost и прочее думали бы головой, а не другим местом, то не было бы никаких .first и .second.
были бы .key .value, либо .tag .value...

и такое дерьмо повсюду в std и бусте.
видимо потому-что писалось жопорукими супер продумывальщиками, которым даже интелекта не хватает назвать элементы пары ключ-значение в каком-нибудь map соответсвующими key и value.

[Old]

Нахрена мне в xml std::pair? Какая равноценность, когда пара тэг-значение никогда не равноценна!

Т.е. других претензий не осталось. Это же прекрасно.
С сокетами из Java EE что нибудь покажите?
Или там примерно как и здесь все просто и эффективно?

Код

C++ (Qt)
                parser = new XmlPullParcer();
		String prodTag = "producer";
		String itemTag = "item";
		String vTag = "v";
		String dTag = "d";
		while ((event = parser.next()) != XmlPullParser.END_DOCUMENT) {
		    if (event == XmlPullParser.START_TAG) {
		        if (prodTag .equals(parser.getName())) {
		        	System.out.println("producer name:" + parser.getAttributeValue(null, "name"));
		        } else if (itemTag.equals(parser.getName())) {
		        	System.out.println("item name:" + parser.getAttributeValue(null, "name"));
		        } else if (vTag.equals(parser.getName())) {
		        	System.out.println("v: " + parser.nextText());
		        } else if (dTag.equals(parser.getName())) {
		        	System.out.println("d: " + parser.nextText());
		    }
		}