CreateThread: возможно ли запустить не статический метод класса?

Возможно ли в CreateThread запустить не static процедуру класса?
как-то так

0

oleg-m1973, так а разве при принудительном выходе программа не закроектся без ожидания?

0

Сообщение от ReYalp oleg-m1973, так а разве при принудительном выходе программа не закроектся без ожидания?

Если ты сделаешь процессу kill, то закроется. Если ты штатно останавливаешь процесс, т.е. закрываешь главное окно или делаешь Ctr+C, то процесс должен подождать пока завершатся все его потоки.

Добавлено через 8 минут

Сообщение от oleg-m1973 Если ты штатно останавливаешь процесс, т.е. закрываешь главное окно или делаешь Ctr+C, то процесс должен подождать пока завершатся все его потоки.

Вернее - будет лучше, если ты подождёшь, пока завершаться все твои потоки перед тем как сделать return из функции main. Сам по себе процесс не будет ничего ждать, закроет их и всё

1

Сообщение от ReYalp а что делать в этом случае?

Ваш процесс не просто так убить хотят. Смиритесь.

2

Сообщение от DrOffset Потому что void * p в общем случае не обязан быть такого же размера, что и class_s * ps.

пруф?

0

Сообщение от hoggy пруф?

Драфт С 2011:

6.2.5 Types ... 28 A pointer to void shall have the same representation and alignment requirements as a pointer to a character type.48) Similarly, pointers to qualified or unqualified versions of compatible types shall have the same representation and alignment requirements. All pointers to structure types shall have the same representation and alignment requirements as each other. All pointers to union types shall have the same representation and alignment requirements as each other. Pointers to other types need not have the same representation or alignment requirements. _____ 48) The same representation and alignment requirements are meant to imply interchangeability as arguments to functions, return values from functions, and members of unions.

В стандарте С об этом вообще прямым текстом написано.
Подробности в C FAQ: http://c-faq.com/null/machexamp.html
Дополнительно выделил очень ценное пояснение⁴⁸⁾ о том, что совместимость представления и требований к выравниванию означает для аргументов функции. Совершенно очевидно, что мы не можем закладываться на такую совместимость в случае с void * и остальными указателями.

В стандарте С++: http://eel.is/c++draft/basic.compound#5

A pointer to cv-qualified ([basic.type.qualifier]) or cv-unqualified void can be used to point to objects of unknown type. Such a pointer shall be able to hold any object pointer. An object of type cv void* shall have the same representation and alignment requirements as cv char*.

меньше конкретики, но все равно to hold, как видно из текста, не означает при этом то же representation и alignment requirement, что и у остальных указаталей.

3

Сообщение от DrOffset В стандарте С об этом вообще прямым текстом написано.

Сообщение от DrOffset 6.2.5 Types ... 28 A pointer to void shall have the same representation and alignment requirements as a pointer to a character type.48) Similarly, pointers to qualified or unqualified versions of compatible types shall have the same representation and alignment requirements. All pointers to structure types shall have the same representation and alignment requirements as each other. All pointers to union types shall have the same representation and alignment requirements as each other. Pointers to other types need not have the same representation or alignment requirements.

здесь же черным по белому написано,
что void* и вообще все указатели на данные
имеют те же требования, что и char*,
не?

Сообщение от DrOffset Совершенно очевидно, что мы не можем закладываться на такую совместимость в случае с void * и остальными указателями.

не очевидно, с чего ты взял свою очевидность.

под "остальные типами" :

Сообщение от DrOffset Pointers to other types need not have the same representation or alignment requirements.

подразумеваются те разновидности указателей,
что не были перечислены выше по тексту.

то бишь такие указатели, которые не являются:

Сообщение от DrOffset pointer to void

Сообщение от DrOffset pointer to a character type.

Сообщение от DrOffset All pointers to structure types

Сообщение от DrOffset All pointers to union types

таким образом, "остальные типы" - это например, указатель-на-функцию-член.

0

Сообщение от hoggy вообще все указатели на данные

Где именно выделенное написано?

