Re[3]: Строки. Наболело... - C/C++

Привет all!
Хотел бы услышать у кого, что с опытом прежилось
из C++ string api ?
Собственно я вижу два более менее "стандарта":
1) std::string ( <string> )
2) atl::CString ( <atlstr.h> )

Проблемы заключается в том, что :
а) для 1-ого случая для форматирования требуются
"костыли" в коде типа _stprintf_s. Не понимаю, почему
не встроили "штатное" форматирование в std::string?
б) второй случай можно назвать "стандартным" только в
для vc и то, не Express Ed.

Вот поэтому и интересуюсь как кто справляется с этими
"невзгодами" судьбы программистской...

Всем заранее спасибо за ответы!

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

__D>Вот поэтому и интересуюсь как кто справляется с этими
__D>"невзгодами" судьбы программистской...

переходим на С#

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

вообще printf и компания не очень хороши, потому что запросто можно набажить указав в формате, что печатаем допустим строку и подсунув по ошибке объект или число. И такие проблемы на этапе компиляции никак не выявляются а всплывают на этапе выполнения и очень неприятно. Что бы разрулить эту проблему был придуман C++ с перегрузкой, (ну не только эту

) ) и потоками ввода вывода. для форматирования я использую ostringstream(wostringstream) из sstream работает чуть помедленнее и иногда не очень удобно, но зато если что-то не то, просто не скомпилируется. Есть ещё boost::format

__D>Привет all!
__D>Хотел бы услышать у кого, что с опытом прежилось
__D>из C++ string api ?
__D>Собственно я вижу два более менее "стандарта":
__D>1) std::string ( <string> )
__D>2) atl::CString ( <atlstr.h> )

__D>Проблемы заключается в том, что :
__D>а) для 1-ого случая для форматирования требуются
__D>"костыли" в коде типа _stprintf_s. Не понимаю, почему
__D>не встроили "штатное" форматирование в std::string?
__D>б) второй случай можно назвать "стандартным" только в
__D>для vc и то, не Express Ed.

__D>Вот поэтому и интересуюсь как кто справляется с этими
__D>"невзгодами" судьбы программистской...

__D>Всем заранее спасибо за ответы!

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

__D>Привет all!
__D>Хотел бы услышать у кого, что с опытом прежилось
__D>из C++ string api ?
__D>Собственно я вижу два более менее "стандарта":
__D>1) std::string ( <string> )
__D>2) atl::CString ( <atlstr.h> )

__D>Проблемы заключается в том, что :
__D>а) для 1-ого случая для форматирования требуются
__D>"костыли" в коде типа _stprintf_s. Не понимаю, почему
__D>не встроили "штатное" форматирование в std::string?

Штатное — <strstream>
Более printf-way — Boost.Format

__D>б) второй случай можно назвать "стандартным" только в
__D>для vc и то, не Express Ed.

Если и так код со студии никуда не уйдёт, например код GUI на WTL, то почему бы не юзать CString.
Если нужна переносимость — то лучше std::string.

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

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

__D>>Привет all!
__D>>Хотел бы услышать у кого, что с опытом прежилось
__D>>из C++ string api ?
__D>>Собственно я вижу два более менее "стандарта":
__D>>1) std::string ( <string> )
__D>>2) atl::CString ( <atlstr.h> )

__D>>Проблемы заключается в том, что :
__D>>а) для 1-ого случая для форматирования требуются
__D>>"костыли" в коде типа _stprintf_s. Не понимаю, почему
__D>>не встроили "штатное" форматирование в std::string?

AG>Штатное — <strstream>
AG>Более printf-way — Boost.Format

__D>>б) второй случай можно назвать "стандартным" только в
__D>>для vc и то, не Express Ed.

AG>Если и так код со студии никуда не уйдёт, например код GUI на WTL, то почему бы не юзать CString.
AG>Если нужна переносимость — то лучше std::string.

