C ++ - Передача объекта в CreateThread () по ссылке

Question

C ++ - Передача объекта в CreateThread () по ссылке

0

Я не уверен, какой правильный синтаксис для этого, потому что он включает winapi, с которым я не знаком. Например, я не знал, что это не позволит мне xhangethe предопределенные параметры функции потока от processClient (LPVOID) к processClient (LPVOID &).

Мне нужно передать объект "params" по ссылке (просто потому, что на данный момент проблем нет, даже если im не собирается изменять значения в нем) для функции потока "processClient()".

... struct(the object) declaration
struct ClientParams{

    ClientParams::ClientParams():sock(INVALID_SOCKET), i(NULL){};

public:
    SOCKET sock;
    int i;
};

... in processClient(LPVOID lpParam){
    SOCKET ClientSocket=(SOCKET)*lpParam->sock; ?? doesnt work
    int i=*lpParam->i; ?? doesn't work
}
... in main{
ClientParams *params = new ClientParams();
params->i=some_value;
params->sock=ClientSocket;
CreateThread(
            NULL,                       // don't inherit handle
            0,                          // use default size for the executable
            processClient,
            (LPVOID)params,             // thread data
            0,                          // run right away
            &i );
}

shawn a 24 дек. 2013, в 03:10

Источник

0

Я предлагаю вместо этого использовать std::thread для простоты, но это уже указатель, поэтому просто передайте указатель на то, что вам нужно, и преобразуйте его в тот же указатель внутри.
chris 24 дек. 2013, в 02:07
0

SOCKET ClientSocket = ((ClientParams*)lpParam)->sock; - базовый C ++. Возможно, многопоточное сетевое приложение не совсем подходит для первого проекта.
IInspectable 24 дек. 2013, в 02:10
0

@IInspectable, вы разыменовываете пустой указатель. В любом случае, вы имеете в виду C. C ++ действительно имеет лучшие способы, чем пустые указатели.
chris 24 дек. 2013, в 02:11
0

@ chris Вы не можете использовать C ++ при вызове C API ...
IInspectable 24 дек. 2013, в 02:14
0

@IInspectable, я имею в виду метод использования пустых указателей в качестве параметров данных. Он возник из C, и я не могу вспомнить время, когда я предпочел бы сделать это, чем использовать более безопасный и простой метод C ++ для достижения того же самого. Таким образом, я сравниваю это с изучением C-строк вместо std::string или ручным управлением памятью вместо утилит на основе RAII. Очевидно, что гораздо больше C-like, и программисты на C ++ обычно так не поступают. В любом случае наиболее подходящим способом C ++ для этой конкретной задачи является стандартная библиотека потоков, которая также лучше обрабатывает параметры данных.
chris 24 дек. 2013, в 02:16
0

@chris Этот вопрос помечен как [winapi]. Наиболее C ++ способ для этой конкретной задачи - вызвать интерфейс C. И поскольку этот вопрос помечен [winapi], стандартная библиотека потоков, безусловно, намного менее способна, чем собственные примитивы синхронизации.
IInspectable 24 дек. 2013, в 02:28
0

@IInspectable, намного менее способный? Простая строка для создания объекта и передачи данных, независимо от того, какие у него функции, и тогда вы можете получить HANDLE для него в любое время, когда вам нужно сделать что-то, чего он не предлагает (хотя у Boost есть interrupt и еще много чего). Снаружи это намного проще, и возможность получить ручку позволяет делать все возможное с вызовами winapi.
chris 24 дек. 2013, в 02:31
0

@IInspectable, Во всяком случае, конечно, можно использовать C ++ в некоторой степени при работе с C API. Дескриптор потока является одним из примеров, но также подумайте об использовании вектора, передавая прямую память вместо самого вектора, и продолжая то, для чего вы использовали его ранее. Вопрос также помечен C ++, поэтому я не понимаю, почему стандарт C ++ автоматически не применяется. Насколько я знаю, OP хотел бы использовать std::thread , но никогда не знал, что он существует.
chris 24 дек. 2013, в 02:35
0

CreateThread не должен использоваться, поскольку он утечет, также вы теряете дескриптор, который он возвращает, и не проверяете, действительно ли работало создание потока
paulm 24 дек. 2013, в 09:06
0

