Ушат помоев в сторону крестолюбов

Я лучше приведу тебе работающий аналог, для которого написать аналог ты не осилишь:

#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include "uthash.h"

struct S {
	int i;
	const char *key;
	const char *s;
	UT_hash_handle idx_key;
	UT_hash_handle idx_i;
};

typedef struct {
	struct S *by_key;
	struct S *by_i;
} multihash;

struct S*
make_S(int i, const char *s)
{
	int len = strlen(s);
	struct S *obj = malloc(sizeof(*obj) + len + 1);
	obj->i = i;
	obj->s = (const char*)(obj + 1);
	memcpy(obj + 1, s, len + 1);
	return obj;
}

struct S*
hash_S_put(multihash *hash, const char *key, int i, const char *s)
{
	struct S *obj;
	int klen, slen;
	klen = strlen(key) + 1; slen = s != NULL ? strlen(s) + 1 : 0;
	obj = malloc(sizeof(*obj) + klen + slen);
	obj->i = i;
	obj->key = memcpy((char*)(obj + 1), key, klen);
	obj->s = slen ? memcpy((char*)obj->key + klen, s, slen) : NULL;
	HASH_ADD_KEYPTR(idx_key, hash->by_key, obj->key, klen - 1, obj);
	HASH_ADD(idx_i, hash->by_i, i, sizeof(obj->i), obj);
	return obj;
}

static int
S_cmp_i(const struct S *a, const struct S *b)
{
	return a->i - b->i;
}

static int
S_cmp_key(const struct S *a, const struct S *b)
{
	return strcmp(a->key, b->key);
}

int main()
{
	struct S *s;
	multihash mh = {NULL, NULL};

	hash_S_put(&mh, "one", 1, "cat");
	hash_S_put(&mh, "two", 2, "dogs");
	hash_S_put(&mh, "three", 3, "cows");
	
	HASH_SRT(idx_key, mh.by_key, S_cmp_key);
	HASH_SRT(idx_i, mh.by_i, S_cmp_i);
	
	printf("Sorted by key:\n");
	for (s = mh.by_key; s != NULL; s = s->idx_key.next)
		printf("  \"%s\" => { %d, \"%s\" }\n", s->key, s->i, s->s);

	printf("\nSorted by i:\n");
	for (s = mh.by_i; s != NULL; s = s->idx_i.next)
		printf("  \"%s\" => { %d, \"%s\" }\n", s->key, s->i, s->s);
	return 0;
}

Осилишь гибридный хеш с поиском по двум ключам или сразу сольешься?

Это гнушное нестандартное и не портируемое расширение.

... которое поддерживают clang, icc и конечно же наш любимый gcc.

При этом твой код всё равно будет в десять раз больше

Обосрамс №1

в отличие от приведенного варианта на C++ - твой примитивный камент про RAII показывает, что ты ничего не понимаешь не только в C++, но и в том, что может выдавать valgrind

Обосрамс №2. Ну так я дождусь сегодня от крестопрофи пояснений к утечкам памяти в простейшем примере?

Серьезно, просто прекратите писать тупак и ЖЖ на ЛОРе! Спасибо.

win32 почти и не используется

Ну да, интерфейсы рисуются силой мысли, а GDI и DirectDraw тут совершенно ни при чем. Да и DispatchMessage даже в глубинах wrapper-ов не вызывается, да?

Всем, кроме тебя, понятно, что речь шла о native Win32 application, а не о native NT API application. Да и тебе это понятно, но ты решил порисоваться знанием редких терминов.

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

Спасибо, что признался.

А можно узнать что происходит в этом коде?
не имею возможности прочитать и понять этот кусок

так бы тоже хотел попробовать сыграть в спец. олимпиаду =)

Это просто другой уровень абстракции. Никто не требует писать на плюсах так же как на сях.

и да, что за ra2 такое? у меня гугел только red alert 2 выдает, хорошая игра кстати

Осилишь гибридный хеш с поиском по двум ключам или сразу сольешься?

Мне его не надо осиливать, его осилили до меня: http://www.boost.org/doc/libs/1_62_0/libs/multi_index/doc/index.html

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

«Получение ресурса есть инициализация».

Directdraw к win32 действительно не имеет отношения, а gdi - deprecated еще во времена windows 3.11. Что касается рисования интерфейсов - это ресурсный компилятор, вообще не код, а секция в pe. рисовать интерфейсы через win32 можно, но это к психиатру.

Обосрамс №2. Ну так я дождусь сегодня от крестопрофи пояснений к утечкам памяти в простейшем примере?

Там нет утечек памяти. Просто научись читать хотя-бы.

Это не делает его более стандартным.

Там нет утечек памяти. Просто научись читать хотя-бы.

