- 1
- 2
- 3
- 4
- 5
- 6
- 7
HRESULT SomeClass::GetVersion(std::wstring& version)
{
CComBSTR versionBstr;
m_Interface->get_Version(&versionBstr);
version = std::move(std::wstring((_bstr_t)versionBstr, versionBstr.Length()));
return S_OK;
}
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+2
HRESULT SomeClass::GetVersion(std::wstring& version)
{
CComBSTR versionBstr;
m_Interface->get_Version(&versionBstr);
version = std::move(std::wstring((_bstr_t)versionBstr, versionBstr.Length()));
return S_OK;
}
Как показать в одном методе (не)знание move семантики, правил приведения типов и COM фреймворка
Такого не знать.
Как классы в реестре регистрируются? Как сервера создаются отдельно стоящие или внутри процесса? Как через IDL клиенты создаются?
по этому я за линух и форки.
Взял "пхп" файл, положил в папку, которую "апач" видит и всё готово.
Поэтому я за "пхп".
Ну да, процессы понятнее и безопаснее этих ваших "тредов".
Разве? Процесс (в виндах) — это же просто обёртка над группой потоков, как он может быть легче?
Между процессами же шарятся только те данные, которые ты реально хочешь расшарить.
Но победили унылые и менее гибкие треды.
Но ведь это не из-за того, что в венде треды хорошие. Там просто процессы очень медленно стартуют. Форк, конечно, очень странная идея, но позволяет запускать процессы уже прогретыми.
А тред, по сути, тот же форк, только вся память в режиме shared.
> хочет видеть процессы
А видит там вкладки хрома.
Х.з., добавить exec'нутым какой-нибудь флажок?
Я вот с процессами основную траблу вижу в управлении памятью. Если на 64-битке ещё можно себе позволить отдать половину пространства под shared и половину под private, то на 32-битке с этим будет боль. А shared память хотелось бы видеть по одинаковым адресам во всех процессах, которые её юзают.
Используй линупсовый системный вызов clone для максимальной гибкости:
> clone() creates a new process, in a manner similar to fork(2).
> This page describes both the glibc clone() wrapper function and the underlying system call on which it is based. The main text describes the wrapper function; the differences for the raw system call are described toward the end of this page.
> Unlike fork(2), clone() allows the child process to share parts of its execution context with the calling process, such as the virtual address space, the table of file descriptors, and the table of signal handlers. (Note that on this manual page, "calling process" normally corresponds to "parent process". But see the description of CLONE_PARENT below.)
В glibc для Linux эти pthread-ы как раз через clone() и реализованы
это же SUS
зы: а крузис и батлфилд где запускать-то?
irq[1] = function() { ... }