The QtService component is useful for developing Windows services and Unix daemons.
The project provides a QtService template class that can be used to implement service applications, and a QtServiceController class to control a service.
On Windows systems the implementation uses the Service Control Manager.
On Unix systems services are implemented as daemons.
The QtSingleApplication component provides support for applications that can be only started once per user.
For some applications it is useful or even critical that they are started only once by any user. Future attempts to start the application should activate any already running instance, and possibly perform requested actions, e.g. loading a file, in that instance.
The QtSingleApplication class provides an interface to detect a running instance, and to send command strings to that instance.
For console (non-GUI) applications, the QtSingleCoreApplication variant is provided, which avoids dependency on QtGui.
QThread was designed and is intended to be used as an interface or a control point to an operating system thread, not as a place to put code that you want to run in a thread. We object-oriented programmers subclass because we want to extend or specialize the base class functionality. The only valid reasons I can think of for subclassing QThread is to add functionality that QThread doesn’t have, e.g. perhaps providing a pointer to memory to use as the thread’s stack, or possibly adding real-time interfaces/support. Code to download a file, or to query a database, or to do any other kind of processing should not be added to a subclass of QThread; it should be encapsulated in an object of it’s own.
// create the producer and consumer and plug them together
Producer producer;
Consumer consumer;
bool bOk = producer.connect(&consumer,
SIGNAL(consumed()),
SLOT(produce()));
Q_ASSERT(bOk);
bOk = consumer.connect(&producer,
SIGNAL(produced(QByteArray *)),
SLOT(consume(QByteArray *)));
Q_ASSERT(bOk);
// they both get their own thread
QThread producerThread;
producer.moveToThread(&producerThread);
QThread consumerThread;
consumer.moveToThread(&consumerThread);
// go!
producerThread.start();
consumerThread.start();
Reference: Threading without the headache or QThread’s no longer abstract (see attached file)
#include <vector>
#include <string>
#include <iostream>
#include <fstream>
#include <algorithm>
#include <iterator>
int main(int argc, char* argv[])
{
std::vector<std::string> v;
std::ifstream f("e:/test.txt");
if(f.is_open())
{
std::copy(std::istream_iterator<std::string>(f),
std::istream_iterator<std::string>(),
std::back_inserter(v));
}
// проверка
std::copy(v.begin(), v.end(),
std::ostream_iterator<std::string>(std::cout, "\n"));
return 0;
}
#define YEAR ((((__DATE__ [7] - '0') * 10 + (__DATE__ [8] - '0')) * 10 \
+ (__DATE__ [9] - '0')) * 10 + (__DATE__ [10] - '0'))
#define MONTH (__DATE__ [2] == 'n' ? 0 \
: __DATE__ [2] == 'b' ? 1 \
: __DATE__ [2] == 'r' ? (__DATE__ [0] == 'M' ? 2 : 3) \
: __DATE__ [2] == 'y' ? 4 \
: __DATE__ [2] == 'n' ? 5 \
: __DATE__ [2] == 'l' ? 6 \
: __DATE__ [2] == 'g' ? 7 \
: __DATE__ [2] == 'p' ? 8 \
: __DATE__ [2] == 't' ? 9 \
: __DATE__ [2] == 'v' ? 10 : 11)
#define DAY ((__DATE__ [4] == ' ' ? 0 : __DATE__ [4] - '0') * 10 + (__DATE__ [5] - '0'))
#define DATE_AS_INT (((YEAR - 2000) * 12 + MONTH) * 31 + DAY)
int main (void)
{
printf ("%d-%02d-%02d = %d\n", YEAR, MONTH + 1, DAY, DATE_AS_INT);
return 0;
}
static LPTOP_LEVEL_EXCEPTION_FILTER m_previousFilter = NULL;
typedef BOOL (WINAPI *MINIDUMPWRITEDUMP)(HANDLE hProcess, DWORD dwPid, HANDLE hFile, MINIDUMP_TYPE DumpType,
CONST PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,
CONST PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,
CONST PMINIDUMP_CALLBACK_INFORMATION CallbackParam);
static LONG WINAPI MyUnhandledExceptionFilter(PEXCEPTION_POINTERS pExceptionInfo)
{
HMODULE hDll = ::LoadLibrary(_T("DBGHELP.DLL"));
MINIDUMPWRITEDUMP pDump = (MINIDUMPWRITEDUMP)::GetProcAddress(hDll, "MiniDumpWriteDump");
_MINIDUMP_EXCEPTION_INFORMATION ExInfo;
ExInfo.ThreadId = ::GetCurrentThreadId();
ExInfo.ExceptionPointers = pExceptionInfo;
ExInfo.ClientPointers = NULL;
MINIDUMP_CALLBACK_INFORMATION mci;
// HANDLE hFile - minidamp file name(for example, "test.dmp")
BOOL bOK = pDump(::GetCurrentProcess(), ::GetCurrentProcessId(),
hFile, 1, &ExInfo, NULL, &mci);
}
void main()
{
// setup our own ExceptionHandler
m_previousFilter = SetUnhandledExceptionFilter(MyUnhandledExceptionFilter);
// actial work
// befoe exit
if (m_previousFilter)
{
SetUnhandledExceptionFilter(m_previousFilter);
}
}
uint8_t num_of_bits32(uint32_t _arg)
{
_arg = (_arg & 0x55555555L) + ((_arg >> 1) & 0x55555555L);
_arg = (_arg & 0x33333333L) + ((_arg >> 2) & 0x33333333L);
_arg = (_arg + (_arg >> 4)) & 0x0F0F0F0FL;
_arg = _arg + (_arg >> 8);
return (uint8_t)(_arg + (_arg >> 16)) & 0x3F;
}
or
int count1(int t)
{
__asm
{
mov edx,t
mov eax, 0
cycle : bsf ecx, edx
jz finish
inc eax
inc ecx
shr edx, cl
jmp cycle
finish:
}
}
The goal of this article is to describe a more or less generic way to access .NET managed object from a native C++ application.
The goal of this article is to describe a more or less generic way to access .NET managed object from a native C++ application. I will present a dynamic link library (dll) which can be used, for example, to augment legacy C++ applications with the power of managed code. The library is written in C++/CLI which is the only .NET language which can be used to accomplish such a task.
All code was written with Visual C++ 2008, it’s also possible to do this with previous versions of the Microsoft C++ compilers, but Microsoft has done a lot of changes to C++/CLI for VS 2008, so it’s now much easier to use than in older version.
The “more” generic in the first sentence means that the library can be used to call any function (with an unlimited amount of parameters) of any managed class. The “less” means that the parameter types are limited to the native C++ types and a few user defined types (string, date/time, …). It’s easy to provide support for your own types, but therefore the code for the dll has to be extended by yourself.
Автор: Александр Шарахов
Предлагаю вашему вниманию еще один подход к построению алгоритмов вычисления CRC32. Хотя многие использованные в нем идеи в той или иной мере содержатся в известных руководствах по оптимизации кода для IA32 и вычислению CRC32, он может представлять некоторый интерес. Использование свойств CRC-арифметики позволило разработать алгоритм вычисления CRC32, имеющий производительность в 3-5 раз выше стандартной табличной реализации. Например, на компьютере с процессором E6850/3.2GHz он расходует 1.33 такта процессора на байт, т.е. скорость обработки данных при вычислении CRC32 составляет 0.75 байта за такт центрального процессора или 2.4*10^9 байтов в секунду.
In modern versions of Windows (XP, Vista, and beyond), the API call SetForegroundWindow() will bring the specified window to the foreground only if it’s owned by the calling thread. The following code removes this limitation and provides a workaround:
void NewSetForegroundWindow(HWND hWnd)
{
if (GetForegroundWindow() != hWnd)
{
DWORD dwMyThreadID = GetWindowThreadProcessId(GetForegroundWindow(), NULL);
DWORD dwOtherThreadID = GetWindowThreadProcessId(hWnd, NULL);
if (dwMyThreadID != dwOtherThreadID)
{
AttachThreadInput(dwMyThreadID, dwOtherThreadID, TRUE);
SetForegroundWindow(hWnd);
SetFocus(hWnd);
AttachThreadInput(dwMyThreadID, dwOtherThreadID, FALSE);
}
else
{
SetForegroundWindow(hWnd);
}
if (IsIconic(hWnd))
{
ShowWindow(hWnd, SW_RESTORE);
}
else
{
ShowWindow(hWnd, SW_SHOW);
}
}
}
Another (but more intrusive and restrictive) way to make SetForegroundWindow() behave the same way as it did on Windows 95 and Microsoft Windows NT 4.0 is to change the foreground lock timeout value SPI_SETFOREGROUNDLOCKTIMEOUT, as described in this MSDN document.
