А в чем отличие? Это типа если пишешь библиотеку в стиле С — то есть без всяких классов — это АБИ? То есть будет цепляться к любому языку и платформе? А если классы чисто для конкретного языка, то АПИ?
Здравствуйте, Hоmunculus, Вы писали:
H>А в чем отличие? Это типа если пишешь библиотеку в стиле С — то есть без всяких классов — это АБИ? То есть будет цепляться к любому языку и платформе? А если классы чисто для конкретного языка, то АПИ?
АБИ — это бинарный интерфейс. Речь о совместимости модулей. Грубо говоря — о возможности слинковаться с модулем, скомпилированным другим компилятором. Это не выражается в пользовательском коде. Это про внутренний формат бинарных файлов.
Двоичный (бинарный) интерфейс приложений (англ. application binary interface, ABI) — набор соглашений для доступа приложения к операционной системе и другим низкоуровневым сервисам, спроектированный для переносимости исполняемого кода между машинами, имеющими совместимые ABI[1]. В отличие от API, который регламентирует совместимость на уровне исходного текста, ABI можно рассматривать как набор правил, позволяющих компоновщику объединять откомпилированные модули компонента без перекомпиляции всего исходного текста, в то же время определяя двоичный интерфейс[2].
Здравствуйте, Hоmunculus, Вы писали:
H>А в чем отличие? Это типа если пишешь библиотеку в стиле С — то есть без всяких классов — это АБИ? То есть будет цепляться к любому языку и платформе? А если классы чисто для конкретного языка, то АПИ?
Апи это програмный интерфейс
interface A {
handle open(name);
void close(handle);
}
А ABI это как передавать параметры (stdcall,pascal,fastcall,...), в стеке в регистрах, как выравнивать, какие регистры нельзя трогать, в какие можно менять, не сохраняя т.п. или как формировать xml или json для выполнения запроса open/close.
Здравствуйте, Hоmunculus, Вы писали:
H>А в чем отличие? Это типа если пишешь библиотеку в стиле С — то есть без всяких классов — это АБИ? То есть будет цепляться к любому языку и платформе? А если классы чисто для конкретного языка, то АПИ?
Это всё API. ABI — это то, как реализуются различные механизмы на низком уровне. Как параметры передаются, как исключения обрабатываются, и тп. ABI на одной программно-аппаратной платформе (x86-Linux, x64-Windows, и тп) обычно одно. Хотя, GCC вроде между мажорными версиями иногда ломает совместимость ABI, и glibc разных мажорных версий бывают несовместимы.
Здравствуйте, Hоmunculus, Вы писали:
H>А в чем отличие?
Очень наглядный пример — это debug и release сборки. Есть у тебя dll, которой ты передаешь, например, std::string или std:: vector. API не меняется, а ABI у debug будет другой, потому что stl контейнеры по-умолчанию будут иметь другой размер и вести себя соответственно. Программа упадёт, если собрать exe в release, а dll в debug. Но API же не изменился!
Здравствуйте, Hоmunculus, Вы писали:
H>А в чем отличие? Это типа если пишешь библиотеку в стиле С — то есть без всяких классов — это АБИ? То есть будет цепляться к любому языку и платформе? А если классы чисто для конкретного языка, то АПИ?
API — это совместимость на уровне исходников.
ABI — это когда для совместимости исходники не требуются.
Даже и в случаи C на некоторых платформах соглашения о вызовах, например, менялись. Т.е., ломалась совместимость на уровне ABI.
В случае C++ совместимость на уровне ABI обеспечить можно, но придётся специально поднапрячься. А в случае Go, например, совместимость на уровне ABI никто не обещал и никто не отгружал.
Здравствуйте, Nuzhny, Вы писали:
N>Очень наглядный пример — это debug и release сборки.
Это как раз наглядный пример того, что не является ABI.
N>ABI у debug будет другой
Не будет, если явно не менять то, что относится к ABI (например, stdcall на fastcall).
N>потому что stl контейнеры по-умолчанию будут иметь другой размер
Это не относится к ABI.
N>Программа упадёт, если собрать exe в release, а dll в debug. Но API же не изменился!
И ABI не изменился. Изменились ожидаемые неявные параметры.
Здравствуйте, Nuzhny, Вы писали:
ЕМ>>Изменились ожидаемые неявные параметры.
N>Что это такое?
Э-э-э... Например, когда функции передается указатель на массив, и она неявно ожидает, что в нем будет не меньше, скажем, трех элементов.
N>Никогда не слышал термина, он существует?
Это не термин, а обычное описательное выражение. В англоязычной литературе часто обозначается словами "assumptions", "expectations" и т.п.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Э-э-э... Например, когда функции передается указатель на массив, и она неявно ожидает, что в нем будет не меньше, скажем, трех элементов.
Что это за АПИ такой? Всегда когда передают указатель на массив, то передают и количество.
Здравствуйте, Hоmunculus, Вы писали:
ЕМ>>Э-э-э... Например, когда функции передается указатель на массив, и она неявно ожидает, что в нем будет не меньше, скажем, трех элементов.
H>Что это за АПИ такой?
Допустим, он его только что придумал
H>Всегда когда передают указатель на массив, то передают и количество.
Ну ясно что необязательно. В лабораторных либах. А в реальных не видел чтоб не было. Я не про указатель на участок памяти, а именно на какой-то массив. Ну хотя… если ожидается матрица 4 на 4 или типа того… то да, наверное реальный случай
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>>Изменились ожидаемые неявные параметры. N>>Что это такое? ЕМ>Э-э-э... Например, когда функции передается указатель на массив, и она неявно ожидает, что в нем будет не меньше, скажем, трех элементов.
This is disallowed by ABI3 constraints. Additional research on optimization and SSO-tuning for std::string is also assumed to be worth a non-trivial performance boost (1% macrobenchmark/fleet performance) — this has no API impact, but is disallowed by ABI constraints.
Это по мнению члена комитета по С++, если что.
Далее можно почитать большую статью Саттера на тему ABI, там будут аналогичные примеры с std::string, которая где-то реализует, например, copy-on-write, а где-то и нет. И по его мнению, это ломает ABI.
То есть я использую термин ABI для обозначения изменения поведения и/или размера стандартных сущностей из С++ также, как чоены комитета по С++. Разве нет?
N>>Никогда не слышал термина, он существует? ЕМ>Это не термин, а обычное описательное выражение. В англоязычной литературе часто обозначается словами "assumptions", "expectations" и т.п.
Ну, так у нас разговор сейчас именно про термины. Я ошибаюсь с границами термина ABI? Мне кажется, что нет. Есть ли какой-то другой термин? Видимо нет, просто описательное выражение.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, Hоmunculus, Вы писали:
H>>Что это за АПИ такой? Всегда когда передают указатель на массив, то передают и количество.
ЕМ>Вы за свою жизнь сколько API видели — два, три, четыре?
Ну да, да. Не сразу вспомнились. В опенгл и в опенсв есть такие функции
Здравствуйте, Nuzhny, Вы писали:
N>Я ошибаюсь с границами термина ABI?
Об ABI уместно говорить там, где есть спецификация интерфейса. Если для std::string документировано, что/где/как должно лежать в двоичном виде в отладочных/релизных сборках, то это ABI. Если же все упирается в неявные зависимости от параметров, которые по-разному определяются в разных сборках, то это те самые assumptions.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Об ABI уместно говорить там, где есть спецификация интерфейса.
Это не общеупотребительное определение. Обычно как раз разделяют низкоуровневое ABI типа cdecl/stdcall и другой штуки. А также выделяю C++ABI, которое как раз про реализацию исключений, стандартной библиотеки и т.д.
Очевидно, мы говорим просто о разных уровнях.
Здравствуйте, Nuzhny, Вы писали:
ЕМ>>Об ABI уместно говорить там, где есть спецификация интерфейса.
N>Это не общеупотребительное определение. Обычно как раз разделяют низкоуровневое ABI типа cdecl/stdcall и другой штуки. А также выделяю C++ABI, которое как раз про реализацию исключений, стандартной библиотеки и т.д. N>Очевидно, мы говорим просто о разных уровнях.
Здравствуйте, Nuzhny, Вы писали:
N>разделяют низкоуровневое ABI типа cdecl/stdcall и другой штуки.
Высота уровня здесь ни при чем. Буква "I" в аббревиатуре ABI обозначает факт стыковки программных сущностей, а "B" — тип этой стыковки. Чтобы эту стыковку можно было выделить сколько-нибудь явно, требуется спецификация. Правила оформления символических имен, обращения со стеком/регистрами и т.п., являются частью ABI. Если они различаются в отладочной и релизной сборках, то имеет смысл говорить о "несовместимости по ABI". Если же одна сторона ожидает найти по определенному адресу определенное значение, определенный результат вызова функции с определенными параметрами, но это явно не специфицировано в API, то имеет место "несовместимость сред" или что-то вроде этого, и говорить в этом контексте об ABI некорректно.
Здравствуйте, Nuzhny, Вы писали:
N>Очень наглядный пример — это debug и release сборки. Есть у тебя dll, которой ты передаешь, например, std::string или std:: vector. API не меняется, а ABI у debug будет другой...
Это не то, то — это различный формат самих данных, например:
есть у тебя USB-осциллограф, который может отдавать тебе массивы точек в формате {FILETIME time, float voltage}. Ты прочитал формат данных в документации, но обломался: x86 использует Little-Endian, а железка тебе отдаёт Big-Endian.
Потом ты разобрался в чём дело, и ещё раз обломался: ты на C# пишешь — поставил [StructLayout(LayoutKind.Sequential)] и успокоился, не учёл, что значения в структуре DSP-процессор выравнивает совсем не так, как это принято в винде.
Другой пример: решил ты, значит, попрактиковаться с графическими форматами — захотелось руками поковыряться в jpeg. И вот описал ты структурки, все нужные алгоритмы правильно написал — все тесты проходят, но нифига не работает. Угадай почему.
И ведь, сцуко, ни один чат-бот тебе не поможет с таким вопросом, не подскажет куда копать.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Nuzhny, Вы писали:
N>>Очень наглядный пример — это debug и release сборки. Есть у тебя dll, которой ты передаешь, например, std::string или std:: vector. API не меняется, а ABI у debug будет другой...
Ф>Это не то, то — это различный формат самих данных, например:
Зачем эти фантазии и философия? Вот есть же доки, они рулез.
Например https://gcc.gnu.org/onlinedocs/gcc/Compatibility.html
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
А смысл в доках от GCC, если бинарный интерфейс частенько даже не кодом записан? Псевдокодом, в pdf'ке.
Где GCC и где бинарный интерфейс какой-нибудь железяки?
by all of the tools that deal with binary representations of a program, including compilers, assemblers, linkers, and language runtime support.
Вот скажи, железяка предоставляет бинарный интерфейс? Может это делать? Тогда причём тут "binary representations of a program"?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>·>Зачем эти фантазии и философия? Вот есть же доки, они рулез. Ф>·>Например https://gcc.gnu.org/onlinedocs/gcc/Compatibility.html Ф>А смысл в доках от GCC, если
Смысл в том, что там пишут фактическое название вещей, а не филосовствования.
Ф>бинарный интерфейс частенько даже не кодом записан? Псевдокодом, в pdf'ке.
Тогда это не ABI.
Ф>Где GCC и где бинарный интерфейс какой-нибудь железяки?
У железяк не ABI, а протоколы. По определению.
Ф>
Ф>by all of the tools that deal with binary representations of a program, including compilers, assemblers, linkers, and language runtime support.
Ф>Вот скажи, железяка предоставляет бинарный интерфейс?
Не предоставляет.
Ф>Может это делать?
Не может.
Ф> Тогда причём тут "binary representations of a program"?
Такое определение термина ABI.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
