написал простенькую функцию на Си
, хотел бы с помощью профи на этом форуме, довести её до совершенства.
а именно:
Как вы уже заметили я использую глобальные массивы, что не есть гуд! 
Вот бы переделать её так что бы она стала указателем на результат, т.е.

эта функция очень маленькая, поэтому прошу !проффи! , мне очень хочеться посмотреть как можно до совершенства решить такую задачку.
спасибо.

Непрофессионал делает так:




Сейчас вам еще покажут плюсовый пример на каком-нибудь boost-е.

Добавлено через 2 минуты и 51 секунду
Хм. Это этот дефайн легко превращается в обычную функцию. Изначально он был сложнее - буфер передавался как один из параметров дефайна, поэтому функция не подходила - sizeof(buf) не работал как задумано.

можно обойтись без задания конкретной длины 128? ведь формат может быть по длинее. ну вообще довольно таки здорово! Спасибо!
allprofi Будут ли еще варианты?

Это сообщение отредактировал(а) segadir - 7.9.2010, 16:26

Вот раскопал оригинальный дефайн. Первым параметром передается заранее приготовленный буфер нужной длины. Но я от этого варианта отказался, потому что на деле 128 байт хватает с головой, а громоздкость кода значительно уменьшается.

Пожалуйста!

djamshud, глобальный буффер...  сделайте его либо локальным, либо добавьте глобальный мьютекс.


именно. благо что говорится про Си. ибо в с++ нельзя использовать strftime().
единственный абсолютно правильный вариант - boost.format

очень хотел бы услышать про то как можно отказаться от фиксированной (128)  длины массива, 
т.е. длина сама бы задавалась в зависимости от входной строки.
как вариант сделать - динамическим
но может есть что либо так сказать "по изящнее" ? а?

IMHO функция по-любому лучше.
1. Можно сделать параметр форматирования по-умолчанию, например "dd.MM.yyyy hh:mm:ss"
2. Можно вернуть std::string
3. Буфер можно выделить на стеке

и зачем в конце делается 

?

   Это почему?

да но я думаю это спарведливо только к С++??? или нет?

только 

а выделить память на стеке можно и в Си.
Правда в данном случае от неё толку не будет, потому, что вернуть char * на такую память нельзя
вернее можно, но получишь краш :(

кстати, твоё замечание нужно адресоватьи boost'овцам

Это сообщение отредактировал(а) borisbn - 7.9.2010, 18:10

Мне опять скучно ... 

1) Локальный буфер



Оформляем


Буфер будет локальным, и в пределах блока который был в дефайне, и "драки" имен между переменными быть не должно.

2) Глобальный буфер
Выше описанный спсоб будет работать, вот только в много поточном приложении будет плохо так что либо синхронизация(Mutex, CriticalSction) или
переменная нити(потока) __declspec(thread) для студии.


Sartorius, Можно, но только это микс С с С++, не которые личность утверждают что это от лукавого, но каждому свое.


borisbn

Креш не получи, так как память валидная, а вот гарантировать валидность данных, это не получится, так как при "закрутки" стека компилятор волен выбирать метод самостоятельно, так что это вы правы использовать НЕЛЬЗЯ.

boostcoder, во-первых, не каждое приложение многопоточно; во-вторых, многопоточность - костыль; в-третьих, буфер локален в пределах одного объектного файла. Но вообще, да :).

borisbn,

>и зачем в конце делается 

Чтобы "вернуть" указатель из макроса. См., как раскрывается макрос в код.

icecrashldr, 

>локальный буфер

В общем да, только я его немного пропатчу для ТС:) "({})" - GCC-шное расширение, но без него никак: обычный #define macro{...} раскроется в код и все испортит, #define macro ... и нормальной "локальной" tm не сделает, и код попортит.

segadir,



Но обнаружился неприятный баг strftime-а: если сформированная им строка-дата не влезает в отведенный буфер, функция мало того, что не выставляет \0 в его конец, так еще и возвращает неправильный return value. В приведенных примерах я это пофиксил, но думается мне, надо писать багрепорт в ГНУ, т.к. в мане про этот баг ни слова не нашел.

это еще почему?  

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

  


а..это вы в контексте обозначенной проблемы? я думал вообще, так сказать глобально