Здравствуйте, __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?
Я думаю, написать функцию форматирования строки займет у Вас (опытного программиста) не более 20 минут.
Здравствуйте, __Dmitry__, Вы писали:
__D>Очень хочеться printf-like output и не зависеть от сторонних библиотек типа __D><atlstr>, <boost.format>
А что заставляет считать буст сторонней библиотекой? Убогий компилятор, политика партии или религия?
Если религия — то лучше религию поменять. Буст — это нашевсё и заготовка для стандартной библиотеки С++1х (хотя судя по темпам принятия 0х, при том, что уже кончается 2008 год, это будет С++2х какой-нибудь)
А против партии и компилятора, конечно, спорить трудно.
Здравствуйте, __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
Глянь, может понравится (как лекарство от обоих проблем)
Здравствуйте, __Dmitry__, Вы писали:
__D>Здравствуйте, Alexander G, Вы писали:
__D>Очень хочеться printf-like output и не зависеть от сторонних библиотек типа __D><atlstr>, <boost.format> __D>А <sstream>, <strstream> жутко неудобны, потому как вывести что-то компактное типа %2.3f __D>или подобное не позволяют. Одних "<<", ">>" надо больше натайпить, чем рабочих __D>символов (см. %2.3f ). Да и читабельность кода эти "<<", ">>" отнюдь не повышают __D>Но я понял деваться некуда!
TarasKo wrote:
> вообще printf и компания не очень хороши, потому что запросто можно > набажить указав в формате, что печатаем допустим строку и подсунув по
Да даже в Джабе вводят форматный вывод уже. А ты тут возмущаешься.
Все перегрузы, манипуляторы и пр. хороши, да всё же почему-то
людям удобнее старый добрый форматный вывод.
Почему его нет в STD, как и многого другого, понятно:
это была сознательная диверсия, чтобы дискредитировать
хороший язык программирования. И отчасти им это удалось.
Но в конце концов победа будет за нами.
Nikita123 wrote:
> Я думаю, написать функцию форматирования строки займет у Вас (опытного > программиста) не более 20 минут.
Ага, функцию форматирования строки — 20 минут. Тесты — 2 дня.
Функцию обрезания — еще 20 минут. Тесты — еще 2 дня.
И так далее , и так далее. Я что, нанялся стандартную библиотеку для
С++ писать ?
Здравствуйте, __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, в остальных случаях эту выдранную строку.
Здравствуйте, 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 ). Да и читабельность кода эти "<<", ">>" отнюдь не повышают
Но я понял деваться некуда!
Здравствуйте, Кодт, Вы писали:
К>Если религия — то лучше религию поменять. Буст — это нашевсё и заготовка для стандартной библиотеки С++1х (хотя судя по темпам принятия 0х, при том, что уже кончается 2008 год, это будет С++2х какой-нибудь)
Они вроде обещались исправиться, и впредь выпускать по стандарту за три года.
MZ>Почему его нет в STD, как и многого другого, понятно: MZ>это была сознательная диверсия, чтобы дискредитировать MZ>хороший язык программирования. И отчасти им это удалось. MZ>Но в конце концов победа будет за нами.
А как думаете организивать форматированный вывод в std::basic_string<float> ?
Просто концепция STL слишком абстрагирована от таких частностей.
Юзайте бустовелосипеды, в чем проблема то?
Привет all!
Хотел бы услышать у кого, что с опытом прежилось
из C++ string api ?
Собственно я вижу два более менее "стандарта":
1) std::string ( <string> )
2) atl::CString ( <atlstr.h> )
Проблемы заключается в том, что :
а) для 1-ого случая для форматирования требуются
"костыли" в коде типа _stprintf_s. Не понимаю, почему
не встроили "штатное" форматирование в std::string?
б) второй случай можно назвать "стандартным" только в
для vc и то, не Express Ed.
Вот поэтому и интересуюсь как кто справляется с этими
"невзгодами" судьбы программистской...
вообще 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.
Здравствуйте, skeptik_, Вы писали:
_>Здравствуйте, Кодт, Вы писали:
К>>Если религия — то лучше религию поменять. Буст — это нашевсё и заготовка для стандартной библиотеки С++1х (хотя судя по темпам принятия 0х, при том, что уже кончается 2008 год, это будет С++2х какой-нибудь)
_>Они вроде обещались исправиться, и впредь выпускать по стандарту за три года.
Хехе, они б еще компиляторы выпускали поддерживающие то что настандартизирвали, цены б им небыло
Здравствуйте, MShura, Вы писали:
TK>>И такие проблемы на этапе компиляции никак не выявляются а всплывают на этапе выполнения и очень неприятно.
MS>gcc прекрасно отлавливает это на этапе компиляции
// =============================================================================
// 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.
x-code wrote: > Это зависит от корпоративных стандартов Я в свое время не стал париться, > выдрал из MFC строку CString, выкинул оттуда все виндовское и сделал ее > кроссплатформенной. И под линуксом реально работает,
Та же фигня.
и код проверенный > (MFC весь мир юзал и юзает еще), и форматирование есть, и куча > вспомогательных функций преобразования строк, и если что можно внести > изменения. Но в 90% контор такой подход не прокатит.
Здравствуйте, MasterZiv, Вы писали:
>> изменения. Но в 90% контор такой подход не прокатит.
MZ>Почему, кстати ?
Ну это Вы спрашивайте не у меня Возможно, потому что там требуется какое-то лицензирование и подобные вещи, где-то отдают исходники заказчику, возможно потому что все что не stl и не boost — не кошерно, вариантов может быть много...
Здравствуйте, 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 слишком абстрагирована от таких частностей.
x-code wrote:
> MZ>Почему, кстати ? > Ну это Вы спрашивайте не у меня Возможно, потому что там требуется > какое-то лицензирование и подобные вещи,
Так я же говорю, опен соурс уже давно MFC-шная строка.
Не знаю какая там лицензия, но какая-то разрешающая. должна быть.
В WTL она входит.
Posted via RSDN NNTP Server 2.1 beta
Re[5]: Строки. Наболело...
От:
Аноним
Дата:
09.09.08 08:21
Оценка:
>> Просто концепция STL слишком абстрагирована от таких частностей. MZ>Вот в этом-то и проблема.
В чем проблема-то? Есть высокоабстаргирванная стандартная библиотека, есть куча более приспособленная к жизни библиотека использующая ее, в котором есть ваш любимый формат. Юзайте ее на здоровье. Зачем каждый пук в стандарт пихать то?
Здравствуйте, MasterZiv, Вы писали:
>> Я думаю, написать функцию форматирования строки займет у Вас (опытного >> программиста) не более 20 минут. MZ>Ага, функцию форматирования строки — 20 минут. Тесты — 2 дня. MZ>Функцию обрезания — еще 20 минут. Тесты — еще 2 дня.
Да ладно Вам. Я потратил на библиотеку, расширяющую std::string (класс,
содержищий 20 методов), всего 2 рабочих дня, включая отладку и тестирование.
MZ>И так далее , и так далее. Я что, нанялся стандартную библиотеку для С++ писать?
А зачем? Она уже написана до Вас. И переписывать ее нет никакого смысла.
Здравствуйте, 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 и т.п.). В результате никаких проблем с форматированием + никаких проблем с многопоточностью.
Здравствуйте, Nikita123, Вы писали:
N>Да ладно Вам. Я потратил на библиотеку, расширяющую std::string (класс, N>содержищий 20 методов), всего 2 рабочих дня, включая отладку и тестирование.
И что, она умеет делать сама все то, что делает sprintf?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, anonim_44ax, Вы писали:
MZ>>Вообще, на сколько я знаю, MFC-шный CString теперь входит в том числе в WTF, _>WTF — это "Worse Than Failure" ? В принципе стандартно для MS
Имелось в виду WTL, Windows Template Library.
А WTF имеет гораздо более экспрессивное значение; "worse than failure" — это эвфемизм.
К>А WTF имеет гораздо более экспрессивное значение; "worse than failure" — это эвфемизм.
Ну "более экспрессивные" высказывания на форуме вроде запрещены