Собственно твои возражения никак ничего не меняют. В стандарте написано, что указатели на структуры все между собой имеют одинаковое внутреннее представление, но не написано, что указатели на void имеют такое же внутреннее представление, что и указатели на структуры или любые другие типы. Единственное что написано, что он имеет такое же внутреннее представление, что и указатель на char.
А формулировка "способен хранить" не накладывает никаких требований на одинаковое при этом внутреннее представление, что подтверждается примерами из C FAQ.

1

Сообщение от DrOffset Где именно выделенное написано?

может быть я перевожу коряво.

вот здесь:

Сообщение от DrOffset Similarly, pointers to qualified or unqualified versions of compatible types shall have the same representation and alignment requirements.

"совместимые указатели, пофигу на квалификатор, имеют одинаковые требования"

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

вот здесь:

Сообщение от DrOffset All pointers to structure types shall have the same representation and alignment requirements as each other.

"все указатели на объекты-структур должны иметь те же требования, как и для других"

"как и для других" - выше описанных.
это вытекает из контекста.
не?

здесь не сказано, что для всех указателей-на-объекты-структур одинаковые требования.
здесь сказано, что для всех указателей-на-объекты-структур требования такие же,
как и для прочих (выше описанных, что вытекает из контекста) типов.

0

Сообщение от hoggy "совместимые указатели, пофигу на квалификатор, имеют одинаковые требования"

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

Сообщение от hoggy "все указатели на объекты-структур должны иметь те же требования, как и для других"

Вот как раз что такое each other похоже и является ключевым.
Я считаю, что other - это другие указатели на структуры, а не вообще все указатели. Ты считаешь, что это ссылка на вышеописанные указатели на char* и void*. Если это действительно так, то непонятно зачем так мудрено писать, отдельно выделять структуры, отдельно cv группы совместимых типов, когда можно было написать это одним простым предложением?

Добавлено через 39 минут
hoggy, ладно, давай вообще оставим в покое этот each other, допустим даже, что ты верно понял, а я нет.

Но все равно, вот читаем:

Similarly, pointers to qualified or unqualified versions of compatible types shall have the same representation and alignment requirements.

1) Типы должны быть совместимыми, чтобы указатели могли считаться совместимыми.
Теперь такой вопрос: int, например, и double - это совместимые типы? Нет (надеюсь с этим-то никто спорить не станет).
значит эта ситуация попадает под other types == (несовместимые типы и не структуры и не объединения), поэтому идем в конец и читаем:

Pointers to other types need not have the same representation or alignment requirements.

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

2) Теперь допустим, что ты понял верно и все указатели на структуры совместимы между собой и совместимы с void*, а также все указатели на совместимые типы (пофигу на квалификатор) совместимы между собой и совместимы с void*. И? Это потребовало бы и от double* быть совместимым с void* и от int* ,быть совместимым с void*. double и double const совместимы между собой? да. если ты прав, они также совместимы и с void*. int и int const совместимы между собой? да. если ты прав, они также совместимы и с void*. И дальше у нас логическое противоречие возникает на основании пункта 1), нет? Твоя логика строилась на том, что other types - это обязательно функции, но, как оказалось, нет.

2

Сообщение от hoggy таким образом, "остальные типы" - это например, указатель-на-функцию-член.

В C11 появились функции-члены?

0

Сообщение от DrOffset Тут не указатели совместимы, а типы, на которые он указывает

действительно.

Сообщение от DrOffset Вот как раз что такое each other похоже и является ключевым. Я считаю, что other - это другие указатели на структуры, а не вообще все указатели. Ты считаешь, что это ссылка на вышеописанные указатели на char* и void*. Если это действительно так, то непонятно зачем так мудрено писать, отдельно выделять структуры, отдельно cv группы совместимых типов, когда можно было написать это одним простым предложением?

я тоже подумал, что "each other" может означать "другие указатели-на-структуры".
но тогда, - подумал я, - почему фраза такая мудреная?
если имеется ввиду группа указателей-на-структуры,
почему так сложно?
можно же было записать попроще,
по аналогии с совместимыми типами?


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

2