Здравствуйте, VoidEx, Вы писали:
Q>>А что, где-то пришито?
VE>object.ToString
Это всего лишь способ вывода по умолчанию, который используется в случае, если в методы форматирования не передаётся своя реализация IFormatProvider/ICustomFormatter. See also: Formatting Types
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, VoidEx, Вы писали:
Q>>>А что, где-то пришито?
VE>>object.ToString
Q>Это всего лишь способ вывода по умолчанию, который используется в случае, если в методы форматирования не передаётся своя реализация IFormatProvider/ICustomFormatter. See also: Formatting Types
BFE>Кто-нибудь может сказать, что valarray следовало бы назвать vector(вектор), поскольку он является традиционным математическим вектором, а vector следовало бы назвать array(массив), однако терминология развивалась иначе. valarray — это вектор, оптимизированный для численных расчётов, а vector — это гибкий контейнер разработанный для хранения объектов различного типа и манипулирования с ними, массив же — это низкоуровневый встроенный тип.
BFE> Бьерн Страуструп
IMHO, это только доказывает, что "терминология развивалась" неудачно...
Ну вообще весь STL делали люди со значительным вывихом мозга. Так что чего там было ждать-то прямых решений?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Qbit86, Вы писали:
Q>Обещанного? Никто не обещал восполнять твои пробелы в образовании.
Ага, как я и думал. В начале много громких слов, а когда переходим к конкретике, то пшик.
Q>Ты не улавливаешь связи в последовательных предложениях. Упоминание класса вектора в одном из .NET API служило примером, а не определением вектора в алгебре (который элемент векторного пространства).
Угу, и в OpenGL тоже есть свои вектора. Только какое это имеет отношение к универсальным контейнерам C++?
_>>И снова .Net и Java. Без них никак не получается говорить про C++? ) Q>Нельзя продуктивно говорить о чём бы то ни было, не пытаясь расширить контекст и проводить сравнения с существующими образцами.
Ооо, ну хорошо. Тогда давайте разберём что же подразумевается под понятием "список" в языках Лисп, Пролог, Хаскель. Ну это для начала. )))
Здравствуйте, alex_public, Вы писали:
_>Ооо, ну хорошо. Тогда давайте разберём что же подразумевается под понятием "список" в языках Лисп, Пролог, Хаскель. Ну это для начала. )))
Для начала лучше вспомнить, что называли списком, например, Дейкстра или Вирт. Неожиданно оказывается, что это 1 или 2-связный интрузивный список, а никак не список покупок.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, SleepyDrago, Вы писали:
SD>добровольно выбираете 2е зная что это нужно каждые 50 строк ? Я чесслово не смог бы лучше за вас описать насколько это эпик. SD>А геометрия она бывает не только из чисел. Вот например 2d грань это 2 точки и направление
Не очень понятно ваше желание выводить точки исключительно в поток. А если вам потребуется их не логгировать, а, скажем, в TextBox записывать?
Безотносительно к наличию в языке потоков достаточно реализовать метод .toString(), который решит все проблемы форматирования точки раз и навсегда.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Erop, Вы писали:
E>IMHO, это только доказывает, что "терминология развивалась" неудачно... :xz: E>Ну вообще весь STL делали люди со значительным вывихом мозга. Так что чего там было ждать-то прямых решений? ;)
Не скажи. Его делали очень умные люди, в первую очередь, Алекс Степанов. В его книжке «Начала программирования» (которая скорее, не про программирование, а про алгебру, кмк) на довольно глубоком уровне расписаны концепции итераторов.
В то время как API коллекций в .NET, кажется, изначально развивалось как бог на душу положит, по-рабоче-крестьянски. Значительно позже появились правильные решения, дженерики, Linq, Rx, выведенные «учОными», а не «инженерАми».
И вот тем не менее, в первом случае появилось малоюзабельное нечто, на что нельзя смотреть без содрогания после работы с более гуманными API.
Здравствуйте, Sinclair, Вы писали:
S>Не очень понятно ваше желание выводить точки исключительно в поток. А если вам потребуется их не логгировать, а, скажем, в TextBox записывать?
Предполагается, что в этом случае ты выведешь в строковый поток, а оттуда получишь строку и запихнёшь в TextBox.
Но я по-прежнему не могу понять, чем вызов MyNamespace::operator <<(cout, point) принципиально лучше упомянутого вызова MyNamespace::print_point(point). Автор что-то недоговаривает.
Здравствуйте, alex_public, Вы писали:
_>Ага, как я и думал. В начале много громких слов, а когда переходим к конкретике, то пшик.
Я дважды озвучил определение вектора, ты этого так и не понял. Вот тебе и «пшик».
_>Угу, и в OpenGL тоже есть свои вектора.
Да-да, я как раз хотел в качестве ещё одного примера упомянуть векторы из OpenGL, ты меня опередил.
_>Только какое это имеет отношение к универсальным контейнерам C++?
Наоборот, какое отношение имеют универсальные контейнеры C++ к тому, что принято называть векторами?
_>Ооо, ну хорошо. Тогда давайте разберём что же подразумевается под понятием "список" в языках Лисп, Пролог, Хаскель. Ну это для начала. )))
В Лиспе и Хаскеле под списком понимается отнюдь не двусвязный список с возможностью быстрой вставки в середину. Так-то.
Здравствуйте, Qbit86, Вы писали: Q>Предполагается, что в этом случае ты выведешь в строковый поток, а оттуда получишь строку и запихнёшь в TextBox.
Ну вот это мне кажется не лучшим способом разделения абстракций. То есть предположение, что "всё можно в поток", при этом "некоторые потоки можно превратить в строку" кажется мне более нелепым, чем предположение, что "всё можно превратить в строку", при этом "строку можно и в поток".
Идеология плюсов явно отстала от времени. Потоки в плюсах в себе скрывают собственно Stream, Writer, и Formatter. То есть с точки зрения теории кристалла, они в лучшем случае могли бы подходить для сериализации, где вопросов форматирования и кодировок просто не встаёт. Но для неё они тоже плохо пригодны, т.к. зачем-то подразумевают текстовость представления.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну вот это мне кажется не лучшим способом разделения абстракций. То есть предположение, что "всё можно в поток", при этом "некоторые потоки можно превратить в строку" кажется мне более нелепым, чем предположение, что "всё можно превратить в строку", при этом "строку можно и в поток". S>Идеология плюсов явно отстала от времени. Потоки в плюсах в себе скрывают собственно Stream, Writer, и Formatter. То есть с точки зрения теории кристалла, они в лучшем случае могли бы подходить для сериализации, где вопросов форматирования и кодировок просто не встаёт. Но для неё они тоже плохо пригодны, т.к. зачем-то подразумевают текстовость представления.
Да вот я как раз примерно то же самое хотел при случае упомянуть. В .NET получение строкового представления объекта рассматривается в рамках более общего понятия «форматирование», куда входит ещё и парсинг, локали/культуры, etc. А «сериализация» — сама по себе, отдельные механизмы и подходы. «Потоки» (стримы) тоже есть, представляют из себя отдельную абстракцию (в том числе декораторы и адаптеры потоков). А в плюсах всё это попытались запихнуть в единое понятие «поток», с его модификаторами (манипуляторами), флагами, специфической обработкой ошибок, изменяемым состоянием, etc.
Здравствуйте, Sinclair, Вы писали:
Q>>Предполагается, что в этом случае ты выведешь в строковый поток, а оттуда получишь строку и запихнёшь в TextBox. S>Ну вот это мне кажется не лучшим способом разделения абстракций. То есть предположение, что "всё можно в поток", при этом "некоторые потоки можно превратить в строку" кажется мне более нелепым, чем предположение, что "всё можно превратить в строку", при этом "строку можно и в поток".
Ничего ни мешает TextBox'у быть потоком.
Например в wxWidgets все контролы (для которых это имеет смысл) поддерживают operator<<.
S>Идеология плюсов явно отстала от времени. Потоки в плюсах в себе скрывают собственно Stream, Writer, и Formatter. То есть с точки зрения теории кристалла, они в лучшем случае могли бы подходить для сериализации, где вопросов форматирования и кодировок просто не встаёт. Но для неё они тоже плохо пригодны, т.к. зачем-то подразумевают текстовость представления.
Фигня, большой разницы между строкой и строковым потоком нет. Для некоторых применений удобно одно, для других другое.
Здравствуйте, Qbit86, Вы писали:
Q>Да вот я как раз примерно то же самое хотел при случае упомянуть. В .NET получение строкового представления объекта рассматривается в рамках более общего понятия «форматирование», куда входит ещё и парсинг, локали/культуры, etc. А «сериализация» — сама по себе, отдельные механизмы и подходы. «Потоки» (стримы) тоже есть, представляют из себя отдельную абстракцию (в том числе декораторы и адаптеры потоков). А в плюсах всё это попытались запихнуть в единое понятие «поток», с его модификаторами (манипуляторами), флагами, специфической обработкой ошибок, изменяемым состоянием, etc.
Согласен с тем что реализация паршивая. Но сама идея вывода в поток ничем ни хуже идеи вывода в строку.
Здравствуйте, FR, Вы писали:
FR>Фигня, большой разницы между строкой и строковым потоком нет. Для некоторых применений удобно одно, для других другое.
Ну, с моей точки зрения, разница — огромна. Одно дело иммутабельная строка, другое дело — строковый поток.
Да, с идеологической точки зрения StringBuilder и TextWriter — примерно одно и то же.
Тем не менее, все остальные аспекты, запиханные в плюсовые потоки, там точно лишние.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Erop, Вы писали:
Q>Не скажи. Его делали очень умные люди, в первую очередь, Алекс Степанов.
Дык у глупых-то отуда вывих мозга возьмётся?..
Q>В его книжке «Начала программирования» (которая скорее, не про программирование, а про алгебру, кмк) на довольно глубоком уровне расписаны концепции итераторов.
Беда тут ровно одна -- для программирования 99% кода это всё вляется переусложнением и вообще не надо
Он, как бы, пытался угадать, какие сложные задачи классно поддержать в языке. От чего-то затеял разделять данные и алгоритмы (этакое ати-ООП), и в основу положил жёстко заданные последовательности.
А на практике оказалось нужным уметь работать с наборами, а не с последовательностями (типа SQL зарулил степановский STL), и отказ от ООП тоже пошёл по другому пути...
А С++ остался со всей этой не особо нужной алгеброй....
Q>И вот тем не менее, в первом случае появилось малоюзабельное нечто, на что нельзя смотреть без содрогания после работы с более гуманными API.
Дык вот о том и речь...
Но у них был систематический просчёт и фейл закономерен. Если хочешь получить что-то юзабельное -- надо идти ОТ ЗАДАЧ, а не от математических красот...
Правда я не думаю, что Степанов хотел юзабельное. IMHO, он хотел не юзабельности, а славы
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, SleepyDrago, Вы писали:
SD>>добровольно выбираете 2е зная что это нужно каждые 50 строк ? Я чесслово не смог бы лучше за вас описать насколько это эпик. SD>>А геометрия она бывает не только из чисел. Вот например 2d грань это 2 точки и направление S>Не очень понятно ваше желание выводить точки исключительно в поток. А если вам потребуется их не логгировать, а, скажем, в TextBox записывать? S>Безотносительно к наличию в языке потоков достаточно реализовать метод .toString(), который решит все проблемы форматирования точки раз и навсегда.
мне тут выше 3 раза напоминали что форматировать надо уметь по разному. Так что метод внутри класса это не удобно.
На практике я не настаиваю на вывод в поток так как у нас строка выглядит и ведет себя как поток так что мне не важно
Здравствуйте, Pzz, Вы писали:
Pzz>Эта интуитивная понятность кончается, когда хочется вписать результат форматирования в поле определенной ширины, или вывести число с определенной точностью — то, что в printf'е как раз делается просто и естественно.
Без них никак не получается говорить про C++? )