Ой как все запущено...

int main()
{
  static char *cpp_fanboi = new char[100];
  return 0;
}

Не весь. Многие написаны на C#, а числодробительная часть вынесена на C++.

В man странице пример. http://ru.manpages.org/hsearch/3

Это не делает его более стандартным.

И он от этого хуже работает, или как?

Ну тут тоже все ок по твоей версии, да? Ведь still reachable != lost.

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

А при чём тут static?

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

GDI мертв и оставлен только для обратной совместимости, GDI+ занял его место с выхода Windows XP. Напомнить сколько лет назад это было и на каком ЯП написан GDI+?

DirectDraw вообще deprecated API.

Вопрос: почему любой спец. софт (автокады, фотошопы и т.п., тысячи их) написан на С++

Я, честно говоря, не знаю ни одного сколь-нибудь крупного win32 приложения со сложным графическим интерфейсом, написанном на голом WinAPI. А на чем еще можно было писать интерфейсы в те бородатые годы?

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

Ой, сильно сомневаюсь. Выбирать в наше время кресты для нового проекта можно только из соображений садомазохизма.

Включать комп я сейчас не пойду. Если до завтра тема доживет - завтра напишу. Но из примера тебе должно быть всё понятно. Если, конечно, твоя цель - понять.

GDI

канделябром

DirectDraw

это часть directx, как человек «который знает как работет система» ты должен был бы знать.

DispatchMessage

опять канделябром

Мало ли куда там dispatchmessage запихано. Его один раз написали, 100 раз поплевались и больше туда заглядывать никто кроме мазохистов не хочет.

Да что ты к ленину привязался, он известный анскилл. Вон тебе выше код написали: Ушат помоев в сторону крестолюбов (комментарий)

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

И, да, работает хуже. Кругом багрепорты, что на icc, что на clang.

это часть directx, как человек «который знает как работет система» ты должен был бы знать.

С каких пор на LOR-е нужно знать WinAPI, чтобы обличать крестофанбоев в некомпетентности?

Мало ли куда там dispatchmessage запихано

Крестологика в действии: зойчем знать детали имплементации, если хеллоуворлд на qtscript работает? Суть в том, что WinAPI по-прежнему там и никуда не делось: это единственный способ общаться с ядром Windows. Это как отрицать syscall-ы в линуксе со словами: «ну есть же libc».

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

==6749== Memcheck, a memory error detector
==6749== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==6749== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==6749== Command: ./a.out
==6749== 
Sorted by key:
  "one" => { 1, "cat" }
  "three" => { 3, "cows" }
  "two" => { 2, "dogs" }

Sorted by i:
  "one" => { 1, "cat" }
  "two" => { 2, "dogs" }
  "three" => { 3, "cows" }
==6749== 
==6749== HEAP SUMMARY:
==6749==     in use at exit: 1,588 bytes in 7 blocks
==6749==   total heap usage: 7 allocs, 0 frees, 1,588 bytes allocated
==6749== 
==6749== LEAK SUMMARY:
==6749==    definitely lost: 144 bytes in 1 blocks
==6749==    indirectly lost: 1,444 bytes in 6 blocks
==6749==      possibly lost: 0 bytes in 0 blocks
==6749==    still reachable: 0 bytes in 0 blocks
==6749==         suppressed: 0 bytes in 0 blocks
==6749== Rerun with --leak-check=full to see details of leaked memory
==6749== 
==6749== For counts of detected and suppressed errors, rerun with: -v
==6749== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Вот в этом - все C-говнокодеры. Прокукарекал про valgrind, а своё поделие проверить даже не удосужился.

Единственный способ общаться с ядром windows - native api. Win32 - это трансляция и эмуляция. Такие дела.

И, да, работает хуже. Кругом багрепорты, что на icc, что на clang.

И тут ты такой наглядно демонстрируешь злободневные проблемы с attribute cleanup в icc/clang.

Я, честно говоря, не знаю ни одного сколь-нибудь крупного win32 приложения со сложным графическим интерфейсом, написанном на голом WinAPI. А на чем еще можно было писать интерфейсы в те бородатые годы?

Этот пук был к чему?

Ой, сильно сомневаюсь.

Че ты как баба то, весь сомнительный.

Выбирать в наше время кресты для нового проекта можно только из соображений садомазохизма.

Садомазохизм - это писать на С прикладуху, как ты тут воняешь.

Вот в этом - все C-говнокодеры

Однако ж, научил кресторебенка новому трюку, тот и обрадовался. Зачем мне освобождать память перед выходом из main? Представь себе хеш, скажем, на 80 миллионов элементов — какой идиот будет вызывать 80 (а в твоем случае минимум 160) миллионов free вместо того, чтобы предоставить это сделать ОС?