@paulm CreateThread не пропускает. Что заставляет вас думать, что это будет? И что бы вы предложили вместо этого? И как эта предложенная превосходная альтернатива - которая в конечном счете вызывает сам CreateThread - волшебным образом устраняет утечку из API, который она не контролирует?
IInspectable 24 дек. 2013, в 10:50
0

Это приводит к утечке, если вы используете CRT - что делает большинство людей. stackoverflow.com/questions/331536/...
paulm 24 дек. 2013, в 11:26
0

@paulm _beginthreadex вызывает CreateThread . Так что, если CreateThread вызывает утечку, то _beginthreadex . Ни то, ни другое не правда. _beginthread[ex] требуется для установки состояния для каждого потока, например, errno , locale, среды с плавающей запятой и т. д. Неспособность вызвать _beginthread[ex] не приводит к утечке. Он просто вызывает неопределенное поведение при вызове одной из функций CRT, которые требуют состояния для каждого потока.
IInspectable 24 дек. 2013, в 12:25
0

CreateThread () не будет течь, но все равно будет утечка памяти: support.microsoft.com/kb/104641/en-us
paulm 24 дек. 2013, в 12:47
0

@paulm Другими словами: CRT теряет память при использовании в потоке, который не был подготовлен для запуска кода из CRT. Это не так уж удивительно. Вызов CreateThread совершенно безопасен, надежен и никогда не пропускает.
IInspectable 24 дек. 2013, в 12:52
0

Поскольку он использует CRT у него есть утечка памяти, поэтому в любом нормальном приложении win32 , который использует CRT я бы не сказал его « в целости и сохранности» , поскольку его использование может привести к утечке памяти.
paulm 24 дек. 2013, в 12:58
0

@paulm Престижность за чтение мысли ОП. Я не вижу определения processClient поэтому я не могу знать, выполняет ли он код CRT в потоке. Дело в том, что CreateThread не протекает и не является небезопасным. Если вы хотите использовать CRT, убедитесь, что играете по правилам.
IInspectable 24 дек. 2013, в 13:10
0

Он использует оператор new, поэтому мне не нужно читать его мысли, оператор new предоставляется CRT.
paulm 24 дек. 2013, в 13:14
0

@paulm Вы неверно истолковали правила. Правила таковы, что вы должны инициализировать CRT в потоке, если этот поток использует CRT . operator new не вызывается для рассматриваемого потока; вызов CreateThread может быть совершенно безопасным. С предоставленной информацией мы точно не знаем, так или иначе. В сторону: operator new не предоставляется CRT. Однако он вызывает malloc и может выдавать исключения - оба они реализованы в CRT.
IInspectable 24 дек. 2013, в 13:25
0

Что дает оператору новый? Если я создаю приложения без CRT, я должен определить свое собственное, обычно вызывая HeapAlloc ().
paulm 24 дек. 2013, в 13:43
0

давайте продолжим эту дискуссию в чате
IInspectable 24 дек. 2013, в 13:51

Показать ещё 18 комментариев

Теги:

c++

winapi

2 ответа

0

Элементы структуры доступа должны через структуру.

SOCKET ClientSocket=((ClientParams*)lpParam)->sock;

Lange 24 дек. 2013, в 04:14

Ещё вопросы

