- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
const char * c_version()
{
const char * hui = "hui";
const char * pizda = "pizda";
unsigned long huilen = strlen ( hui );
unsigned long pizdalen = strlen ( pizda );
char * sobaka = ( char* ) ::malloc ( (huilen + pizdalen) + 2 );
strcat ( sobaka,hui );
strcat ( ( sobaka + huilen ),"&" );
strcat ( ( sobaka + huilen + 1 ),pizda );
sobaka[huilen + pizdalen + 1] = '\0';
return sobaka;
}
Follow us!
> ::malloc
А что, так можно?
Сделай свою либу для строк или найди готовую, раз так часто клеить приходится.
на большинстве человеческих систем - где поддерживается asprintf() - в одну.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/sscanf.html
[CX] [Option Start] The %c, %s, and %[ conversion specifiers shall accept an optional assignment-allocation character 'm', which shall cause a memory buffer to be allocated to hold the string converted including a terminating null character. In such a case, the argument corresponding to the conversion specifier should be a reference to a pointer variable that will receive a pointer to the allocated buffer. The system shall allocate a buffer as if malloc() had been called. The application shall be responsible for freeing the memory after usage. If there is insufficient memory to allocate a buffer, the function shall set errno to [ENOMEM] and a conversion error shall result. If the function returns EOF, any memory successfully allocated for parameters using assignment-allocation character 'm' by this call shall be freed before the function returns. [Option End]
если бы огородов не городили, а взяли фиксированый буфер, то эта функция может быть и в принципе не нужна была бы.
ЗЫ или даже обычный строковый литерал:
и все остальное - включая ноль на конце - сделает за тебя компилер.
на самом деле я подобные огороды как сверху видел. было очень смешно когда первые билды фирмваре не бутились потому что пулы/хипы еще не были проинициализированы, но статикой вызывалась генерация строки версии. и что бы все еще маразменней сделать, все было хардкожено (как и выше) в теле статического метода который эту строку динамически генерировал.
Универсальное предположение.
Я бы в наше время переходил на универсальный единообразный подход, а дела пирфоманса и вкомпиливание констант в код программы оставил бы компилятору. Чем меньше программист работает оператором байтов, тем больше у него времени на работу над алгоритмом.
Хотя, в C++ даже аргумент без серьёзных размышлений просто так нормально не передашь.
Тем больше он работает оператором джиры и менеджерского хуйца.
такой код имеет тенденции, в long run:
- требует сопровождения и поддержки
- требует дополнительного тестирования
как по мне, в мелочах и простых вещах, долгосрочно, лучше оставатся ближе к языку/ОС/стандартным библиотекам. и тестировать не надо, и поддерживать только по мелочам.
в какой жабе или шарпе это еще терпимо - потому что сидят в некритичных прикладных облястях - там тест коверадж никто и не требует, и даже сервис/high авэйлабилити там тоже ограниченые ("бизнес хауэрс"). да и все равно все апдейтится и ребутится постоянно.
> Чем меньше программист работает оператором байтов, тем больше у него времени на работу над алгоритмом.
да. теперь в контексте этой мысли почитай историю PHP, языка и рантайма. почитай и поразмышляй как думали создатели PHP 20 лет назад.
Оставаться ближе к языку - благо. Но если он сложный, лучше выбрать достаточное подмножество.
Динамическая sobaka - это всё ещё обычный C/C++, только у программиста из головы бритвой Оккама вырезается необязательная абстракция.
Оптимальный подход - доверять автоматике как можно больше задач для решения (т.к. автоматика не забудет, не устанет и будет работать одинаково хорошо), а затем делать тонкую подстройку там, где человек может сделать лучше, и это действительно необходимо. Правда, для этого нужны нормальные инструменты. У нас почему-то считают, что машина - говно по сравнению с профессионалом, и мастер руками сможет выжать больше, из чего вытекают недостаточно автоматизированные инструменты, которые без усилия человека производят некачественный продукт.
То есть, грубо говоря, либо следи сам за всеми UB, сам решай, где статика, где динамика, где ссылка, где значение, ... - всегда напрягайся, и будет суперпирфоманс, либо дадим тебе язык, где нет UB, и всё неизменно передаётся по ссылке, непомерно пожирая процессор.
1. когда последний раз видел обработку std::bad_alloc?
2. "обычный С++" - этот язык на котором юникорны программируют или что?
> либо дадим тебе язык, где нет UB,
таки пересаживаем всех на Tcl и Haskell? или Rust?
Собаколена не хватает.