Эврика

[Finch]

Еше маленькая хитрость увиденная мною.
Есть расширяемый массив и две переменные size (количество используемых элементов массива), len (размер самого массива). Функция bool SetDoubleSize(void) увеличивает массив в двое. Если по каким либо причинам увеличение не удалось, функция возрашает false.

Код:

size++;
if ((size < len) || SetDoubleSize())
{
  // Тут наш код по заполнению полей массива
} 
else size--;

[RXL]

Finch, я бы тут использовал не double, а step - лекго кучу памяти впустую занять.

[Антон (LogRus)]

То решение, которое я видел

Код:

if (Func1(...) && Func2(.....) && Func3(....) && .......);

Единственный минус я вижу: довольно сложно отменить результаты предыдуших действий.

Классика жанра я всегда так делаю и не только с функциями, проверака валидности итераторов
например поиск вернул итератор и надо проверить, что он 1 валидный(не end) и элемент удовлетворяет доп условию

Код:

if(it == cont.end() || it->elem < 0) return;

[Джон]

Я раньше тоже любил наворачивать кучу условий. Удовольствие кончается, когда надо пройтись дебаггером. Смотришь на этот if  думаешь, какое из десяти условий не ложь? Так что палка о двух концах.

[Антон (LogRus)]

Джон, а ты не запихивай больше 3-х
да и в студии видно какое не сработало или сработало при правильном подходе, даже при отладке в релизе.

[Джон]

Оно конечно, три меньше чем десять...
А ещё я страдал "болезнью левизны в С++" (как я это называю, из-за порядка проверки условий) в циклах while. Те любил, чтобы цикл выглядел типа while(f1() && f2 && f3() ... );
Тоже прикольная вещица, пока дело не дойдёт до отладки.

[Антон (LogRus)]

Джон, while использую крайне редко, и в форме do{}while

[Антон (LogRus)]

Вспомнилось. Идиома RAII. Практически реализация расширения finally.
суть например нам надо гарантированно(в зависимости от того были исключения или нет), закрыть файл после открытия.
делаем класс который в деструкторе закрывает файл.

Код:

struct raii_closefile
{
file& f;
raii_closefile(file& ff):f(ff){}
~raii_closefile(){ close(f); }
}
file f;
open(f);
raii_closefile(f);

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

[Антон (LogRus)]

Условаия:
1. несколько потоков производят поиск и вставку в древовидный контейнер
2. один поток периодически отризает лишние ветви дерева
Есть задача:
1. организовать доступ таким образом, что бы все потоки поиска могли одновременно производить поиск и вставку
2. обеспечить блокировку всех потоков поиска перед удалением ветки, т.е. дождаться пока все потоки поиска завершат поиск, если придут новые потоки повесить их на мьютексе
3. разблокировать потоки поиска после удаления ветки

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

Код:

#include "stdafx.h"
#include <iostream>
#include <boost/thread/mutex.hpp>
#include <boost/thread/condition.hpp>
#include <boost/thread/thread.hpp>
#include <boost/bind.hpp>

using namespace std;

class semaphore: boost::noncopyable
{
	boost::mutex mutex_;
	boost::condition cond_;
	volatile int refs_;
	volatile bool fullLock_;
public:
	typedef bool cv_state;
public:
	semaphore():refs_(0), fullLock_(false){}
	bool is_fulllock()
	{
		return fullLock_;
	}

	bool is_locked()
	{
		return refs_ > 0;
	}

	bool is_unlocked()
	{
		return 0==refs_;
	}

	void do_lock()
	{
		boost::mutex::scoped_lock l(mutex_);
		if (fullLock_)
			cond_.wait(l);
		++refs_;
		cout << "semaphore::do_lock refs = " << refs_ << "\n";
	}

	void do_unlock()
	{
		boost::mutex::scoped_lock l(mutex_);
		--refs_;
		cond_.notify_all();
		cout << "semaphore::do_unlock refs = " << refs_ << "\n";
	}

	void do_fulllock()
	{
		boost::mutex::scoped_lock l(mutex_);
		cout << "semaphore::do_fulllock in refs = " << refs_ << "\n";
		fullLock_ = true;
		cond_.wait(l, boost::bind(&semaphore::is_unlocked,this));
		cout << "semaphore::do_fulllock done refs = " << refs_ << "\n";
	}

	void do_fullunlock()
	{
		boost::mutex::scoped_lock l(mutex_);
		fullLock_ = false;
		cond_.notify_all();
		cout << "semaphore::do_unfulllock refs = " << refs_ << "\n";
	}
};


void other(semaphore& s, long i)
{
	boost::detail::thread::scoped_lock<semaphore> l(s);
	Sleep((i+1)*1000);
}

void waiter(semaphore& s)
{
	long b = GetTickCount();
	s.do_fulllock();
	long e = GetTickCount();
	cout << "Waited " << e-b << "\n";
	s.do_fullunlock();
}

