yngwie19, 
это же C++ - "делай шо хочешь"
соответственно, если этот указатель превратить обратно в переменную целого типа, то проблем никаких и не будет.

int и указатель не одно и тоже. Никто не гарантирует, что они будут одинакового размера. Передавать int в указателе считаю неправильным.

Тогда по ссылке

Правильно будет передавать только адрес.

Функция требует void* - значит ей надо передать любой указатель. Нельзя помещать в указатель другую информацию.

Я бы понял если бы речь шла о кроссплатформенности, и то, размер указателя всегда больше или равен размеру int
Но речь идет о системной функции win32, и тут рассуждения о размере int и размере указателя совершенно бессмысленны, т.к. туда надо передавать только 4-байтовые значения, как int так и указателей

Система не различает, указатели или значения передаются callback'ам, т.к. они просто копируются.
Более того, кроме C++ программы под win32 можно писать и на других языках программирования, например на *asm, так вот учитывая правила написания программ под win32 вообще, безотносительно языка программирования, в CreateThread параметром потоку можно передавать любые 4 байта.

Это сообщение отредактировал(а) GoldFinch - 1.4.2009, 08:53

Я имею в виду не конкретно данную ситуацию, а подход вцелом. 
ИМХО. Если требуется указатель - надо передавать указатель, а не использовать левые преобразования

Anikmar, а при чем тут подход в целом? тут вполне конкретный случай
и указатель там не требуется, это в заголовочных файлах С++ написано что указатель, а в заголовочных файлах для других языков, там не указатель

ИМХО
Есть интерфейс. Интерфейсу требуется указатель. Вот и надо его передать. Если рассматривать частные случаи, то С++ позволит сделать практически все. Я за общий подход, поэтому за то, чтобы не передавать в указателях целые параметры. И рассматривать заголовочные файлы других языков - это не разговор. Что за функция конкретно вызывается из exe, скомпилированного на С++ и какая из exe других языков заранее мы знать не можем. Конкретно в данном случае - известная функция, всем известно что она делает и я полностью согласен, что никакого вреда в этом случае не будет. Но лично я придерживаюсь другого стиля.
Опять-таки ИМХО

там еще float можно передать

вызов-то ее размещен в .exe, а сама-то функция во внешней .dll
кроме того, в ее интерфейсе указано соглашение вызова, stdcall, так вот согласно соглашению вызова stdcall разницы между указателем, целочисленным 4-байтовым значением, или любым другим 4-байтовым значением нет. 
и язык программирования, раз указано конкретное соглашение вызова, тут совершенно ни при чем.

Anikmar, все верно, пока речь не идет о производительности
так можно и не дойти до решения основной задачи,
а даже если дойти, то код уже будет неэффективным

ради справедливости, можешь поставить перед вызовом функции 

и все проблемы решатся:
и совместимость не нарушена
и не нужно плодить лишний код

ИМХО, такого рода перестраховки - просто тараканы, о которых ты забудешь, как только начнешь задумываться о том, как сильно они сказываются на твоем КПД

Добавлено через 9 минут и 30 секунд
GoldFinch, слишком много ненужных подробностей,
и stdcall тут ни при чем: выравнивание стека параметров не равно размеру элемента, это всего лишь лишь его кратность

Сначала обсуждали конкретный пример, теперь речь о производительности. В данном конкретном случае никакого выигрыша по производительности заметно не будет.


Закладывать в свой код предположение о размере указателя и целого числа как 4 байта я и считаю отступлением от общего нормального подхода. Сколько байт точно вешать знает только sizeof. Если говорить о stdcall то данный модификатор лишь объявляет соглашение о вызове функции в совместимом с win32 формате. Никаких 4, а также 5, 6 или 8 байт он не предусматривает.
Соглашение лишь о порядке следования параметров и о способе передаче параметров по значению:
MSDN:



ИМХО. Данная вещь хороша при отладке. А закладывать в код вероятность вылета из-за кривого программирования - тут, конечно, дело вкуса, но не проще ли предусмотреть нормальную работу в любом варианте - тем более здесь не требуется особых наворотов.


Это не перестраховка, а просто мое мнение (и не только мое, кстати), что конструкций вида


Нужно избегать. 

ИМХО.

Anikmar, будет выигрыш не только по производительности, но и по безопасности, не надо обеспечивать время жизни указателя на все время жизни потока

это в кроссплатформенном С\С++ это нормальный подход
а при работе с конкретной платформой, всегда надо знать и учитывать численные характеристики платформы


там в msdn написано далеко не все

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

Я привел только то, что касается непосредственно темы обсуждения.

У меня сложилось впечатление, что вы большой приверенженец ассемблера и из-за этого достаточно яростно отстаиваете подходы, которые часто применяют именно ASM-программеры. Касаемо текущего обсуждения общий фон такой: Да, это вроде как не совсем правильно, но в конкретном этом случае можно. Я же изначально сказал, что в общем (а не конкретном) подходе так делать не рекомендуют, и я сам так не делаю. Хотя бы из-за того, что код для виндов также должен переносится в более свежие версии и нужно делать максимально меньше подозрительных крякозябр. В этом случае ничего не произойдет, зато в другом случае можно потратить неделю на поиск ошибки. Легче приучить себя изначально делать правильно - и все будет ок.



Знать, учитывать и использовать - совершенно разные вещи. Я к кросс-платформенности отношусь с большим скепсисом. ИМХО нельзя написать по-настоящему хорошее, удобное, оптимизированное кросс-платформенное приложение. В данном же конкретном случае это не к кроссплатформенности относится, а к стилю программирования на C++. К преобразованию типов надо всегда подходить очень ответственно.


Производительность оставим в покое. А вот по поводу обеспечения времени жизни - все зависит от конкретной задачи. Если создаваемому потоку достаточно парметра int это одно, если надо чего-то больше, то все равно надо обеспечивать необходимое время жизни. И писать в одном случае так, а в другом этак - дело, конечно вкуса, но не мой стиль точно.
ИМХО, однако.

Anikmar, да при чем тут асм? я еще когда кодил только на турбопаскале\делфи уже знал сколько байт какая переменная занимает
а вы подозреваю это все никак не можете запомнить вот и говорите про sizeof

sizeof для простых типов данных нужен если вам надо менять строчку
  typedef float MyData;
на
  typedef double MyData;
чтобы не менять везде *4 на *8

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