Я предлагаю вместо этого использовать std::thread для простоты, но это уже указатель, поэтому просто передайте указатель на то, что вам нужно, и преобразуйте его в тот же указатель внутри.
SOCKET ClientSocket = ((ClientParams*)lpParam)->sock; - базовый C ++. Возможно, многопоточное сетевое приложение не совсем подходит для первого проекта.
@IInspectable, вы разыменовываете пустой указатель. В любом случае, вы имеете в виду C. C ++ действительно имеет лучшие способы, чем пустые указатели.
@ chris Вы не можете использовать C ++ при вызове C API ...
@IInspectable, я имею в виду метод использования пустых указателей в качестве параметров данных. Он возник из C, и я не могу вспомнить время, когда я предпочел бы сделать это, чем использовать более безопасный и простой метод C ++ для достижения того же самого. Таким образом, я сравниваю это с изучением C-строк вместо std::string или ручным управлением памятью вместо утилит на основе RAII. Очевидно, что гораздо больше C-like, и программисты на C ++ обычно так не поступают. В любом случае наиболее подходящим способом C ++ для этой конкретной задачи является стандартная библиотека потоков, которая также лучше обрабатывает параметры данных.
@chris Этот вопрос помечен как [winapi]. Наиболее C ++ способ для этой конкретной задачи - вызвать интерфейс C. И поскольку этот вопрос помечен [winapi], стандартная библиотека потоков, безусловно, намного менее способна, чем собственные примитивы синхронизации.
@IInspectable, намного менее способный? Простая строка для создания объекта и передачи данных, независимо от того, какие у него функции, и тогда вы можете получить HANDLE для него в любое время, когда вам нужно сделать что-то, чего он не предлагает (хотя у Boost есть interrupt и еще много чего). Снаружи это намного проще, и возможность получить ручку позволяет делать все возможное с вызовами winapi.
@IInspectable, Во всяком случае, конечно, можно использовать C ++ в некоторой степени при работе с C API. Дескриптор потока является одним из примеров, но также подумайте об использовании вектора, передавая прямую память вместо самого вектора, и продолжая то, для чего вы использовали его ранее. Вопрос также помечен C ++, поэтому я не понимаю, почему стандарт C ++ автоматически не применяется. Насколько я знаю, OP хотел бы использовать std::thread , но никогда не знал, что он существует.
CreateThread не должен использоваться, поскольку он утечет, также вы теряете дескриптор, который он возвращает, и не проверяете, действительно ли работало создание потока
@paulm CreateThread не пропускает. Что заставляет вас думать, что это будет? И что бы вы предложили вместо этого? И как эта предложенная превосходная альтернатива - которая в конечном счете вызывает сам CreateThread - волшебным образом устраняет утечку из API, который она не контролирует?
Это приводит к утечке, если вы используете CRT - что делает большинство людей. stackoverflow.com/questions/331536/...
@paulm _beginthreadex вызывает CreateThread . Так что, если CreateThread вызывает утечку, то _beginthreadex . Ни то, ни другое не правда. _beginthread[ex] требуется для установки состояния для каждого потока, например, errno , locale, среды с плавающей запятой и т. д. Неспособность вызвать _beginthread[ex] не приводит к утечке. Он просто вызывает неопределенное поведение при вызове одной из функций CRT, которые требуют состояния для каждого потока.
CreateThread () не будет течь, но все равно будет утечка памяти: support.microsoft.com/kb/104641/en-us
@paulm Другими словами: CRT теряет память при использовании в потоке, который не был подготовлен для запуска кода из CRT. Это не так уж удивительно. Вызов CreateThread совершенно безопасен, надежен и никогда не пропускает.
Поскольку он использует CRT у него есть утечка памяти, поэтому в любом нормальном приложении win32 , который использует CRT я бы не сказал его « в целости и сохранности» , поскольку его использование может привести к утечке памяти.
@paulm Престижность за чтение мысли ОП. Я не вижу определения processClient поэтому я не могу знать, выполняет ли он код CRT в потоке. Дело в том, что CreateThread не протекает и не является небезопасным. Если вы хотите использовать CRT, убедитесь, что играете по правилам.
Он использует оператор new, поэтому мне не нужно читать его мысли, оператор new предоставляется CRT.
@paulm Вы неверно истолковали правила. Правила таковы, что вы должны инициализировать CRT в потоке, если этот поток использует CRT . operator new не вызывается для рассматриваемого потока; вызов CreateThread может быть совершенно безопасным. С предоставленной информацией мы точно не знаем, так или иначе. В сторону: operator new не предоставляется CRT. Однако он вызывает malloc и может выдавать исключения - оба они реализованы в CRT.
Что дает оператору новый? Если я создаю приложения без CRT, я должен определить свое собственное, обычно вызывая HeapAlloc ().
давайте продолжим эту дискуссию в чате

user207421 · Accepted Answer · 2013-12-24T01-48-00.000Z

SOCKET ClientSocket = (SOCKET) * lpParam-> носок; ?? не работает

lpParam имеет то же значение, что и при его передаче, в основном, где это были "params", типа "ClientParams", поэтому у вас нет никакого бизнеса, разыгрывающего его с помощью "*". Остальная часть - это просто проблема с приоритетом. Должен быть

SOCKET ClientSocket=((ClientParams*)lpParam)->sock;

Спасибо! Параметры пустоты в винапе смутили меня.