Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, __kot2, Вы писали:
__>>посмотрите на наименование контейнеров, например — сразу видно, что их разрабатывал человек не для, там, алгоритмов каких-то продвинутых, а для тех, кто 2 недельный курс программирования в ПТУ закончил.
Q>Lol'd Хуже, чем в C++, коллекции мало где называются
Q>list'ом называется не абстрактный тип данных cписок, а структура данных односвязный список.
это то же самое, что написать: у моего знакомого руки не из жопы торчат, а из плеч, во прикол-то какой!
а что вы ожидали от понятия "список"?

Q>vector'ом называется не кортеж фиксированного числа элементов с операциями типа евклидова длина или скалярное произведение, а динамически расширяемый массив.
правильно было назвать его dynamic_array, но это слишком длинно для базового типа. точно из тех же соображений int, а не integer и float, а не floating_point

Q>Хэш-таблица в стандарте называется unordered_map.
у хэш-таблицы может быть миллион реализаций и все нужны

Q>Facepalm.
а русские слова кончились?

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

__>вот есть я. я не задумывался никогда почему такого, как я больше нет нигде :)
__>вот есть бомж Вася. он собирает бутылки
__>вот есть баба Валя жена бомжа Васи, она тоже собирает бутылки
__>может и мне стоить бросить это программирование и идти собирать бутылки?

А вот разработчики Boost.Format таки решили уподобиться бомжу Васе, и сделать более или менее безопасную реализацию форматных срок. Взамен слабоюзабельным потокам.

(Интересно, а кто-то всерьёз регулярно проверяет std::cout.bad(), или, по старой традиции забивает на подобные мелочи?).

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

__>а что вы ожидали от понятия "список"?

Близости к бытовому понятию списка. Скажем, список покупок. Вполне может быть нумерованным. Есть абстракция List, есть реализации ArrayList (индексируемый список), есть LinkedList (однонаправленный список), SortedList, etc. С соответствующими асимптотиками поддерживаемых операций, и т.п.

Q>>vector'ом называется не кортеж фиксированного числа элементов с операциями типа евклидова длина или скалярное произведение, а динамически расширяемый массив.
__>правильно было назвать его dynamic_array, но это слишком длинно для базового типа. точно из тех же соображений int, а не integer и float, а не floating_point

Т.е. dynamic_array слишком длинно, поэтому решили сократить до vector? Facepalm.

Q>>Хэш-таблица в стандарте называется unordered_map.
__>у хэш-таблицы может быть миллион реализаций и все нужны

И наоборот, хэш-таблицы — это способ реализации (структуры данных) абстрактного типа ассоциативный массив. Есть абстракция Map, есть реализации HashMap, SortedMap (или даже уточнения типа RBTreeMap), etc.

Q>>Facepalm.
__>а русские слова кончились?

Рукалицо.

> * Сами потоки также представляют собой объекты и отлично вписываются в
> объектно-ориентированную структуру языка

Какого ? С++ ? Он не объектно-ориентированный. Он гибридный.

> * Интуитивно-понятны (не надо вспоминать, что означает тот или иной
> спецификатор в строке форматирования)

Это если тебе надо что-то очень простое вывести, тебе хватит << .
А потом тебе придётся вспоминать такие же форматтеры из потоковой библиотеки.

> * Безопасны (хотя некоторые компиляторы и выдают ошибки / предупреждения на
> попытку некорректного использования функций семейства printf, это лишь
> исключения из правила — стандарт этого, разумеется, не обязывает)


Безопасность -- на самом деле единственный плюс потоковой библиотеки.
Но безопасно можно писать и на stdio.

> А что Вы думаете по этому поводу?

В общем, потоки -- отстой. Красивая игрушка, плохо пригодная для
нормального промышленного применения.

