Вопрос тем кто пишет на C: Что вы используете вместо сиплюсплюсного std::string? Нет ли какой-нибудь популярной библиотеки позволяющей писать примерно так?:

void f(char *pathname);

void g(char *path, char *filename)
{
    struct String s;

    String_construct(&s, path);
    String_append(&s, filename);
    f(String_c_str(&s));
    String_destruct(&s);
}

Здравствуйте, igna, Вы писали:

I>Вопрос тем кто пишет на C: Что вы используете вместо сиплюсплюсного std::string? Нет ли какой-нибудь популярной библиотеки позволяющей писать примерно так?:

CString (ATL)

Здравствуйте, den123, Вы писали:

I>>Вопрос тем кто пишет на C: Что вы используете вместо сиплюсплюсного std::string? Нет ли какой-нибудь популярной библиотеки позволяющей писать примерно так?:

D>CString (ATL)

Это C?

Здравствуйте, Alxndr, Вы писали:

A>Здравствуйте, den123, Вы писали:

I>>>Вопрос тем кто пишет на C: Что вы используете вместо сиплюсплюсного std::string? Нет ли какой-нибудь популярной библиотеки позволяющей писать примерно так?:

D>>CString (ATL)

A>Это C?
C++

Здравствуйте, den123, Вы писали:

I>>>>Вопрос тем кто пишет на C: Что вы используете вместо сиплюсплюсного std::string? Нет ли какой-нибудь популярной библиотеки позволяющей писать примерно так?:
D>>>CString (ATL)
A>>Это C?
D>C++

А спрашивали-то про С.
Кроме того из тематика форума C/C++. Прикладные вопросы

Автор: Павел Кузнецов
Дата: 17.10.04

:

Off-topic
...
* Библиотеки, API и т.п., для которых существуют специальные форумы: MFC, ATL, WTL, Win API, .Net Framework и т.п.

Добрый день!

