- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
int complexFunction(int flag)
{
QMutexLocker locker(&mutex);
int retVal = 0;
switch (flag) {
case 0:
case 1:
return moreComplexFunction(flag);
case 2:
{
int status = anotherFunction();
if (status < 0)
return -2;
retVal = status + flag;
}
break;
default:
if (flag > 10)
return -1;
break;
}
return retVal;
}
Пора добавлять отдельную ветку для фрейворка Qt. Это просто клад, так извратить все принципы програмирования :-). Этот код из справки к этому чуду. QMutexLocker - целый класс для того чтобы не нужно было разблокировать мьютекс при выходе из функции! Так они скоро и до сборщика мусора с неявной типизацией дойдут!
P.S. У кого есть Qq попробуйте в "коде" сборки qmake вызвать include внутри функции.
Follow us!
А собственно, в чем проблема? Удобно ведь.
В C++11 такая же штука есть, называется std::lock_guard.
> сборщика мусора
std::shared_ptr и его друзей тоже будешь ругать за извращение "принципов программирования"? Это ведь целая вязанка классов для того чтобы не нужно было освобождать память вручную.
> неявной типизацией
boost::any, boost::variant, QVariant и т.п. тоже не будешь юзать?
P.S. Вон из моих крестов, невежда!
Если это так - то в чем говно? Причем тут сборщики мусора? просто оптимизация труда программиста, который не желает один ретурн из функции
Если нет - просветите. Может мне на пользу пойдет
QMutexLocker в конструкторе захватывает мьютекс, а в деструкторе - отпускает. Благодаря этому не надо искать все точки выхода (включая мимопролетающие исключения) и пихать в них unlock(). В общем аналог шарпейского lock (mutex) { /* some work */ } или жабьего synchronized (mutex) { /* some work */ }.
> Причем тут сборщики мусора?
Видимо автор любит ручное управление памятью, а RAII и сборщики ставит на одну ступеньку.
> в чем говно
Ни в чем, няш.
Как можно, тут же простейшая аналогия -
RAII моет посуду сразу как поест
А GC - когда чистой больше нет
Минорные сборки...
Когда чистая посуда на сушилке кончается, GC часть посуды моет, а часть убирает подальше в шкаф. Через месяц, когда жрать уже не с чего, а вся посуда оказалась в шкафу, он таки решается открыть шкаф и перемыть всё, что там лежит.
Многие кстати так и живут.
> GC часть посуды моет
Ту с которой будут вероятнее всего жрать.
>а часть убирает подальше в шкаф
Которая много раз не использовалась. И GC умеет мыть посуду несколькими руками одновременно, а рук у него часто более двух.
А есть многопоточные free/delete?
http://stackoverflow.com/a/4859584
Про многопоточные фрибсдшный malloc и tcmalloc известно всем, но вопрос был не про malloc/new.
А про: "многопоточные free/delete"
Из многопоточного алокатора не следует многопоточный деалокатор/дефрагментатор памяти.
раз malloc из glibc удовлетворяет твоим критериям многопоточности, то его же free сделан на тех же операциях (впрочем, коды этих двух функций - соседи, и ты сам сможешь сравнить что хочешь):
http://code.woboq.org/userspace/glibc/malloc/malloc.c.html#__libc_free
исходники CRT для винды 7 поищешь сам, мне лень :)
еще не надо забывать про исключения. Если какая-то из вызываемых функций(методов) бросит исключения - будет утечка.
В жабошарпах на этот случай есть finally, try-with-resources и using. А в кресты их не завезли.
А оно там надо?
Тащемта RAII покрывает все случаи этого вашего try-with-resources/using и половину случаев, когда вы пишете finally. Оставшиеся finally покрываются catch { /* finalization */ throw; }