Ну, как по мне, смысла нет. И так ясно: если стремиться написать код, который должен очень быстро работать, то качественное решение на C++ выиграет у качественного решения на C#. Другой вопрос в том, какие затраты на написания качественного решения: для C++ они выше. Как по мне, если брать среднестатистического программиста, то C# выигрывает в плане быстроты и удобства разработки, что вполне окупает потерю производительности.
Я смотрел какое-то видео, увидел это окошко и именно из-за него захотел Visual Studio 2015! Ещё не пользовался, но — УРА, круто, наконец-то. Дождались!
Ну зачем столько сарказма? Когда используешь cdb (другие не пробовал) из-под QtCreator-а, лично у меня — он подвисает очень часто и, по сравнению со встроенным Visual Studio Debugger-ом — всё продвигается медленнее. Просмотр переменных в QtCreator-е просто ад и ужас, особенно, если это обычные строки. Watch-окна, вроде как, нет (с удобными штуками такими как @ err,hr). Окна потоков/подключённых процессов так же как и окна пам'яти/call stack-а — удобнее в студии. Такой штуки как Autos в QtCreator-е, если я не ошибаюсь, вообще нет (так же как и дизасемблера ?). Коннектиться к удалённому процесу — намного проще, если ещё и к vmware-виртуалке (удобный плагин, всё в один клик). Как подключить KD — я так и не нашёл (хотя, признаюсь, гуглил не больше 2х минут).
По поводу Qt Creator — пытался работать с ним, но никак не ужился с отсутствием нормального дебаггера. Именно из-за шикарного дебаггера — использую только студию (рефакторинг — с плагинами, автодополнение — в 13й — очень даже не плохо). Ну а вне Windows — Qt Creator единственная IDE
Как минимум потому что, скорее всего, это означает, что язык востребован, за ним следят, интересуются, понимают, что он «не идеален», пытаются улучшить, да и вообще, если есть стандарт, то скорее всего — у языка большая коммюнити…
Если большинство слов не помещается в изначально зарезервированный в `std::string` буфер размером 16 char
Хм, я понимаю, что это SSO, но не утверждал бы так категорично, как будто это всегда так.
char const *finish = text + std::strlen(text);
Зачем пробегаться по тексту лишний раз, ели всё равно strlen расчитан на null-terminated строку.
Когда нужен именно массив с поэлементным доступом и недорогим увеличением размера, смотри лучше в сторону `std::deque`
Ну вот смотрю я push_back(), а сложность для deque — константная, а для vector — амортизированная константная. Что это значит? Утверждение, без каких либо объяснений.
Для класса field, как по мне нужно хотя бы упомянуть о конструкторе копирования/операторе присваивания и, вообще, m_buffer это целая эпопея для тех, кто знаком с memory alignment.
Ну, снова таки — из приведённого Вами документа, видно, что автор разбивает ресурсы на «pointer handle type» и «handle types that are not pointers». Для работы с ресурсами первого типа, как раз таки, приводится прекрасный пример использования std::unique_ptr для управления ресурсом (конечно, есть и недостатки).
Пример из N4189
typedef void *HANDLE; // System defined opaque handle type
typedef unsigned long DWORD;
#define INVALID_HANDLE_VALUE reinterpret_cast<HANDLE>(-1)
// Can’t help this, that’s from the OS
// System defined APIs
void CloseHandle(HANDLE hObject);
HANDLE CreateFile(const char *pszFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile);
bool ReadFile(HANDLE hFile,
void *pBuffer,
DWORD nNumberOfBytesToRead,
DWORD*pNumberOfBytesRead);
// Using std::unique ptr to ensure file handle is closed on scope-exit:
void CoercedExample()
{
// Initialize hFile ensure it will be ”closed” (regardless of value) on scope-exit
std::unique_ptr<void, decltype(&CloseHandle)> hFile(
CreateFile("test.tmp",
FILE_ALL_ACCESS,
FILE_SHARE_READ,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
nullptr),
CloseHandle);
// Read some data using the handle
std::array<char, 1024> arr = { };
DWORD dwRead = 0;
ReadFile(hFile.get(), // Must use std::unique ptr::get()
&arr[0],
static_cast<DWORD>(arr.size()),
&dwRead);
}
Для ресурсов второго типа («handle types that are not pointers») — используется уже новый, предлагаемый API — т.е., я хочу сказать, что простых решений с использованием существующей библиотеки C++ (как в случае с «pointer handle type») — нет.
Так вот Вы же приводите пример, который пытается решить проблему «handle types that are not pointers» c помощью того же std::unique_ptr, и говорите, что использовать std::unique_ptr для «pointer handle type» — спекуляция.
спекуляция с использованием std::remove_pointer указывает на полное непонимание принципа его работы. В случае std::unique_ptr работу с ресурсом необходимо оборачивать в работу над указателем на ресурс, а не маскировать ресурс под указатель.
А можно здесь поподробней? Я использую подобный трюк и хотелось бы узнать в чём-же моё непонимание std::unique_ptr. На примере HANDLE, как бы поступили Вы?
Это если по-умолчанию, передаём что-то типа вот такого аллокатора — и всё на стеке
Этот конструктор настолько секретный, что даже сопровождающие STL не знают о нём...
:)
Спасибо за перевод.
_Generic,_Bool,_Thread_local?Какой-то странный мютекс. Обычно принято
lock()делать. И, если это делается где-то неявно, то имя совсем не подходит реальности.Зачем? Ничего же не получится.
Хм, я понимаю, что это SSO, но не утверждал бы так категорично, как будто это всегда так.
Зачем пробегаться по тексту лишний раз, ели всё равно
strlenрасчитан на null-terminated строку.Ну вот смотрю я
push_back(), а сложность дляdeque— константная, а дляvector— амортизированная константная. Что это значит? Утверждение, без каких либо объяснений.Для класса
field, как по мне нужно хотя бы упомянуть о конструкторе копирования/операторе присваивания и, вообще,m_bufferэто целая эпопея для тех, кто знаком с memory alignment.std::unique_ptrдля управления ресурсом (конечно, есть и недостатки).Для ресурсов второго типа («handle types that are not pointers») — используется уже новый, предлагаемый API — т.е., я хочу сказать, что простых решений с использованием существующей библиотеки C++ (как в случае с «pointer handle type») — нет.
Так вот Вы же приводите пример, который пытается решить проблему «handle types that are not pointers» c помощью того же
std::unique_ptr, и говорите, что использоватьstd::unique_ptrдля «pointer handle type» — спекуляция.А можно здесь поподробней? Я использую подобный трюк и хотелось бы узнать в чём-же моё непонимание std::unique_ptr. На примере HANDLE, как бы поступили Вы?