Хорошо подходит для тестовых или учебных целей -- вывел и не надо
думать о типе аргумента. как бы ввод-вывод, встроенный в язык
(как в паскал`е).

> Всё так, только забыли главное упомянуть: неудобство форматирования вывода. Во
> всех языках имеется возможность удобного вывода в том или ином виде, от обычных
> printf-подобных и их расширений (ява, шарп) до here-doc & K°.

Кстати, те же джависты таки добавили в последней версии форматный вывод.
6 кажется версий пыжились и тужились, но таки добавили.

Кстати, на счёт форматного ввода-вывода. В первом языке программирования
(fortran) всегда был очень сильный форматный ввод-вывод. Описание его
занимает порядка трети всего языка. Так что форматный ввод-вывод можно
сказать must в программировании.


> ЗЫ: ещё камень в потоки, хотя это уже не относится к stream vs printf:
> стандартные потоки завязаны исключительно на текстовой вывод, и средствами C++
> вроде бы нельзя работать с бинарными файлами. Или неформатированный ввод/вывод
> может?

Можно.

Здравствуйте, Qbit86, Вы писали:
Q>А вот разработчики Boost.Format таки решили уподобиться бомжу Васе, и сделать более или менее безопасную реализацию форматных срок. Взамен слабоюзабельным потокам.
а разработчики гугла советуют использовать эту безопасную альтернативу или эллипсис проканает?

лично я тоже не фанат потоков. если нужно написать свое логгирование или сериализация меня вполне устраивает просто переопределенные ф-ии типа log(int, float, string) и т.д.
другое дело что я против переменного числа аргументов в printf. это как ездить в машине с неработающими тормозами и тормозить только ручником — так делать можно, но советовать это как стиль вождения??? сейчас не 19ый век, надо избавляться от таких решений.

Q>(Интересно, а кто-то всерьёз регулярно проверяет std::cout.bad(), или, по старой традиции забивает на подобные мелочи?).
проверки зависят от требований к проекту. в таких проектов, где вывод в cout был критически важен, я еще не участвовал

Здравствуйте, Qbit86, Вы писали:
Q>Близости к бытовому понятию списка. Скажем, список покупок. Вполне может быть нумерованным. Есть абстракция List, есть реализации ArrayList (индексируемый список), есть LinkedList (однонаправленный список), SortedList, etc. С соответствующими асимптотиками поддерживаемых операций, и т.п.
да, для определенной аудитории д-но нужно чтобы список был похож на список покупок. те же, кто книжки читал по алгоритмам знают, что за списком закреплена определенная структура с определенными операциями

Q>>>vector'ом называется не кортеж фиксированного числа элементов с операциями типа евклидова длина или скалярное произведение, а динамически расширяемый массив.
__>>правильно было назвать его dynamic_array, но это слишком длинно для базового типа. точно из тех же соображений int, а не integer и float, а не floating_point
Q>Т.е. dynamic_array слишком длинно, поэтому решили сократить до vector? Facepalm.
вектор тоже подходит. есть, например, функан. там вектора вообще почти все бесконечномерны. никто не мешает использовать его как массив фиксированной длинны + они сделали его авторасширяемым

Q>>>Хэш-таблица в стандарте называется unordered_map.
__>>у хэш-таблицы может быть миллион реализаций и все нужны
Q>И наоборот, хэш-таблицы — это способ реализации (структуры данных) абстрактного типа ассоциативный массив. Есть абстракция Map, есть реализации HashMap, SortedMap (или даже уточнения типа RBTreeMap), etc.
откройте книжку по алгоритмам. самое главное чем отличаются хэш-таблицы это можно ли из них удалять элементы, ожидаемое время поиска, вставки и т.д. это главное. и реализации у них принципиально разные.

Q>>>Facepalm.
__>>а русские слова кончились?
Q>Рукалицо.
ну и причем тут рукалицо?

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

__>может и мне стоить бросить это программирование и идти собирать бутылки?
Если судить по этому топику, то очень даже может быть

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

__>да, для определенной аудитории д-но нужно чтобы список был похож на список покупок. те же, кто книжки читал по алгоритмам знают, что за списком закреплена определенная структура с определенными операциями

Ну вот Кормен—Лейзерсон—Ривест — это подходящая книжка по алгоритмам? Там то, что в C++ называется std::list, называется singly linked list.

__>вектор тоже подходит. есть, например, функан. там вектора вообще почти все бесконечномерны. никто не мешает использовать его как массив фиксированной длинны + они сделали его авторасширяемым

Мне интересно, ну хоть где-то в природе используется std::vector как часть какого-нибудь API, работающего с каким-нибудь векторным пространством? Графические библиотеки, библиотеки вычислительной алгебры, цифровой обработки изображений, 3D-моделирования, ну хоть где-нибудь?

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

А>Из минусов могу вспомнить лишь,..

А>А что Вы думаете по этому поводу?

Ну, например, часто не так уж и просто предсказать какой именно ваиант operator << выберется в том или ином месте...

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

Q>Мне интересно, ну хоть где-то в природе используется std::vector как часть какого-нибудь API, работающего с каким-нибудь векторным пространством? Графические библиотеки, библиотеки вычислительной алгебры, цифровой обработки изображений, 3D-моделирования, ну хоть где-нибудь?

Где-то тут же на RSDN с полгода назад видел комментарий, что в STL надо мысленно менять названия vector и array местами, тогда оно будет соответствовать привычному пониманию.

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

__>лично я тоже не фанат потоков. если нужно написать свое логгирование или сериализация меня вполне устраивает просто переопределенные ф-ии типа log(int, float, string) и т.д.
__>другое дело что я против переменного числа аргументов в printf. это как ездить в машине с неработающими тормозами и тормозить только ручником — так делать можно, но советовать это как стиль вождения??? сейчас не 19ый век, надо избавляться от таких решений.

Я-то думал, что Вы против возможного рассогласования формата и типа данных, а Вы, оказывается, против переменного числа аргументов.

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

N>>А Вы никогда не задумывались, почему потокового интерфейса в таком стиле, как в C++, больше нигде нет?
__>а как их реализовать средствами языка в C# и в Python? уже как сделали, так сделали

1) при чём тут язык? эта реализация в библиотеке.
2) да точно так же как в C++. если бы было нужно и полезно, давно бы сделали. у питона средства для этого не хуже чем C++, и даже гибче. но раз нет — значит, не настолько нужно

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

Q>>list'ом называется не абстрактный тип данных cписок, а структура данных односвязный список.
__>это то же самое, что написать: у моего знакомого руки не из жопы торчат, а из плеч, во прикол-то какой!
__>а что вы ожидали от понятия "список"?

список, к сведению, может быть, например, двусвязным. это значительно полезнее, когда хотя бы иногда возникают ситуации типа "надо посмотреть на предыдущий элемент" или "надо выкинуть элемент из списка, имея только указатель на этот элемент и на какую-то условную голову списка".

а в случае STL это ситуация, когда одна рука из плеча растёт, а вторая таки из зада, и то может отсутствовать.

Q>>vector'ом называется не кортеж фиксированного числа элементов с операциями типа евклидова длина или скалярное произведение, а динамически расширяемый массив.
__>правильно было назвать его dynamic_array, но это слишком длинно для базового типа. точно из тех же соображений int, а не integer и float, а не floating_point

правильно было его назвать просто array.

Q>>Хэш-таблица в стандарте называется unordered_map.
__>у хэш-таблицы может быть миллион реализаций и все нужны

и какая из этого миллиона реализаций может быть названа, к примеру, ordered map?

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

__>а разработчики гугла советуют использовать эту безопасную альтернативу или эллипсис проканает?

Я не знаю. Этот стайл гайд я читал очень давно. Они там, вроде, даже исключения не используют, так что мне с ними не по пути.

__>лично я тоже не фанат потоков.

То-то и оно. (С C# на C++ очень тяжело возвращаться.) Printf не использую из-за небезопасности, Boost.Format — из-за нежелания собирать его под целевую платформу. Так что продолжаю грызть кактус и использую потоки.

__>если нужно написать свое логгирование или сериализация меня вполне устраивает просто переопределенные ф-ии типа log(int, float, string) и т.д.

Хм... Log всегда выводит строку. Другое дело, как её форматировать. Обычно это не просто число, а более сложный комментарий, описывающий контекст возникновения ошибки.

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

__>>другое дело что я против переменного числа аргументов в printf. это как ездить в машине с неработающими тормозами и тормозить только ручником — так делать можно, но советовать это как стиль вождения??? сейчас не 19ый век, надо избавляться от таких решений.

N>Я-то думал, что Вы против возможного рассогласования формата и типа данных, а Вы, оказывается, против переменного числа аргументов.

Вот, например, переменное число аргументов в C# — это по сути синтаксический сахар для одного аргумента, коллекции с переменным количеством элементов. Т.е. быть против переменного числа параметров — примерно как быть против многоэлементных коллекций. (В C#, конечно, форматирование строк безопаснее, чем в Си.)

Использование такой функциональности вполне имеет смысл. Скажем, мы делаем

var messageFormat = Resources.GetUserFormat();
var message = String.Format(messageFormat, userName, userId, date, time);

А конкретная форматная строка может выбираться в зависимости от каких-то настроек, и содержать все, не все, переупорядоченные или даже продублированные параметры (скажем, "{1} (0x{1:X})" для вывода идентификатора и его 16-ричного представления).

Здравствуйте, netch80, Вы писали:
N>>>А Вы никогда не задумывались, почему потокового интерфейса в таком стиле, как в C++, больше нигде нет?
__>>а как их реализовать средствами языка в C# и в Python? уже как сделали, так сделали
N>1) при чём тут язык? эта реализация в библиотеке.
ниче не понял. вот вездеход. он ездит везде. вот Лада Калина. она нигде не ездит. я говорю — раздатка нужна для того, чтобы везде проехать. без раздатки вы не уедете. на Калину не устанавливается раздатка вообще ни в каком варианте. у C# или в Python нельзя реализовать вывод текста в стиле cout << "A" << 10 << endl, так же, как раздатку не вкорячишь в Калину, хоть ты что делай. ограничения конструкции.

Здравствуйте, netch80, Вы писали:
N>список, к сведению, может быть, например, двусвязным. это значительно полезнее, когда хотя бы иногда возникают ситуации типа "надо посмотреть на предыдущий элемент" или "надо выкинуть элемент из списка, имея только указатель на этот элемент и на какую-то условную голову списка".
по дефолту список односвязный так как это минимальная структура такого рода. и алгоритмы для списков в основном ориентируются на односвязность. двусвязность это уже фича списка — оптимизация за счет увеличения использования памяти. поэтому списком называют именно односвязный список, а двусвязный список обычно называют полностью.

Здравствуйте, netch80, Вы писали:
N>правильно было его назвать просто array.
нет. array обычно размещается на стеке и размер его фиксирован

Q>>>Хэш-таблица в стандарте называется unordered_map.
N>и какая из этого миллиона реализаций может быть названа, к примеру, ordered map?
обычно реализуется через дерево. коих тоже множество разных реализаций в зависимости от того, что нужно. какая из них в stl — не знаю, не интересовался. может быть и нету.

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

__>ниче не понял. вот вездеход. он ездит везде. вот Лада Калина. она нигде не ездит. я говорю — раздатка нужна для того, чтобы везде проехать. без раздатки вы не уедете. на Калину не устанавливается раздатка вообще ни в каком варианте. у C# или в Python нельзя реализовать вывод текста в стиле cout << "A" << 10 << endl, так же, как раздатку не вкорячишь в Калину, хоть ты что делай. ограничения конструкции.

Можешь сформулировать, в чём именно заключаются «ограничения конструкции» этих языков, что не позволяют реализовать? Отсутствие вывода в стиле C++ в других языках и библиотеках имеет место из-за того, что вывод в стиле потоков C++ — он как Неуловимый Джо.

N>>правильно было его назвать просто array.
__>нет. array обычно размещается на стеке и размер его фиксирован

«array обычно размещается на стеке» — это «обычно» только для C++. Структуры данных в упомянутых тобой книжках по алгоритмам никогда не привязаны к особенностям конкретных языков.

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

Q>>>list'ом называется не абстрактный тип данных cписок, а структура данных односвязный список.
__>>это то же самое, что написать: у моего знакомого руки не из жопы торчат, а из плеч, во прикол-то какой!
__>>а что вы ожидали от понятия "список"?

N>список, к сведению, может быть, например, двусвязным. это значительно полезнее, когда хотя бы иногда возникают ситуации типа "надо посмотреть на предыдущий элемент" или "надо выкинуть элемент из списка, имея только указатель на этот элемент и на какую-то условную голову списка".

ну, как-бы, список из стандартной библиотеки, двусвязный и есть.
так что суть претензий не совсем понятна.

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

N>>список, к сведению, может быть, например, двусвязным. это значительно полезнее, когда хотя бы иногда возникают ситуации типа "надо посмотреть на предыдущий элемент" или "надо выкинуть элемент из списка, имея только указатель на этот элемент и на какую-то условную голову списка".

NB>ну, как-бы, список из стандартной библиотеки, двусвязный и есть.
NB>так что суть претензий не совсем понятна.

А коллега из одного из предыдущих постингов сказал, что односвязный. Кому верить?
Я сам с STL слишком давно возился и уже забыл.