Очень хочеться printf-like output и не зависеть от сторонних библиотек типа
<atlstr>, <boost.format>
А <sstream>, <strstream> жутко неудобны, потому как вывести что-то компактное типа %2.3f
или подобное не позволяют. Одних "<<", ">>" надо больше натайпить, чем рабочих
символов (см. %2.3f ). Да и читабельность кода эти "<<", ">>" отнюдь не повышают

Но я понял деваться некуда!

Всем еще раз спасибо!

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

TK>И такие проблемы на этапе компиляции никак не выявляются

ну как же, PREfast их ловит только так

TK>И такие проблемы на этапе компиляции никак не выявляются а всплывают на этапе выполнения и очень неприятно.

gcc прекрасно отлавливает это на этапе компиляции

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

__D>Здравствуйте, Alexander G, Вы писали:

__D>Очень хочеться printf-like output и не зависеть от сторонних библиотек типа
__D><atlstr>, <boost.format>
__D>А <sstream>, <strstream> жутко неудобны, потому как вывести что-то компактное типа %2.3f
__D>или подобное не позволяют. Одних "<<", ">>" надо больше натайпить, чем рабочих
__D>символов (см. %2.3f ). Да и читабельность кода эти "<<", ">>" отнюдь не повышают

__D>Но я понял деваться некуда!

Как это не куда?

Ну нарисуй себе нечто типа:

inline std::wstring format(const wchar_t *fmt,...) 
{
  wchar_t buffer[2049];
  va_list args;
  va_start (args, fmt);
  do_w_vsnprintf( buffer, 2048, fmt, args );
  va_end (args);
  return buffer;
}

и гори оно огнем.

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

__D>Очень хочеться printf-like output и не зависеть от сторонних библиотек типа
__D><atlstr>, <boost.format>

А что заставляет считать буст сторонней библиотекой? Убогий компилятор, политика партии или религия?

Если религия — то лучше религию поменять. Буст — это нашевсё и заготовка для стандартной библиотеки С++1х (хотя судя по темпам принятия 0х, при том, что уже кончается 2008 год, это будет С++2х какой-нибудь)

А против партии и компилятора, конечно, спорить трудно.

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

К>Если религия — то лучше религию поменять. Буст — это нашевсё и заготовка для стандартной библиотеки С++1х (хотя судя по темпам принятия 0х, при том, что уже кончается 2008 год, это будет С++2х какой-нибудь)

Они вроде обещались исправиться, и впредь выпускать по стандарту за три года.

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

_>Здравствуйте, Кодт, Вы писали:

К>>Если религия — то лучше религию поменять. Буст — это нашевсё и заготовка для стандартной библиотеки С++1х (хотя судя по темпам принятия 0х, при том, что уже кончается 2008 год, это будет С++2х какой-нибудь)

_>Они вроде обещались исправиться, и впредь выпускать по стандарту за три года.

Хехе, они б еще компиляторы выпускали поддерживающие то что настандартизирвали, цены б им небыло

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

TK>>И такие проблемы на этапе компиляции никак не выявляются а всплывают на этапе выполнения и очень неприятно.

MS>gcc прекрасно отлавливает это на этапе компиляции

Хм, да действительно. Беру слова обратно

TarasKo wrote:

> вообще printf и компания не очень хороши, потому что запросто можно
> набажить указав в формате, что печатаем допустим строку и подсунув по

Да даже в Джабе вводят форматный вывод уже. А ты тут возмущаешься.
Все перегрузы, манипуляторы и пр. хороши, да всё же почему-то
людям удобнее старый добрый форматный вывод.

Почему его нет в STD, как и многого другого, понятно:
это была сознательная диверсия, чтобы дискредитировать
хороший язык программирования. И отчасти им это удалось.
Но в конце концов победа будет за нами.

Posted via RSDN NNTP Server 2.1 beta

__Dmitry__ wrote:

> Очень хочеться printf-like output и не зависеть от сторонних библиотек типа
> <atlstr>, <boost.format>

Вообще, на сколько я знаю, MFC-шный CString теперь входит в том числе в WTF,
т.е. open-source. Выдерай CString::Format и пользуйся.

Posted via RSDN NNTP Server 2.1 beta

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

