да

но если соблюдать один рантайм, то всё ок

В инете читал, что если DLL и EXE собраны с разным С рантаймом или разным компилятором, то будет жепа

Родной, если dll и exe собраны с разными рантаймами, то по любому будет жопа. Кидай ты исключения или нет -- не важно

Родной, если dll и exe собраны с разными рантаймами, то по любому будет жопа. Кидай ты исключения или нет -- не важно

От интерфейса зависит. Либа может только хендлы на ресурсы наружу выдавать.

От интерфейса зависит. Либа может только хендлы на ресурсы наружу выдавать.

Это вопросы ABI и нарушения ORD. Не решаются в общем случае вообще.

Нет смысла обсуждать.

Родной, если dll и exe собраны с разными рантаймами, то по любому будет жопа. Кидай ты исключения или нет -- не важно

поэтому кстати исключения не нужны

поэтому кстати исключения не нужны

А что нужно?

От интерфейса зависит. Либа может только хендлы на ресурсы наружу выдавать.

По сути есть два варианта: 0) программа по каким-то причинам не работает. 1) программа по каким-то причинам РАБОТАЕТ. А всё остальное -- детали ...

можно и без них обойтись

поэтому кстати исключения не нужны

Ну pure C ему нужно, и Go.

можно и без них обойтись

Да можно и в машинных кодах писать... Ты пишешь?

зачем передёргивать )

можно писать на C++, не используя исключения

можно писать на C++, не используя исключения

Да нельзя...

просто несколько рантаймов в dll-ках обычное дело к сожалению

По сути есть два варианта: 0) программа по каким-то причинам не работает. 1) программа по каким-то причинам РАБОТАЕТ. А всё остальное -- детали ...

Зачем так категорично? Я по своей практике знаю, когда можно рантаймы тасовать, а когда нельзя.

Зачем так категорично? Я по своей практике знаю, когда можно рантаймы тасовать, а когда нельзя.

Я по своей практике знаю, что рантаймы тасовать нельзя никогда... Когда-нибудь да #бнет...

Я по своей практике знаю, что рантаймы тасовать нельзя никогда... Когда-нибудь да #бнет...

А главное -- не понятно, зачем... Если можно не тасовать.

Я по своей практике знаю, что рантаймы тасовать нельзя никогда... Когда-нибудь да #бнет...

что будешь делать когда пропиетарная библиотека зависит от какого-нибудь MSVC 2008?

Родной, если dll и exe собраны с разными рантаймами, то по любому будет жопа. Кидай ты исключения или нет -- не важно

А как сильно распространена практика экспортирования из DLL С++ классов и функций? То есть полноценный С++ интерфейс, без extern "C" и т.д. Я читал, что такая схема работает, только если все модули (dll либы) компилируются вместе с exe одним компилятором и распространяются пачкой. Иначе могут быть вышеописанные проблемы (жопа)

А как сильно распространена практика экспортирования из DLL С++ классов и функций? То есть полноценный С++ интерфейс, без extern "C" и т.д. Я читал, что такая схема работает, только если все модули (dll либы) компилируются вместе с exe одним компилятором и распространяются пачкой. Иначе могут быть вышеописанные проблемы (жопа)

вот тоже нельзя делать

то же самое будет что и с исключениями

А как сильно распространена практика экспортирования из DLL С++ классов и функций? То есть полноценный С++ интерфейс, без extern "C" и т.д. Я читал, что такая схема работает, только если все модули (dll либы) компилируются вместе с exe одним компилятором и распространяются пачкой. Иначе могут быть вышеописанные проблемы (жопа)

Сильно распространена.

=)

что будешь делать когда пропиетарная библиотека зависит от какого-нибудь MSVC 2008?

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

А как сильно распространена практика экспортирования из DLL С++ классов и функций? То есть полноценный С++ интерфейс, без extern "C" и т.д. Я читал, что такая схема работает, только если все модули (dll либы) компилируются вместе с exe одним компилятором и распространяются пачкой. Иначе могут быть вышеописанные проблемы (жопа)

Я читал, что такая схема работает. И я знаю, как сделать, чтобы эта схема работала.

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

Нуну...

Я читал, что такая схема работает. И я знаю, как сделать, чтобы эта схема работала.

Расскажи=)

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

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

Расскажи=)

Это очень долго. Вкратце, ты должен знать, что делаешь, и не делать херню. Тогда всё будет ок. А далее начинаются кровавые подробности.

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

Либо один, либо ноль.

ну удачи с таким подходом короче )

нет времени объяснять

хотя выше уже в принципе всё есть

C помощью PIMPL можно попытаться запрятать внутри либы все компиляторозависимые вещи, ну или почти все. Но нудно. Проще заставить клиентов собирать как надо, или дать им бинарник под их сетап.

C помощью PIMPL можно попытаться запрятать внутри либы все компиляторозависимые вещи, ну или почти все. Но нудно. Проще заставить клиентов собирать как надо, или дать им бинарник под их сетап.

если у тебя 10 клиентов

а не тысячи

Тогда собирать все мыслимые бинарники