Кстати, давно интересно: через какую задницу реализован unordered_map? Судя по числу malloc-ов, там реально vector<pair<Key, Value>> под капотом — это говно при жирных структурах на 100k элементах задыхаться начнет.

сладкого чая

Oh shi~~~~~~~~~~~~

С каких пор на LOR-е нужно знать WinAPI, чтобы обличать крестофанбоев в некомпетентности?

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

зойчем знать детали имплементации

Зачем, действительно. Ты выше вот uthash используешь? Ты знаешь как работет хэш таблица (и эта конкретно?) Как в этой имплементации происходит работа с коллизиями, какая выбрана хэш. функция? А? А почему вообще выбрана хэш-таблица, а не, допустим, дерево?!

WinAPI - это единственный способ общаться с ядром Windows.

рукалицо

Этот пук был к чему?

А какие были их альтернативы в 90-х? На C поедешь с WinAPI работать, а для крестов вроде как mfc/wtl/atl есть. И вообще, чего ты ко мне пристал со своей виндой?

Садомазохизм - это писать на С прикладуху, как ты тут воняешь.

Типичный крестофанбой.

ППКС.

Зачем мне освобождать память перед выходом из main?

Забавные у тебя двойные стандарты...

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

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

Ты знаешь как работет хэш таблица (и эта конкретно?)

Да.

Как в этой имплементации происходит работа с коллизиями, какая выбрана хэш. функция? А?

1) separate chaining 2) Jenkin's hash. А теперь ответь на эти же вопросы об unorderd_map, или «не определено стандартом»?

Типичный крестофанбой.

Очень важный крестофанбой. Никак на нём куча развесистого энтерпрайз-гуано из нулевых написано.

Определяется структура S с членами i (число) и s (строка). На стеке создается неупорядоченная карта с ключом строкой и значением S. В карту добавляются пары ключ-значение (например ключ: «one», значение: S.i = 1, S.s = «cat»), при чем значение перемещается (перемещается, не копируется). Потом цикл по всем парам ключ-значение в карте и печать.

// Кстати, сишники, а как на сишечке реализовать перемещение объекта, выделенного на стеке?

kawaii_neko лает, караван идет.

Уже сколько лет пророчат смерть и обличают C++ во всех грехах, он он, зараза такая, никак не хочет уходить из сцены!

лучше попытаться съехать с темы.

Это ты сейчас про свою попытку съехать с разговора о том, как ты сфэйлился на winapi? :D

1) separate chaining 2) Jenkin's hash.

Иии что тебе это говорит о поведении этой имплементации хэш. таблицы?

Так почти весь эмбеддед на плюсах по-моему :D

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

Забавные у тебя двойные стандарты...

Забавно то, что ни один крестоодепт в этом треде не осилил прокомментировать вывод valgrind, хотя это довольно просто, если понимаешь, как все работает.

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

1. без понятия, как это сделать и не опозориться
2. без понятия, что такое still reachable и чем оно отличается от possibly lost
3. не написал lookup в своей хеш-таблице, потому что знаешь, что каждый lookup по const char* будет приводить к выделению памяти под временный std::string, а это неловко (шучу, конечно же ты этого не знаешь, как и 99% крестопрофессионалов в этом треде)
4. не в курсе, какое говно у unordered_map под капотом, но пользуешься и рано или поздно будешь недоумевать: «а че оно так тормозит, это же O(1)!»

// Кстати, сишники, а как на сишечке реализовать перемещение объекта, выделенного на стеке?
объект, выделенный на стеке

Ты это, ложись спасть, а то несешь охинею невразумительную. У тебя кто, emplace что ли «на стеке навыделял»? :D

без понятия, что такое still reachable и чем оно отличается от possibly lost

http://valgrind.org/docs/manual/faq.html

«My program uses the C++ STL and string classes. Valgrind reports 'still reachable' memory leaks involving these classes at the exit of the program, but there should be none.

First of all: relax, it's probably not a bug, but a feature.»

А вот про твои definetely lost:

«„definitely lost“ means your program is leaking memory — fix those leaks!»

Уже сколько лет пророчат смерть и обличают C++ во всех грехах, он он, зараза такая, никак не хочет уходить из сцены!

Чтобы уйти со сцены, надо на нее для начала вскарабкаться. За 30 лет крестам так и не удалось найти свою нишу: для прикладного ПО слишком убого, для системного — чересчур наворочено.

C++ везде, только ты слишком ограничен чтобы это видеть. (Это проблема всех фанатиков).

Зачем крестам что-то искать и куда-то уходить. У них персональная, принесённая с собой сцена, все эти 30 лет.