в проекте используем:

// =============================================================================
// FILE: StdString.h
// AUTHOR: Joe O'Leary (with outside help noted in comments)
//
// If you find any bugs in this code, please let me know:
//
// jmoleary@earthlink.net
// http://www.joeo.net/stdstring.htm (a bit outdated)
//
// The latest version of this code should always be available at the
// following link:
//
// http://www.joeo.net/code/StdString.zip (Dec 6, 2003)
//
//
// REMARKS:
// This header file declares the CStdStr template. This template derives
// the Standard C++ Library basic_string<> template and add to it the
// the following conveniences:
// — The full MFC CString set of functions (including implicit cast)
// — writing to/reading from COM IStream interfaces
// — Functional objects for use in STL algorithms
//
// From this template, we intstantiate two classes: CStdStringA and
// CStdStringW. The name "CStdString" is just a #define of one of these,
// based upone the UNICODE macro setting
//
// This header also declares our own version of the MFC/ATL UNICODE-MBCS
// conversion macros. Our version looks exactly like the Microsoft's to
// facilitate portability.
//
// NOTE:
// If you you use this in an MFC or ATL build, you should include either
// afx.h or atlbase.h first, as appropriate.

если аккуратно, то пользоваться можно
здесь

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

__D>Хотел бы услышать у кого, что с опытом прежилось
__D>из C++ string api ?
__D>Собственно я вижу два более менее "стандарта":
__D>1) std::string ( <string> )
__D>2) atl::CString ( <atlstr.h> )

Это зависит от корпоративных стандартов

Я в свое время не стал париться, выдрал из MFC строку CString, выкинул оттуда все виндовское и сделал ее кроссплатформенной. И под линуксом реально работает, и код проверенный (MFC весь мир юзал и юзает еще), и форматирование есть, и куча вспомогательных функций преобразования строк, и если что можно внести изменения. Но в 90% контор такой подход не прокатит.
Соответственно, там где нужет stl использую std::string, в остальных случаях эту выдранную строку.

Nikita123 wrote:

> Я думаю, написать функцию форматирования строки займет у Вас (опытного
> программиста) не более 20 минут.

Ага, функцию форматирования строки — 20 минут. Тесты — 2 дня.
Функцию обрезания — еще 20 минут. Тесты — еще 2 дня.
И так далее , и так далее. Я что, нанялся стандартную библиотеку для
С++ писать ?

Posted via RSDN NNTP Server 2.1 beta

x-code wrote:
> Это зависит от корпоративных стандартов Я в свое время не стал париться,
> выдрал из MFC строку CString, выкинул оттуда все виндовское и сделал ее
> кроссплатформенной. И под линуксом реально работает,

Та же фигня.

и код проверенный
> (MFC весь мир юзал и юзает еще), и форматирование есть, и куча
> вспомогательных функций преобразования строк, и если что можно внести
> изменения. Но в 90% контор такой подход не прокатит.

Почему, кстати ?

Posted via RSDN NNTP Server 2.1 beta

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

>> изменения. Но в 90% контор такой подход не прокатит.

MZ>Почему, кстати ?
Ну это Вы спрашивайте не у меня

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

MZ>Почему его нет в STD, как и многого другого, понятно:
MZ>это была сознательная диверсия, чтобы дискредитировать
MZ>хороший язык программирования. И отчасти им это удалось.
MZ>Но в конце концов победа будет за нами.
А как думаете организивать форматированный вывод в std::basic_string<float> ?

Просто концепция STL слишком абстрагирована от таких частностей.
Юзайте бустовелосипеды, в чем проблема то?

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

MZ>Nikita123 wrote:

>> Я думаю, написать функцию форматирования строки займет у Вас (опытного
>> программиста) не более 20 минут.

MZ>Ага, функцию форматирования строки — 20 минут. Тесты — 2 дня.
MZ>Функцию обрезания — еще 20 минут. Тесты — еще 2 дня.
MZ>И так далее , и так далее. Я что, нанялся стандартную библиотеку для
MZ>С++ писать ?

