|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Artem Chuprina 2:5020/400 07 May 2007 20:30:32
To : Roman Belenov
Subject : Re: Debian vs Ubuntu
--------------------------------------------------------------------------------
.com> <64802336@tigger.lan.cryptocom.ru> <uodkwejex.fsf@intel.com>
From: Artem Chuprina <ran+news@ran.pp.ru>
Roman Belenov -> Artem Chuprina @ Mon, 7 May 2007 15:49:20 +0000 (UTC):
>> Я, скажем так, знаю очень немного задач, которые туда не влезают. И
>> обработка строк вообще и с интерфейсом std::string особенно там, как
>> правило, гм, ни к чему.
RB> Практически везде, где строки нужны постольку-поскольку (но при
RB> этом нужно молотить бинарные данные), готовый std::string по
RB> сравнению с char* вполне себе экономит время кодирования.
Там, где строки нужны постольку поскольку, обычно на ура работает
printf. Даже не sprintf :-)
А там, где они чуть более нужны - std::string точно так же не отличает
символ от байта и потому нафиг не пригоден.
А бинарные данные - да, надо молотить в C. Вон, в соседнем окне
выглядывает из-за угла сишничек. 20 строк тиклового API (сообщения об
ошибках, формирование результата и оформление в пакет) и собственно
молотилка. А работа с файлами, сокетами и строками - tcl. Я что,
маньяк ее на C писать? Спасибо, сишную ее часть за меня уже написали.
>> Hу, будет у тебя другая ошибка... std::string спокойно переживает
>> нулевой символ в середине строки, а функции, которые ты на ее
>> содержимое вызываешь - нет. Довольно стандартная грабля.
RB> Это уже ошибка в алгоритме (откуда бы этому нулевому символу там
RB> изначально взяться?),
А чем он хуже других?
RB> в то время как указатели тащат за собой проблемы, специфичные
RB> именно для них.
Если правильно писать на C, никаких проблем с указателями не будет.
Другое дело, что правильно очень мало кто умеет.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
/итд/почтопосылалка.нстрк (c)
--- ifmail v.2.15dev5.3
* Origin: Leninsky 45 home network (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
