Основные типы для предоставления в C++ API

Я ориентируюсь на Windows, но не вижу причин, по которым некоторый код API, который я пишу, не может использовать базовые типы C++. Что я хочу сделать, так это предоставить методы, которые возвращают строки и целые числа. В мире C# я бы просто использовал строку и имел строку Unicode, но в VC++ у меня есть возможность использовать std::string, std::wstring или CStrings MFC/ATL.

Должен ли я просто использовать std::wstring исключительно для поддержки юникода, или я могу использовать std::string, который будет скомпилирован в юникод на основе моих настроек сборки? Я склоняюсь к последнему. Я бы предпочел предоставить методы Get[Item]AsCString() для моих объектов для других типов строк.

Также я должен использовать size_t вместо целого числа?

API будет использоваться мной и, возможно, будущим разработчиком, работающим над графическим интерфейсом C++. Это способ разделить заботы. Мои предпочтения:

  • Интуитивность для других разработчиков.
  • Прямая совместимость с VС++
  • Совместимость с другими компиляторами C++
  • Производительность (это меня не волнует, но мне нужно время запуска для остальной части моего приложения)

Любые руководства будут оценены.


c++ api-design visual-c++
person WTLNewbie    schedule 27.02.2011    source источник
comment
Этот стиль конфигурации проекта действительно зависит от цели проекта и т. Д. Все имеет свое место, поэтому некоторые аспекты не просто устарели. std::string является наиболее распространенным использованием, которое я видел (хотя я видел wchar_t и т. д. для юникода), и если вы измеряете размер чего-либо, используйте size_t.   -  person RageD    schedule 27.02.2011

Ответы (3)


arrow_upward
2
arrow_downward

Вероятно, вам следует придерживаться строкового типа STL. Класс MFC CString в любом случае в настоящее время построен на основе этого.

Как было отмечено ранее, использование wstring не является волшебным средством для решения проблем Unicode, поскольку существует множество символов Unicode, для кодирования которых по-прежнему требуется несколько символов wchar.

Вместо этого использование Utf-8 имеет потенциальные преимущества (например, вам не нужно беспокоиться о порядке байтов).

В Windows все современные ядра основаны на wchar, поэтому при использовании 8-битных версий API-интерфейсов возникают (минимальные) потери производительности.

person COrthbandt    schedule 28.02.2011

arrow_upward
1
arrow_downward

В вашей ситуации мне потребовалось бы несколько часов/дней, чтобы сформировать мнение и принять решение. Прежде всего, я предпочитаю C_API C++_API, даже для кода C++. Тогда ответ будет char*, или wchar*, или TCHAR*. Теперь попробуйте угадать, ДЕЙСТВИТЕЛЬНО ли вы ожидаете необходимость в UNICODE. Подавляющее большинство моих проектов (в том числе с графическим интерфейсом) не нуждались в UNICODE, простота и привычность простых C-массивов часто трудно превзойти.

Короче говоря, постарайтесь предсказать, каковы будут ваши потребности, не пытайтесь заглядывать слишком далеко в будущее (2 года — это хороший показатель), а затем придумайте самое простое решение для удовлетворения потребностей.

Последнее: чтобы ответить на ваш вопрос более прямо, я бы начал с std::string в качестве первого выбора для оценки. Если бы я не нашел какое-то преимущество в ставках в пользу других вариантов, я бы остался с ним.

person Radim Cernej    schedule 27.02.2011

arrow_upward
1
arrow_downward

Использование std::wstring/string вместо MFC CString позволит вам переносить свой код на другие платформы (например, Qt для Windows).

Даже при использовании std::string вы можете кодировать строки в UTF-8, поэтому ваш API по-прежнему сможет возвращать строки UNICODE. Имейте в виду, что даже wstring на самом деле является UTF-16, а не полным 32-битным UNICODE (в то время как в некоторых операционных системах wstring является UTF-32).

person Paolo Brandoli    schedule 27.02.2011