Да и не только во времени дело...
Архитектура страдает ... в каждом приложения будем
"маячить"
1) эта самописная функция
2) врапы string, wstring под юникод и мултибайт
в итоге все это выглядит как "костыли"...нет ощущения
foundation-а в стандартных библиотеках (раз уж таковой
претендует быть STL)

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

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

MZ>>Nikita123 wrote:

>>> Я думаю, написать функцию форматирования строки займет у Вас (опытного
>>> программиста) не более 20 минут.

MZ>>Ага, функцию форматирования строки — 20 минут. Тесты — 2 дня.
MZ>>Функцию обрезания — еще 20 минут. Тесты — еще 2 дня.
MZ>>И так далее , и так далее. Я что, нанялся стандартную библиотеку для
MZ>>С++ писать ?

__D>Да и не только во времени дело...
__D>Архитектура страдает ... в каждом приложения будем
__D>"маячить"
__D>1) эта самописная функция
__D>2) врапы string, wstring под юникод и мултибайт
__D>в итоге все это выглядит как "костыли"...нет ощущения
__D>foundation-а в стандартных библиотеках (раз уж таковой
__D>претендует быть STL)

Извинясь может кого задел таким категоричным отзывом об
STL, я имел ввиду работу со строками в STL.
Отсальные парадигмы — контейнеры и итераторы — это
конечно хорошо!

Аноним 524 wrote:

> А как думаете организивать форматированный вывод в
> std::basic_string<float> ?

Я -никак не думаю, я думаю, что есть комитет по стандартизации,
которым деньги платят за то, что они думают об этом.
Вот они пусть и думают.

> Просто концепция STL слишком абстрагирована от таких частностей.

Вот в этом-то и проблема.

Posted via RSDN NNTP Server 2.1 beta

x-code wrote:

> MZ>Почему, кстати ?
> Ну это Вы спрашивайте не у меня Возможно, потому что там требуется
> какое-то лицензирование и подобные вещи,

Так я же говорю, опен соурс уже давно MFC-шная строка.
Не знаю какая там лицензия, но какая-то разрешающая. должна быть.
В WTL она входит.

Posted via RSDN NNTP Server 2.1 beta

>> Просто концепция STL слишком абстрагирована от таких частностей.
MZ>Вот в этом-то и проблема.
В чем проблема-то? Есть высокоабстаргирванная стандартная библиотека, есть куча более приспособленная к жизни библиотека использующая ее, в котором есть ваш любимый формат. Юзайте ее на здоровье. Зачем каждый пук в стандарт пихать то?

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

>> Я думаю, написать функцию форматирования строки займет у Вас (опытного
>> программиста) не более 20 минут.
MZ>Ага, функцию форматирования строки — 20 минут. Тесты — 2 дня.
MZ>Функцию обрезания — еще 20 минут. Тесты — еще 2 дня.
Да ладно Вам. Я потратил на библиотеку, расширяющую std::string (класс,
содержищий 20 методов), всего 2 рабочих дня, включая отладку и тестирование.

MZ>И так далее , и так далее. Я что, нанялся стандартную библиотеку для С++ писать?
А зачем? Она уже написана до Вас. И переписывать ее нет никакого смысла.

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

__D>Привет all!
__D>Хотел бы услышать у кого, что с опытом прежилось
__D>из C++ string api ?
__D>Собственно я вижу два более менее "стандарта":
__D>1) std::string ( <string> )
__D>2) atl::CString ( <atlstr.h> )

__D>Проблемы заключается в том, что :
__D>а) для 1-ого случая для форматирования требуются
__D>"костыли" в коде типа _stprintf_s. Не понимаю, почему
__D>не встроили "штатное" форматирование в std::string?
__D>б) второй случай можно назвать "стандартным" только в
__D>для vc и то, не Express Ed.

__D>Вот поэтому и интересуюсь как кто справляется с этими
__D>"невзгодами" судьбы программистской...

__D>Всем заранее спасибо за ответы!

