всем привет. Как известно фукция CreateThread возвращает дескриптор созданного потока, но скажите зачем тогда нужен 6 -ой пераметр этой функции (идентификатор потока) Я думал. что это одно и тоже!

yngwie19, 
Господин Рихтер так думает:

Я думаю, что по Windows 95/98 сейчас уже никто не работает. Значит мне впринципе этот параметр не нужен и Я могу смело ставить NULL, главное это дескриптор потока который возвращает эта функций так? 

Мой тебе совет: не используй CreateThread т.к. будут небольшие утечки памяти (если юзаешь CRT). Юзай _beginthreadex.

Добавлено через 1 минуту и 23 секунды

В чем выражаются эти утечки памяти.
Я пока что тока начал разбираться с потоками поэтому в книге приводится именно эта функция. 
А что насчет 



Это сообщение отредактировал(а) yngwie19 - 31.3.2009, 17:31

 

Добавлено через 38 секунд
Ставь NULL

Добавлено через 1 минуту и 30 секунд




Добавлено через 2 минуты и 15 секунд
И внизу страницы глянь - там есть ссылки для тебя.

Alca, Спасибо. Подскажи подалуйста допустим такой участок кода

Вопрос:
1) При передаче парамметра nPar в функцию Thread(), он передается как указатель ? т.е 
2) При передаче этого параметра в функции CreateThread() мы сначала его преобразовываем в указатель что-ли? или как

Добавлено через 5 минут и 22 секунды

типа да

Добавлено через 10 минут и 45 секунд
Можно еще так:

дык здесь ты передаешь &inc как указатель типа int, а функция принимает void*. Здесь привести в void* случайно не надо?

Скомпилилось без ворнингов.

Добавлено @ 21:36
Creating Threads

Добавлено @ 21:38


Это сообщение отредактировал(а) Alca - 31.3.2009, 21:39

Alca, Спасибо, все же мне не очень понятно как можно переменную (в нашем случае int) привести в указателю.

Вот так:


Добавлено через 30 секунд
или так:

[quote=Alca, 31.3.2009,  21:45, post1829523]Вот так:

(void*)inc
или так:
&inc

Эй, Alca, вы чего?

yngwie19, 
дык здесь ты передаешь &inc как указатель типа int, а функция принимает void*. Здесь привести в void* случайно не надо? 
не надо. указатель на void "паглащает" все другие типы указателей.

 что-то не так?
Дак что получается была переменная - стал указатель и никаких проблем?

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

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

И каков же размер int в TurboC?


sizeof нужен для того, чтобы свой код сделать правильным и не зависимым от конкретного компилятора (даже не платформы).


Если вы считаете этот подход правильным - вперед с песнями и барабаном   

Другой момент, правильно написанный код с использование sizeof, при смене в компиляторе размера базового типа, вообще менять не придется. Нигде. Был int 16, затем 32, сейчас 64 будет - код будет компилироваться и работать.


Что вы. Я даже размер байта не знаю  .

Это сообщение отредактировал(а) Anikmar - 2.4.2009, 16:04

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


не понял, а при чем тут криворукость?

assert дает простой способ решать конфликты в отладочной версии,
суть не в том, что он пропускается в релизе, а в том, что в релизе его можно переопределить на нормальный выход из программы, с соответствующим уведомлением пользователя, мол "версия программы несовместима с платформой, обращайтесь по такому-то адресу, к разработчику"

ну и соответственно, если хоть раз в жизни он произойдет, то дать возможность ему отписаться тебе, что мол, "вот такая-то оч. хорошая программа, а на моей машине не работает ( , прошу учесть мои пожелания в следующих версиях"

ничего страшного в этом нет, это простой способ экономить тебе твое же время, не более

практически в любой программе существует вероятность незапланированного вылета, к примеру: файл, который является основным источником информации, на данный момент не читается (кто-то его открыл)
что делать?
1. можно подождать пока его не закроют (многопоточность, система слежения и т.п.)
2. можно предложить пользователю отменить, приостановить текущую операцию (комбинац. логика, куча проверок, условий и т.п.)
3. а можно просто остановить программу (единый механизм обработки критических ошибок и обратной связи)

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

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

GoldFinch, Anikmar, чего делите-то, не пойму
две крайности одной формальности ))

Я не сказал криворукость. Я сказал "Кривое программирование". Руки, которые это делают - могут быть золотыми.   
Именно про отладку я и сказал. Конкретно в приведенном примере проверяется  не платформа, а совпадение необходимых размеров для преобразования типа. Это я и назвал кривым программированием. Вместо того, чтобы вводить дополнительную проверку на то, что размеры нормально совпадут - просто не рисковать и делать гарантированно правильно. Это даже не платформо-зависимость, а компилеро-ззависимость.


И я про это. Никаких дополнительных затрат времени особо не будет - сразу сделать нормально. А потратить чужое время на написание гневного письма, а затем свое - на ответ (а если гневных писем будет много?   ) - вот и вспомнится экономия   
ИМХО: платформу вообще надо проверять при инсталляции. "Извините - данная версия программы не совместима с вашим ковриком для мыши" что-нибудь такое.


Так вот откуда надписи типа "Произошла внутренняя ошибка программы. Все данный будут потеряны. Если ошибка повторится свяжитесь с разработчиком". В ведро такой софт. ИМХО. Надо к таким фразам издевательскую надпись добавлять "Видите-ли, программисту было лень городить огород- так как основное время он потратил на другой функционал, но он с удовольствием выслушает ваши претензии"   



Да ничего мы не делим. У каждого свой подход и свой взгляд на жизнь. Я чистой воды прикладник, писал вещи узкоспециализированные и заказные. Напрямую общался с конкретными пользователями и очень хорошо знаю претензии типа "Эту кнопку надо по-другому назвать, а  вот это поставить в левый нижний угол". Уровень моих пользователей - это при слове файл, они сразу думали про пластиковый конвертик. И вариант "напишите разработчику" у меня не прокатывает никак. Первый мой принцип - максимальная дуракоустойчивость".

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


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


какие данные? если софт в принципе не для этой платформы, какие он там данные-то успел навоять?
ну, можно поздравить его, коли так, мол мы даже не подозревали о таких скрытых вохможностях нашей программы, такую поддержку мы намечали только в n-ой версии продукта

Ну вот, завел вас похоже.    Объясню кривость такого подхода: Совместимость платформ проверяется на этапе инсталяции, но никак не при запуске основного софта. Т.е. идиот пользователь (ну они же все идиоты - к менеджерам их, пусть там разбираются) сидит и развлекается созерцанием инсталяции, затем жамкает кнопку "Запустить" (образно), а ему вежливый ответ: "видишь ли дурачок, у тебя не та платформа".
Опять таки к конкретно этому примеру: ну никак не должен софт зависеть от разницы в размерах int и указателя - хоть тресни. Останусь при своем ИМХО и не буду больше на эту тему спорить.


Каким образом ветвления влияют на аккуратность в преобразованиях и соблюдение чистоты кода? Напротив, чем сложнее задача, тем лучше придерживаться одного стиля.


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


Сам во всех ипостасях - очень просто так как фрилансер.

Согласен с  Anikmar, 
для переносимости кода необходимо использовать sizeof() там где это нужно. 
Для тех кто в "танке" и не хочет выходить от туда почитайте хотябы эту статью
20 ловушек переноса Си++ - кода на 64-битную платформу

Dem_max, а при чем тут х64 ? там чтоли sizeof(int)!=sizeof(void*) ?

да x64 тут особо не причем, но статья хорошая. 

для некоторых платформ да.