Если нет возможности перейти на C++, то рекомендую GLib (http://www.gtk.org):
http://library.gnome.org/devel/glib/unstable/glib-Strings.html

Здравствуйте, syomin, Вы писали:

S>Добрый день!

S>Если нет возможности перейти на C++, то рекомендую GLib (http://www.gtk.org):
S>http://library.gnome.org/devel/glib/unstable/glib-Strings.html

unstable ?

Здравствуйте, Alxndr, Вы писали:

I>>>Вопрос тем кто пишет на C
D>>CString (ATL)

A>Это C?

Ну как же, CString!

;-)

Добрый день!
_>unstable ? :wow:
Нет, это просто документация от development-версии. Самой библиотеке уже черт знает сколько лет...

Здравствуйте, igna, Вы писали:

I>Вопрос тем кто пишет на C: Что вы используете вместо сиплюсплюсного std::string? Нет ли какой-нибудь популярной библиотеки позволяющей писать примерно так?:

SFL.
http://legacy.imatix.com/html/sfl/

Здравствуйте, igna, Вы писали:

I>Вопрос тем кто пишет на C: Что вы используете вместо сиплюсплюсного std::string? Нет ли какой-нибудь популярной библиотеки позволяющей писать примерно так?:

I>

I>void f(char *pathname);

I>void g(char *path, char *filename)
I>{
I>    struct String s;

I>    String_construct(&s, path);
I>    String_append(&s, filename);
I>    f(String_c_str(&s));
I>    String_destruct(&s);
I>}
I>

Можно ли поинтересоваться "а зачем?" — ?

Здравствуйте, The Lex, Вы писали:

TL>Можно ли поинтересоваться "а зачем?" — ?

А как ты пишешь? Ну вот эту, мной приведенную функцию по-своему перепиши.

Здравствуйте, igna, Вы писали:

TL>>Можно ли поинтересоваться "а зачем?" — ?

I>А как ты пишешь? Ну вот эту, мной приведенную функцию по-своему перепиши.

На Си? Пользуюсь статическими буферами и стандартными функциями.

void f(char *pathname);

void g(char *path, char *filename)
{
    char s[MAX_PATH_LEN_CONST_DEF]; //  struct String s;

    snrcpy(s, path); // String_construct(&s, path);
    strcat(s, filename); // String_append(&s, filename);
    f(s); // f(String_c_str(&s));
    // String_destruct(&s);
}

Кстати, передача в f(...) структуры по указателю — идеологически неверно. Ах да — это ведь Си — другого выхода по скорости нет...

Здесь я понимаю что я, теоретически, не учитываю случай, когда у меня вдруг длина path + filename будет большой и вообще больше моего MAX_PATH_LEN_CONST_DEF, но...

Мне все же интересно, зачем использовать pure C вместо простого C++? Т.е. изначально почему возникает такая потребность?

Здравствуйте, The Lex, Вы писали:

TL>Кстати, передача в f(...) структуры по указателю — идеологически неверно. Ах да — это ведь Си — другого выхода по скорости нет...

Уж все лучше, чем передача по ссылке. В Си хоть видно в точке вызова, получает вызываемая функция объект по значению или по ссылке. В C++, чтобы это узнать, приходится на объявление вызываемой функции смотреть...

TL>Здесь я понимаю что я, теоретически, не учитываю случай, когда у меня вдруг длина path + filename будет большой и вообще больше моего MAX_PATH_LEN_CONST_DEF, но...

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

Здравствуйте, igna, Вы писали:

I>Вопрос тем кто пишет на C: Что вы используете вместо сиплюсплюсного std::string? Нет ли какой-нибудь популярной библиотеки позволяющей писать примерно так?:

Я написал себе сто лет назад специальную библиотечку для строк, и с тех пор ей пользуюсь. Очень удобно.

Здравствуйте, Pzz, Вы писали:

Pzz>Вы, может быть, феномен, и в реальных программах всегда проверяете, не случился ли buffer overflow. Однако большинство людей не обладают этим феноменальным качеством. От чего в программах, написанных ими, появляются хорошо запрятанные уязвимости.

Я пишу программы, которые работают в условиях "достаточного ограничения окружения". Уязвимости уровня записи за пределы буфера в стеке современный C-рантайм "выкупает на раз": в свое время я с удивление "выгреб" целую кучку таких утечек (следует признать, функционально некритичных — иначе не дожил бы... ) при переходе VC 6.0 -> VC 7.0. Я почему спрашиваю и удивляюсь? Потому что мне непонятны исходное ограничение "ANSI C only" — мне действительно как практику интересно в каких сферах все еще актуально такое ограничение. Всякие "левые и мелкие платформы" имеет свойство ценить каждый байт и каждую команду процессора — показанный пример очень простой на очень простой реализации "библиотеки строчных функций" тут же даст очень непростой оверхед как по скорости, так и по фрагментации динамической памяти.

Впрочем... похоже я веду монолог.

TL>Мне все же интересно, зачем использовать pure C вместо простого C++? Т.е. изначально почему возникает такая потребность?

Есть среды, где C++ исключения не поддерживаются.
Например ядро Linux, ядро Windows (драйвера и native приложения)
Использовать C++ без исключений — пожалуйста (правда не для Linux > 2.6.18)

Здравствуйте, The Lex, Вы писали:

TL>Я почему спрашиваю и удивляюсь? Потому что мне непонятны исходное ограничение "ANSI C only" — мне действительно как практику интересно в каких сферах все еще актуально такое ограничение.

(Из жизни)
Предположим, для левой и экзотической платформы написали C-компилятор, но не написали C++?

Здравствуйте, The Lex, Вы писали:

TL>Здравствуйте, Pzz, Вы писали:

TL>Я пишу программы, которые работают в условиях "достаточного ограничения окружения". Уязвимости уровня записи за пределы буфера в стеке современный C-рантайм "выкупает на раз": в свое время я с удивление "выгреб" целую кучку таких утечек (следует признать, функционально некритичных — иначе не дожил бы... ) при переходе VC 6.0 -> VC 7.0.

Как, по-Вашему, он их "выкупает"? Hint: аппаратура позволяет организовать страницу в памяти (вернее, в адресном пространстве), попытка обращения к которой вызывает аппаратное исключение. Т.е., если обложить буфер такими страницами, то выход за храницу такого буфера будет пойман, при условии, что он 1) дотянется до следующей невалидной страницы 2) не дотянется до следующей нормальной памяти. Т.е., если повезет.

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

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

TL> Я почему спрашиваю и удивляюсь? Потому что мне непонятны исходное ограничение "ANSI C only"

Причин может быть миллион. Например то, что не все еще считают C++ лучшим языком всех времен и народов. Или даже просто языком, лучшим, чем Си. У C++ есть масса недостатков (которых, Вы, возможно, привыкли не замечать), и существует масса людей (и я, например, из их числа), которые считают, что сумма недостатков перевешивает сумму достоинств.

Здравствуйте, igna, Вы писали:

I>Вопрос тем кто пишет на C: Что вы используете вместо сиплюсплюсного std::string?

http://bstring.sourceforge.net (тут есть сравнение разных библиотек)
http://www.ossp.org/pkg/lib/al
http://www.zork.org/safestr
http://daniel.haxx.se/trio/
http://www.and.org/ustr/

Но вообще с "просто" строками на чистом си (на с++, впрочем, тоже) лучше не работать . Если возникает такая необходимость, то лучше:

перенести эту функциональность на луа/ява-скрипт/любимый-встраиваемый-язык, благо их сейчас много;

поискать/написать библиотеку по "смыслу" используемых строк (в этом конкретном случае — библиотека для работы с путями).
Все это конечно IMHO.