У Matthew Wilson-а (автора Imperfect C++) тоже наболело
Он недавно зарелизил FastFormat
Глянь, может понравится (как лекарство от обоих проблем)

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

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

__D>>Привет all!
__D>>Хотел бы услышать у кого, что с опытом прежилось
__D>>из C++ string api ?
__D>>Собственно я вижу два более менее "стандарта":
__D>>1) std::string ( <string> )
__D>>2) atl::CString ( <atlstr.h> )

__D>>Проблемы заключается в том, что :
__D>>а) для 1-ого случая для форматирования требуются
__D>>"костыли" в коде типа _stprintf_s. Не понимаю, почему
__D>>не встроили "штатное" форматирование в std::string?
__D>>б) второй случай можно назвать "стандартным" только в
__D>>для vc и то, не Express Ed.

__D>>Вот поэтому и интересуюсь как кто справляется с этими
__D>>"невзгодами" судьбы программистской...

__D>>Всем заранее спасибо за ответы!

S>У Matthew Wilson-а (автора Imperfect C++) тоже наболело
S>Он недавно зарелизил FastFormat
S>Глянь, может понравится (как лекарство от обоих проблем)

Спасибо!
Очень интересно!

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

__D>Привет all!
__D>Хотел бы услышать у кого, что с опытом прежилось
__D>из C++ string api ?
__D>Собственно я вижу два более менее "стандарта":
__D>1) std::string ( <string> )
__D>2) atl::CString ( <atlstr.h> )

__D>Проблемы заключается в том, что :
__D>а) для 1-ого случая для форматирования требуются
__D>"костыли" в коде типа _stprintf_s. Не понимаю, почему
__D>не встроили "штатное" форматирование в std::string?
__D>б) второй случай можно назвать "стандартным" только в
__D>для vc и то, не Express Ed.

__D>Вот поэтому и интересуюсь как кто справляется с этими
__D>"невзгодами" судьбы программистской...

__D>Всем заранее спасибо за ответы!

Как выяснилось, в большинстве случаев динамические строки не очень то и нужны. Написал шаблон строк с фиксированным размером буфера и интерфейсом а-ля std::string (+ format, append_format, trim, pad и т.п.). В результате никаких проблем с форматированием + никаких проблем с многопоточностью.

MZ>Вообще, на сколько я знаю, MFC-шный CString теперь входит в том числе в WTF,
WTF — это "Worse Than Failure" ?

В принципе стандартно для MS

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

N>Да ладно Вам. Я потратил на библиотеку, расширяющую std::string (класс,
N>содержищий 20 методов), всего 2 рабочих дня, включая отладку и тестирование.
И что, она умеет делать сама все то, что делает sprintf?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

MZ>>Вообще, на сколько я знаю, MFC-шный CString теперь входит в том числе в WTF,
_>WTF — это "Worse Than Failure" ?

В принципе стандартно для MS

Имелось в виду WTL, Windows Template Library.
А WTF имеет гораздо более экспрессивное значение; "worse than failure" — это эвфемизм.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

	От:	__Dmitry__
	Дата:	05.09.08 17:18
	Оценка:

	От:	Аноним
	Дата:	05.09.08 17:58
	Оценка:	-1

	От:	TarasKo
	Дата:	05.09.08 18:14
	Оценка:

	От:	Alexander G
	Дата:	05.09.08 18:51
	Оценка:

	От:	__Dmitry__
	Дата:	05.09.08 19:06
	Оценка:	+1

От:	c-smile	http://terrainformatica.com
Дата:	05.09.08 20:04
Оценка:	1 (1) +1 -1

От:	Sanik	http://sergeysthoughts.blogspot.com/
Дата:	10.09.08 09:52
Оценка:	15 (3)

	От:	Кодт
	Дата:	06.09.08 08:21
	Оценка:	+3 -1

	От:	skeptik_
	Дата:	06.09.08 09:30
	Оценка:

	От:	Danchik
	Дата:	06.09.08 10:18
	Оценка:

	От:	MasterZiv
	Дата:	08.09.08 07:26
	Оценка:	+1