int _tmain(int argc, _TCHAR* argv[])
{
	semaphore s;
	boost::thread_group ts;
	for (int i = 0; i< 5 ; ++i)
		ts.create_thread(boost::bind(&other, boost::ref(s),i));
	ts.create_thread(boost::bind(&waiter, boost::ref(s)));
	Sleep(6000);
	s.do_fulllock();
	for (int i = 0; i< 5 ; ++i)
		ts.create_thread(boost::bind(&other, boost::ref(s),0));
	cout << "Wait 1 sec.\n";
	Sleep(1000);
	s.do_fullunlock();
	ts.join_all();
}

[Finch]

Столкнулся недавно с забавным багом в QT3. Может быть в QT4 уже исправили. Я не проверял. Класс QListBox. Если у него в списке есть только 1 элемент и попытаться его удалить с помошью  члена класса removeItem. Программа вылетает с ошибкой зашиты фрагментации. Пришлось ставить ловушку:

Код:

	if ((ListOfWindow->count() == 1) && (Index == 0)) ListOfWindow->clear();
	else ListOfWindow->removeItem(Index);

[Ochkarik]

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

Код:

do{
 if (func_1(...))
   break;
 if (func_2(...))
   break;
...
}while(0);

а насчет

Код:

if (Func1(...) && Func2(.....) && Func3(....) && .......);

- для меня почему то не очевидно то что функции будут вызываються по очереди а не вперемешку))
хотя пардон... опреация && по стандарту проводится слева на право)

[Антон (LogRus)]

Ochkarik, это же по стандарту

[Алексей++]

Ochkarik, будут по очереди, у оператора &&  ассоциативность - слева направо

[Ochkarik]

да ладно ладно))))) сам посмотрел)

[Алексей++]

Ochkarik,

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

Код:

if(p && p->CheckSmth())
{
  ...
}

[Ochkarik]

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

[Алексей++]

Ochkarik, всё наглядно. Будет.

А наглядность определяется количеством этажей в строке )))

А почему не любишь то ?  Очень полезный, скажу я вам, оператор )

[Ochkarik]

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

Код:

    block[i] = buf[i]==1 ? (1.0-ep) / ep : ep / (1.0-ep);

вот еще примерчик из той же оперы...

Код:

      inline Type Func( const Type& data  )
      {
        tmp[3] = (Type)((tmp[2] = (Type)((tmp[1] = (Type)((tmp[0] = data) * b + tmp[1] * a)) * b + tmp[2] * a)) * b + tmp[3] * a);
        return tmp[N];
      }

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

[Алексей++]

Ochkarik, а ты возьми и переформатируй (только осторожно, не внося лишних символов)

кстати, когда не помню приоритеты операторов, заключаю в скобки

Код:

block[i] = (buf[i]==1 ? (1.0-ep) / ep : ep / (1.0-ep));

переформатируем -

Код:

block[i] =
(
  (buf[i]==1) ? 
  ((1.0-ep) / ep) :
  (ep / (1.0-ep))
);

или

Код:

if(buf[i]==1)
{
   block[i] =(1.0-ep) / ep;
}
else
{
   block[i] =ep / (1.0-ep);
}

а ещё бы проверить на возможное переполнение при делении , когда ep или (1.0-ep) близкО к нулю (в зависимости от того, что в знаменателе) 

[Ochkarik]

Код:

if(buf[i]==1)
   block[i] =(1.0-ep) / ep;
else
   block[i] =ep / (1.0-ep);

нагляднее. про второе - вообще молчу)

[Алексей++]

Ochkarik,что там нагляднее то ?
 я без блоковых скобок никогда if не использую, а особенно если альтернатива else есть. Вообще, блок {} - это суперское изобретение )
А твой "голый" if-else ничем от оператора "?:" не отличается...

[Алексей++]

почти фокус )  Совершенно случайно получилось, нарочно не придумаешь

Код:

struct S
{
	int n1;

	void F()
	{
		if(!this)return;
		n1=1;
	}
};

//программа не глюкает
S* ps=0;
ps->F();

[Антон (LogRus)]

Алексей1153++, это не по стандарту. небось VC++ используешь
по стандарту
оператор -> должен работать так (*ps).
а *ps тебе должен дать ошибку доступа к памяти

[Алексей++]

LogRus, всё по стандарту ) Функция то существует, хоть объекта и нету. this == 0

[Антон (LogRus)]

Алексей1153++, действительно по горячился.
Но похорошему, так делать нельзя
а вот если функция виртуальная, то точно разорвёт я проверял

[Алексей++]

LogRus, дык я и не делаю так ) Это была ошибка.  А еил нужно без объекта - всегда статическую можно приделать ведь

с виртуальной падает, я тож попробовал , там без объекта уже не найти функцию ))

[Джон]

"Ну вы блин даёте!" (с)

программа не глюкает

Дык, так она ничего и не делает! ) Вот кабы она делала и не глюкала.

[Алексей++]

Джон, как энто ничиво не делает )  Она проверяет несостоятельность своего объекта ))
(состояние нестояния)

[Джон]

"Функция несуществующего объекта, проверяет существование несуществующего объекта".

)

зы А вобще-то байка старая. Говорят в коде программеров мелкософта видели такой код

if(this==NULL)
{

}

[Serg79]

зы А вобще-то байка старая. Говорят в коде программеров мелкософта видели такой код

if(this==NULL)
{

}

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