stl используем во всю, а вот недоразумение под названием iostream - нет
несущественная деталь, можно добавить std::setfill('0') и всё будет хорошо
И будет еще больше нечитабельного кода.
понятно, значит не можете
Я могу, только принципиально не буду этого делать. Я за простые вещи, если что-то делается просто с помощью плюсовых конструкций - я буду их использовать, если что-то с помощью сишных - я буду их использовать.
да разговор начался с того что «фигня Ваш std::cout, я пользуюсь printf», некоторые товарищи тут не согласились, дальше по теме :)
на мой взгляд фишка в том что парадигма потоков (и в частности istringstream и ostringstream на которые был намёк) является более предпочтительной при использовании С++, в отличие от...
уж слишком много кода, тяжело отделить вывод от форматирования, не наглядно. Теряется красота кода.
всё что Вы назвали - очень субъективно, от отсутствия опыта Вам все эти буквы кажутся страшными и непонятными
не буду Вас убеждать, но вот мой Вам совет (Вы его вольны проигнорировать :)) - осильте концепцию потоков (на практике, желательно) и, возможно, Вы почувствуете логику и красоту подобного подхода
ты кретин, или долбоеб? спросили про принципиальную возможность - я ответил как можно, и написал сразу, что это бред, хотя такие долбоебы как ты видно читать два сообщения за раз не умеют
На самом деле каждый байт в библиотеке iostreams - это говно. Конечно, сам язык С++ это тоже не фонтан какой ЯП, но iostreams это прямо таки полюс говняности С++. Можно делать наглядным пособием на тему того как не надо проектировть абстракции.
Ну для объекта определено приведение к char* - указателю символы. Что стоит ожидать от такого приведения? Выделение памяти, запись туда некоторой строки и возвращение указателя. Указатель нигде не сохраняется и память под строку благополучно течет.
Ты напиши пример, где память будет течь, и мы посмеемся. )))
Тем более, что так не делается. Я говорю, что сделать безопасное приведение с char* нельзя. Ты говоришь, что можно и просишь меня сделать нечто неработающее.
> Я говорю, что сделать безопасное приведение с char* нельзя. Ты говоришь, что можно и просишь меня сделать нечто неработающее.
Ну тут варианта два. Либо ты сам допрешь, либо кто-нибудь еще влезет и всё тебе растолкует. Тем более, что объяснять то нечего. Всё уже разжевано до неприличия.
здорово конечно :) именно это выше я и показал со своим «Format(...)», на что мне сказали, что с потоками это делается удобнее - хочется увидеть, чем же?
очевидно же, что для перевода с одного языка на другой задачу не решить без ключиков внутри строки. Это должна быть отдельная задача, не связанная с вводом-выводом, который лучше гораздо на потоках делается.
> Это должна быть отдельная задача, не связанная с вводом-выводом
я ж не спорю :) но этот JackyTreehorn упорно твердит, что он знает более удобный способ написать ту строку, что я привел в предыдущем сообщении - пусть показывает
В разных языках может быть разная последовательность. Поэтому даже чистый printf задачу не решит, не говоря уже про cout << msgs.get (cat, 1, CODE1, def) << i << msgs.get (cat, 1, CODE2, def) << n;
Строка «item %1 of %2» может превратиться в строку «%2 %1 jskj rgfgfd fv dfvdv»
Поэтому и должно быть полное разделение задачи перевода строк и задачи вводы-вывода.
«я признаю, что твой вариант в этом случае более удобный, краткий и все такое.» - так это был сарказм такой? на самом деле ты до сих пор считаешь, что твой вариант лучше, да?
Там же, где и в исходном примере показаны «преимущества» потоков перед printf'ом, то есть нигде. А вот недостаток, который несет эта мнимая «простота» потоков я привел.
Все ошибки выявляет компилятор. Нет возможности вывести в поток- не будет откомпилирована программа. А с printf всё будет известно только в процессе работы программы.
правильно, потому что компилятор просто щаставили изучать строку формата, чтобы было меньше ошибок. Хоть это и не дело компилятора абсолютно. К синтаксису языка это не имеет отношения. И если это скрыть в функции-посреднике, то компилятор ничего не сможет сказать.
>ну зачем ты опять этот ущербный faq тащишь сюда???
Есть чего возразить по поводу поинта по ссылке?
да было б чему там возражать - то лузеры вайнят что кактус горький, ты лучше не ориентируйся на неосиляторов (козлёночком станешь), а читай как делают профессионалы
если ты не осилил ссылки на apachedev вот тебе туториал попроще
после того как осилишь разрешаю посмотреть ссылку на apachedev, которую тебе уже давали
вовсе и не страшный, просто язык сравнительного низкого уровня и программировать на нём - не клопов давить, требует определённой квалификации от программиста, да
это тот же случай когда человек пописал код на Qt и считает что он профессионал в С++, а это далеко не так
>да было б чему там возражать - то лузеры вайнят что кактус горький, ты лучше не ориентируйся на неосиляторов (козлёночком станешь), а читай как делают профессионалы
По ссылкам нет ничего по теме. Прочитай что пишет Alexander E. Patrakov еще раз.
Прежде чем так позориться, советую вспомнить какая точность у типа double. Представляю, сколько бы Вы 2.71бались с отладкой в попытках понять где же теряется точность.
#include<iostream>#include<cmath>usingnamespace std;
constdouble m_pi = 2*acos(0.0);
structX
{
double m;
voidread(istream & is){
is >> m;
}
voidwrite(ostream & os){
os << m;
}
};
не работает, потому что корректно сохранить состояние класса он не может
1) работает потому что выдаёт правильный результат
2) шо? какое состояние класса? никому он ничего не должен сохранять или Вы опять считаете что язык за Вас должен что-то дописывать? к тому же может вся фишка в том что точностью можно управлять снаружи относительно методов данной структуры... я не знаю о чём Вы там мечтали когда пример такой писали :)
> 1) работает потому что выдаёт правильный результат
Выдает правильный результат неправильным способом. Если делаете сериализацию в текстовый поток, то делате её нормально, чтобы вывод не зависел от внешних факторов.
2) шо? какое состояние класса?
Для тех кто в танке — set::precission надо вызывать внутри функции
write, а потом вернуть поток в первоначальное состояние, чтобы после вызова write сюрпризов не было.
PS. ох, жалко же мне ваших студентов, чую плохому бедных учите
Для тех кто в танке — set::precission надо вызывать внутри функции write, а потом вернуть поток в первоначальное состояние, чтобы после вызова write сюрпризов не было.
ещё раз, если у Вас таких структур летает целая куча и Вам надо (!!!) управлять форматом вывода централизовано из какого-нибудь управляющего класса, то почему бы и нет?
ещё раз, это зависит от того какую цель Вы преследовали во время написания такого куска кода :)
этот код, является корректным и при правильном подходе выдаёт правильный результат, но пользоваться им надо осторожно, как в общем и любыми, на первый взгляд безобидными, вещами в сравнительно низкоуровневом языке, которым является С++
Это Вы так пытаетесь оправдать свою безграмотность?
отнюдь, пытаюсь показать Вам почему Ваш пример некорректен с точки зрения того что Вы хотите показать, а Вы отпираетесь как номенклатурщик со стажем :)
Это почему это?
клочок текста один — msgs.get (cat, 1, CODE1, def).
клочок текста два — msgs.get (cat, 1, CODE2, def).
а связи между ними не будет. Такое корректно перевести вообще невозможно.
Это почему это? клочок текста один — msgs.get (cat, 1, CODE1, def). клочок текста два — msgs.get (cat, 1, CODE2, def). а связи между ними не будет. Такое корректно перевести вообще невозможно.
а Вы им будете давать типы аргументов вписывать, да?
или таки локализованная строка таки будет выглядеть «## of ## files loaded» и потом (для printf) по ней пройдёт автопарсер и по заданным правилам приведёт строку к «%d of %d files loaded» и положит её в ресурсы?
Это еще почему? Или мы под ресурсами понимаем разные вещи?
ресурсы должны собираться автоматически, вот как у Qt translator (или как там его) сделано, иначе если у тебя вдруг внутренний формат поменяется (а такое бывает) или ещё что то твои переводчики (или кого ты там посадишь) будут работать ишаками перебивая ручками циферки
> какая разница что там будет потом, переводчик видит и работает со строками целиком, а уж как потом они транслируются и хранится - никого не волнует
Это как это? То есть код генерится по ресурсам, а не наоборот? Тогда веселая жизнь обеспечена программистам.
ну зачем Вы глупости говорите, Вы же умный человек :)
код пишут программисты, но чтобы не учить переводчиков в каком внутреннем формате это всё хранится и не переучивать если он внезапно поменялся делается небольшая тулза для них, которая человечий вид переводит во внутренний формат хранения, а там уже пофиг чем и как выводить
эх, не общались Вы с гейм-дизайнерами по рабочим вопросам :)
Возьмем например qt.
Я делаю так tr(«%1 of %2 files loaded»), потом натравливаю lupdate, который генерит ts файл. ts файл открывается в лингвисте переводчиками, которые увидят там полную фразу «%1 of %2 files loaded». В случае с gettext механизм аналогичен.
А как быть вот с этим cout << msgs.get (cat, 1, CODE1, def) << i << msgs.get (cat, 1, CODE2, def) << n; ? Опишите механизм полностью. Мне не понятно каким образом в ресурсах возникнет полная фраза, а не ёё куски.
Что ты уцепился за этот кусок? Меня попросили «перевести» дословно. В продакшне я бы тоже не стал такое писать.
У меня ваще опыта локализации нет, если честно, я специализируюсь по легаси.
> ресурсы должны собираться автоматически, вот как у Qt translator (или как там его) сделано, иначе если у тебя вдруг внутренний формат поменяется (а такое бывает) или ещё что то твои переводчики (или кого ты там посадишь) будут работать ишаками перебивая ручками циферки
Значит мы все же говорим о разных ресурсах. Какая разница переводчикам, какой там внутренний формат? Они работают со строками. С целыми строками. В моем случае это строки диалогов персонажей, объединенных в группы.
Так что не нужно мне рассказывать про некий геймдейв. Вы ведь преподаватель, а не геймдевелопер.
А как быть вот с этим cout << msgs.get (cat, 1, CODE1, def) << i << msgs.get (cat, 1, CODE2, def) << n; ? Опишите механизм полностью. Мне не понятно каким образом в ресурсах возникнет полная фраза, а не ёё куски.
прости дорогой, но твоя проблема в том что ты не понимаешь концепции потоков, это не плохо, это просто вот так сложилось :)
вот сейчас ты путаешь вывод и хранение, к примеру :)
следует относиться относится к приёмнику потока как к буферу, а не устройству вывода
что мешает сделать вот так?
UnicodeString result;
result = MessageFormat::format(
"At {1,time} on {1,date}, there was {2} on planet{0,number,integer}.",
arguments,
3,
result,
err);
а внутри использовать твою «любимую» ;) фразу:
result << msgs.get (cat, 1, CODE1, def) << i << msgs.get (cat, 1, CODE2, def);
что мешает тебе использовать класс для хранения строки целиком и по запросу извлекать из словаря все составляющие?
тебе лучше и дальше использовать концепцию форматирования строк в стиле printf и не забивать себе голову :)
Значит мы все же говорим о разных ресурсах. Какая разница переводчикам, какой там внутренний формат? Они работают со строками. С целыми строками. В моем случае это строки диалогов персонажей, объединенных в группы.
но таки переводчики не лазают руками в ресурсы, а используют соответствующую тулзу, или нет?
Так что не нужно мне рассказывать про некий геймдейв. Вы ведь преподаватель, а не геймдевелопер.
То есть ты предлагаешь вот это «At {1,time} on {1,date}, there was {2} on planet{0,number,integer}» распарсить, а потом назад «запарсить» с помощью «стрелочек» лишь бы было «на потоках» ?
То есть ты предлагаешь вот это «At {1,time} on {1,date}, there was {2} on planet{0,number,integer}» распарсить, а потом назад «запарсить»
а что не так? в чём проблема? почему в случае с boost::format это Вас не смущает? :)
с помощью «стрелочек» лишь бы было «на потоках» ?
потоки не самоцель - а удобный инструмент
как я уже сказал Вы не понимаете концепции потоков, то что вы используете термины типа «стрелочки» свидетельствует о Вашем пренебрежительном отношении и нежелании разбираться, но в конце концов - это Ваше право так думать :)
и да, я здесь не для того чтобы Вас переубеждать - используйте что нравится :)
Прекрасно понимаю. Чтобы вывести строку текста нужно будет выполнить много дурной работы.
Все, что ты предложил, - это замена ворнингов на неправильные параметры принтфа исключениями или другой аналогичной радостью при неправильном количестве параметров.
Причем ошибки будут вылетать ощутимо ниже по стеку вызовов от места появления.
Это замена одной проблемый другой проблемой, при том, что конечный интерфейс стал более громоздким. По-русски это называется bloatware. ))
> но таки переводчики не лазают руками в ресурсы, а используют соответствующую тулзу, или нет?
Как я и предположил, у нас разные понятия ресурсов. И разные понятия о лазании руками / использовании соответствующих тулз.
Кстати, а текстовый редактор не может являться соответствующей тулзой? Или это обязательно должна быть самописная софтина, ради поддержания хитровыгнутого внутреннего формата?
Прекрасно понимаю. Чтобы вывести строку текста нужно будет выполнить много дурной работы.
локализация в любом разе это предполагает
Все, что ты предложил, - это замена ворнингов на неправильные параметры принтфа исключениями или другой аналогичной радостью при неправильном количестве параметров.
нет, не понимаешь - иди медитируй
Причем ошибки будут вылетать ощутимо ниже по стеку вызовов от места появления.
точно? уверен?
Это замена одной проблемый другой проблемой, при том, что конечный интерфейс стал более громоздким.
это замена неотлавливаемой ошибки на отлавливаемую, если для Вас это так сложно понять то я Вам сочувствую
Причем ошибки будут вылетать ощутимо ниже по стеку вызовов от места появления.
точно? уверен?
Ну, чувак, если ты сумеешь отловить ошибки в описанном тобою интерфейсе _ДО_ или хотя бы во время обращения к MessageFormat::format, я поставлю тебе памятник. Нерукотворный.
это замена неотлавливаемой ошибки на отлавливаемую,
Деточка, arguments в
MessageFormat::format(«At {1,time} on {1,date}, there was {2} on planet {0,number,integer}.»,arguments, 3,result, err);
у тебя что? Он из астрала приходит в наш мир или формируется телепатически?
Выйди к доске и расскажи всему классу, что прозойдет, когда вместо 3 аргументов будет передан один. Или ноль.
Заодно расскажи, какое магическое значение несет в себе цифра 3, и за каким ражном ты её впендюрил в список параметров. )))
> > Кстати, а текстовый редактор не может являться соответствующей тулзой?
только не для копания в ресурсах
Понял, вы просто невменяемый.
> Или это обязательно должна быть самописная софтина, ради поддержания хитровыгнутого внутреннего формата?
смотрите какой пузатый толстячок пришёл к нам на огонёк
При чем тут толстячок? Я следовал вашей логике - формат ресурсов должен быть максимально сложным; так же должна быть утилита, для редактирования ресурсов в этом формате.
Вы часом не приложили руку к разработке формата офисных документов компании MS?
Having programmed for a few years and learnt a second language, the budding genius is firmly convinced that he is the Messiah of the programming world. He reinforces this world view with his conviction that anything he doesn’t understand (i.e. almost everything) is pointless, old-fashioned and a waste of time.
Ну, чувак, если ты сумеешь отловить ошибки в описанном тобою интерфейсе _ДО_ или хотя бы во время обращения к MessageFormat::format, я поставлю тебе памятник. Нерукотворный.
поставь памятник своей глупости :)
Деточка, arguments в
> MessageFormat::format(«At {1,time} on {1,date}, there was {2} on planet {0,number,integer}.»,arguments, 3,result, err);
у тебя что? Он из астрала приходит в наш мир или формируется телепатически?
Выйди к доске и расскажи всему классу, что прозойдет, когда вместо 3 аргументов будет передан один. Или ноль.
а ты открой исходники ICU деточка и посмотри как нормальные квалифицированные люди обрабатывают ошибки :)
>должна быть утилита, для редактирования ресурсов в этом формате.
Ога, попробуй посади гуманитария переводить строковые ресурсы в редакторе Emacs или Vim. Легко угадать, куда ты будешь им послан.
это лёгкий вариант развития событий, потяжелее будет если он таки залезет и исправит так как ему кажется правильно и закоммитит, а потом фриз ресурсов не пройдёт и придётся делать много «monkey business» в сжатые сроки и в последний момент
как я уже сказал Вы не понимаете концепции потоков, то что вы используете термины типа «стрелочки» свидетельствует о Вашем пренебрежительном отношении и нежелании разбираться
jtootf
стрелочки. и почему-то никто не считает, что такое название о чём-то свидетельствует
что ещё тебе объяснить? название абстракции взято из теории категорий, одно из типичных приложений - stream processing, любимые тобою потоки
попробуй почитать хоть что-нибудь, что выходит за рамки твоего уютного мирка, ну
хотя тебе, пожалуй, журнал гламур будет полезней. больше понятных слов
по себе людей не судят, толстячок :)
чмонады свои можешь использовать ректально, я разрешаю, здесь же разговор идёт в контексте (знаешь такое слово? а понятие?) С++ и нет тут никаких стрелочек, а есть потоки и переопределённый оператор сдвига, очень жаль что твой моск не способен этого понять
> Хороший пример, где на все 100% нужно пользоваться printf'ом :)
Есть две уважительный причины для использования printf в коде на С++: legacy и жёсткая оптимизация. А тут нужен boost::format, который удобней и безопасней, чем printf и совместим с потоками C++, что является черезвычайно важным.
Честно говоря, когда-то я читал Страуструпа, думал, может быть, пригодится мне C++. Пока ни с одной ситуацией, где мне бы понадобились преимущества С++ над чистым С не сталкивался. Я не пишу GUI (для моих задач лучше всего подходит веб-интерфейс), мои программки не превышают по объему кода сотни-другой килобайт. В общем, С++ мне абсолютно бесполезен :)
> Пока ни с одной ситуацией, где мне бы понадобились преимущества
С++ над чистым С не сталкивался.
Ну если ты не владеешь C++ практически, то и не столкнёшься :) Я на С++ даже модули для Apache писал, ибо писать на чистом C без веских на то оснований - просто тратить напрасно своё время ;)
Писать на С++ есть смысл лишь в случае, когда в задаче можно выделить классы, определить зависимость между ними, наследование и т.п. А когда у меня несколько железок, которыю надо периодически опрашивать и обрабатывать полученные данные, С++ использовать бесполезно. Ну, а примеры неоправданного применения С++ там, где можно было бы значительно уменьшить количество кода использованием С, здесь уже приводили.
> Писать на С++ есть смысл лишь в случае, когда в задаче можно выделить
классы, определить зависимость между ними, наследование и т.п.
С чего вдруг? STL, например, может быть весьма эффективна даже если не определять своих классов. А boost.asio кажется сейчас лучшее что есть, для работы с асинхронным вводом/выводом. Ну и т.д. У C++ много преимуществ, но что бы понимать их нужно владеть им на достаточно хорошем уровне ;)
примеры неоправданного применения С++ там, где можно было бы
значительно уменьшить количество кода использованием С, здесь уже