Comments 18
Во времена 20го стандарта рассуждать о ручном управлении памятью и фичах 11 стандарта — выглядит слегка outdated.
Конечно, специфика WinAPI накладывает свой отпечаток.
А так — есть несколько неплохих пунктов для джуниоров, хотя, если человек сознательно идёт на плюсы и не знает про чтение из объединения, размеры типов и инициализацию статических объектов вместе с проблемами контейнеров в интерфейсах — ему(и, особенно, нанимающему) стоит задуматься о другом языке, ИМХО.
Никто и не спорит, что там и 03 может быть, но я не думаю, что в современных DSP делают интерфейсы с контейнерами из стандартной библиотеки или у разработчика возникают вопросы относительно размеров int и long, которые, на 99.9% вообще в коже не встретятся, т.к. на такой «глубине» все пользуются (u)int(8/16/32/64)_t и знают платформенные типы.
Видел платформу где uint8_t и прочие char занимают 2 байта: один данные хранит, а другой владеет кристалл и сам распоряжается что там надо делать. Вроде у TI DSP какой-то был.
ЗЫ зато когда всё 32 бита никогда не ошибешься в размере =))
Но ведь стандарт гарантирует, что uint8_t будет занимать ровно 8 бит.
Простите, не удержался, но статья производит впечатление "уж мы-то какие всезнайки, в одном коротком примере кода столько косяков можем перечислить, сколько вам и не снилось". А особой пикантности придает то, что у вас Finalizer — это class, а не struct, поэтому по умолчанию все его содержимое — это private секция, включая конструктор и деструктор. А раз так, то экземпляр Finalizer смогут создать не только лишь все. Посему вы просто не сможете объявить глобальную переменную типа Finalizer и ваш пример просто не скомпилируется (по типу вот такого).
Возможно, вы сочли этот код простым, очевидным и достаточно безопасным? Или, может быть, вы нашли в нем некоторые проблемы? А может быть, даже дюжину или две?
Чёрт да от него за две версты воняет, любому блин понятно насколько это вонючий код. А для новичков хватило бы и подобного
class SomeClass
{
int* some_ptr;
public:
void print_value()
{
std::cout << *some_ptr;
}
void set_val(int* ptr)
{
delete some_ptr;
some_ptr = ptr;
}
SomeClass& operator=(SomeClass& val)
{
delete some_ptr;
some_ptr = val.some_ptr;
}
~SomeClass()
{
delete some_ptr;
}
};
class SecondClass: public SomeClass
{
public:
void print_value()
{
std::cout << "wubba lubba dub dub";
}
};
Обычно что-то подобное иногда проскакивает у джунов, куча ошибок на небольшом куске.
Возможно, вы сочли этот код простым, очевидным и достаточно безопасным?
Нет, от него глаза кровоточат и воняет за версту.
И где здесь, кстати, C++?
Кликбейтный заголовок настраивает на увлекательное чтиво о настоящих, кровавых багах и темных углах языка и стандартной библиотеки.
Вместо этого имеем кусок С WinAPI-specific кода из 2000 года, случайным образом присыпанный throw, new, vector и т.п., в котором — кто бы мог подумать! — есть баги, 95% которых C & WinAPI-specific.
C++: Коварство и Любовь, или Да что вообще может пойти не так?