Здравствуйте, <Аноним>, Вы писали:

RO>>В C++03 вообще никаких потоков нет, так что любые потоки — UB . RO>В зависимости от реализации, new-там-delete-здесь может быть безопасно, а может вызвать проблемы.
А>В стандарте — нету. В конкретных реализациях компиляторов и CRT — есть. В частности при использовании MSVC и включении MT-safe рантайма new/delete можно гарантированно без проблемно делать из разных потоков. Если же вы не включили правильнынй рантайм из каких то соображений — вы сами себе злобный Буратино.
Т.е. это исключительно implementation specific грабли конкретных реализаций CRT.

RO>>Да, и еще есть любители делать new в динамической библиотеке и delete в основном модуле, что может вызывать самые разные результаты в зависимости от фазы луны.
А>Это совершенно из другой оперы проблема.
Это тоже строго implementation specific проблема CRT.

Здравствуйте, CreatorCray, Вы писали:

А>>В стандарте — нету. В конкретных реализациях компиляторов и CRT — есть. В частности при использовании MSVC и включении MT-safe рантайма new/delete можно гарантированно без проблемно делать из разных потоков. Если же вы не включили правильнынй рантайм из каких то соображений — вы сами себе злобный Буратино.
CC>Т.е. это исключительно implementation specific грабли конкретных реализаций CRT.

Ты можешь себе представить, что если когда-нибудь стандарт
установит правила на этот счет, то бы было явное ограничение new/delete в одном потоке?
Это бы противоречило уже сложившейся практике с распространненными компиляторами.

Здравствуйте, rastoman, Вы писали:

R>Здравствуйте, Roman Odaisky, Вы писали:

RO>>Да, и еще есть любители делать new в динамической библиотеке и delete в основном модуле, что может вызывать самые разные результаты в зависимости от фазы луны.
R>Если CRT прилинковано статически, то да. А если динамически, то можно выделять в одном модуле, а освобождать в другом.
а если основной модуль и динамическая библиотека прилинкованы динамически, но к разным рантаймам?

А>

А>..................
А>cObject * iObject = new cObject;
А>DWORD iThreadID;
А>HANDLE a_HThread;

А>a_HThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE) ThreadFun, iObject, 0, & iThreadID);
А>..................

А>// Далее уже в потоковой функции

А>DWORD WINAPI ThreadFun(void * arguments)
А>{
А>    cObject * o = (cObject *) arguments;
А>        while(SomeCondition) {
А>        // Что-то там происходит и в итоге решил я цикл покинуть
А>        }

А>        delete s; // И вот тут я ловлю ошибку.
А>

Насколлько я понимаю, под CObjeсt подразумевается MFC-шный класс. Так вот, чтобы MFC как-то работала потоки нужно запускать AfxBeginThread().
Во-вторых MFC-шные классы не следует создавать в одном потоке, а уничтожать в другом. Вылетает на всяких ASSERT_VALID-ах внутри деструкторов. Так что рекомендую либо не наследовать объекты от MFC, либо уничтожать их в том же потоке, в котором они созданы.

RO>>Кстати, в других ОС вообще есть такое недоразумение, как неиспользование libc?
CC>Это всего лишь либа. Да, в ней есть некоторые вещи, которые компилер использует автоматически (типа поддержки int64 на 32-битной платформе, некоторые FPU хэлперы и т.п.), но никто не заставляет использовать все остальное.

Действительно, почему-то от виндузятников постоянно слышно: КРТ не использую! Как слинковать программу, чтобы не использовала КРТ? Причина, вероятно, в том, что винда имеет некие полезные функции, которые традиционно входят в КРТ. Например, все богатство функций работы со строками. В той же солярке ничего такого нет.

Здравствуйте, Vamp, Вы писали:

RO>>>Кстати, в других ОС вообще есть такое недоразумение, как неиспользование libc?
CC>>Это всего лишь либа. Да, в ней есть некоторые вещи, которые компилер использует автоматически (типа поддержки int64 на 32-битной платформе, некоторые FPU хэлперы и т.п.), но никто не заставляет использовать все остальное.

V>Действительно, почему-то от виндузятников постоянно слышно: КРТ не использую!
V>Как слинковать программу, чтобы не использовала КРТ?

V>Причина, вероятно, в том, что винда имеет некие полезные функции, которые традиционно входят в КРТ.
Да хотяб работа с файлами: MMF, потоки, \\?\, sparced файлы, Junctions, Gather/Scatter, управление кэшированием — всего этого нет в CRT, да и быть не может.
ЗЫ: ДА! Я это всё использую.

V>Например, все богатство функций работы со строками.
Нафига CRT функции для строк если можно юзать STL-like строки. Оно как то поудобнее в разы.

Все что я использую из CRT (впрочем и то — косвенно) — это встраиваемые компилером функции преобразования int->float, работа с int64 на 32bit и т.п.
Остальное попросту не нужно.
Но это не значит что я выкорчевываю CRT и программ. Я просто не использую ничего, что вызывается явно.

CC>Да хотяб работа с файлами: MMF, потоки, \\?\, sparced файлы, Junctions, Gather/Scatter, управление кэшированием — всего этого нет в CRT, да и быть не может.
CC>ЗЫ: ДА! Я это всё использую.
Ну правильно, причем тут КРТ? Я же немного не о том.

CC>Нафига CRT функции для строк если можно юзать STL-like строки. Оно как то поудобнее в разы.
Зависит. Может потребоваться для работы со всякими третьими библиотеками, тем же API ОС и т.д.