А в чем отличие? Это типа если пишешь библиотеку в стиле С — то есть без всяких классов — это АБИ? То есть будет цепляться к любому языку и платформе? А если классы чисто для конкретного языка, то АПИ?
Здравствуйте, 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>Очевидно, мы говорим просто о разных уровнях.