Других способов не знаю. Может, те, у кого нет времени объяснять, всё-таки поделятся)

Тогда собирать все мыслимые бинарники

выход новой версии превратится в дурдом

почему? Просто скрипт, который N раз вызывает msbuild с разными флагами

вопрос организации

или cmake, или что у вас там, не важно

Да собс-но, что нам кабанам на каждую С++-либу не делать обертку с С-шным интерфейсом? Make FFI happy.

нет времени объяснять

Аналогично.

почему? Просто скрипт, который N раз вызывает msbuild с разными флагами

всего-то должны все версии Visual Studio (причём с разными сервис-паками и без) стоять на билд-машине, mingw, clang и это только для винды

плюс вся эта куча бинарей будет весить хз сколько

и юзеру может быть сложно понять что именно ему нужно и зачем

и всё это ради того, чтобы использовать C++-интерфейсы и исключения... окееей

Смотря, что вы делаете. Для кого-то это может быть оправдано, для вас, видимо, нет. Не уверен насчёт сервис-паков, кстати, они не должны ломать бинарную совместимость. Пока ещё ни разу о таком не слышал.

Вон, Qt можно в куче вариантов скачать, например

И я бы вряд ли оценил там С интерфейс

всего-то должны все версии Visual Studio (причём с разными сервис-паками и без) стоять на билд-машине, mingw, clang и это только для винды

Всего лишь dll - msvcp msvcr и их можно тащить с собой

Смотря, что вы делаете. Для кого-то это может быть оправдано, для вас, видимо, нет. Не уверен насчёт сервис-паков, кстати, они не должны ломать бинарную совместимость. Пока ещё ни разу о таком не слышал.

бывало, я не вспомню точно в какой, 2008 или 2010

Всего лишь dll - msvcp msvcr и их можно тащить с собой

так клиент тоже будет использовать какую-то свою msvcr

выше предлагали собрать для всех вариантов

так клиент тоже будет использовать какую-то свою msvcr

Ну и пусть, они уживаются друг с другом.

бывало, я не вспомню точно в какой, 2008 или 2010

Не спорю, я с 2012-й занимаюсь коммерческой разработкой, не застал такого.

выше предлагали собрать для всех вариантов

Ну вот это да, надо будет все собирать

Ну и пусть, они уживаются друг с другом.

если он будет дёргать С++-интерфейс, то есть шанс, что не уживутся

Просто деградировать до C интерфейсов не всегда хочется, поэтому иногда проще решить эти проблемы чем все протаскивать через plain C

Просто деградировать до C интерфейсов не всегда хочется, поэтому иногда проще решить эти проблемы чем все протаскивать через plain C

ну вот на популярных проектах вроде всегда проще деградировать до С интерфейсов

примеров куча Microsoft, Adobe и т.п.

А что Adobe? У них есть вполне плюсовый DNG SDK

ERROR: S client not available

он не исходниками распространяется?

я знаю только про SDK для Photoshop, Premiere, AfterEffects

он не исходниками распространяется?

Хороший вопрос. Если только исходниками, тогда понятно.

Неправ абсолютно

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

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

Если у тебя модули (динлинковка) и статический CRT, то это нарушение ODR и как следствие UB... Я тебе желаю счастья в отладке такой программы.

Собсна при некоторых конвенциях вызова бобо не только исключения

Собсна при некоторых конвенциях вызова бобо не только исключения

Вообще, чего уж тут... Давай скажем прямо: всё это программирование -- сплошное бобо...

Ты никогда не видел, как передаваемый по значению контейнер (иногда бывает нужно и такое) валил функцию при выходе?

примеров куча Microsoft, Adobe и т.п.

Э... Вот замечательный КОНТРпример есть как раз от Microsoft. MFC называется.

Никто неподкажет как записать структуру в файл

Зависит от

Никто неподкажет как записать структуру в файл

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

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

Э... Вот замечательный КОНТРпример есть как раз от Microsoft. MFC называется.

он же идёт вместе с visual studio соответственно будет с тем же рантаймом, что у тебя

он же идёт вместе с visual studio соответственно будет с тем же рантаймом, что у тебя

И что?

И что?

не будет проблем

это считай как расширение рантайма от MS

а вот winapi у них с С интерфейсами

не будет проблем

Ну вот на популярных проектах вроде всегда проще деградировать до С интерфейсовКак-то MFCшники не хотят деградировать до С...

а я понял, что неправильно написал

если ты популярную либу делаешь

dll

sdk там

У меня структура данних о книге Arrayofbooks *pBooks с указателемь притом елементи структури я ввожу вручную через консоль

вот это всё

Ну вот на популярных проектах вроде всегда проще деградировать до С интерфейсовКак-то MFCшники не хотят деградировать до С...

MFС-шники ещё живы?

MFС-шники ещё живы?

Как никогда. Вот прям щаз правлю программулю на MFC...

мои соболезнования

MFС-шники ещё живы?

Я вчера видел человека который последние два года за пределы WinAPI не вылазит

а на прогулки выводят хоть?

Можете объяснить как именно реализованы корутины в msvc?

Они так же работают, как и бустовские?