Здравствуйте, Qbit86, Вы писали:
Q>Толсто же. Про университетские курсы мне говорит махровый гуманитарий, который слабо представляет себе, что за сущность такая — вектор.
И что это за сущность? )))
Q>В смысле быстродействия, но абсолютно несущественный в контексте первого упоминания. Твои наивные попытки самоутвердиться, пытаясь обличить в неведении незнакомых тебе людей, выглядят глупо и смешно. Поцепляйся ещё к пунктуации, я иногда вводные слова не обосабливаю.
Не, тут дело не в самоутверждение. Просто раздражает когда люди:
— пишут вообще не по теме, отвлекаясь на всякие сомнительные языки
— пишут не зная предмет.
Ладно хотя бы одно ещё... Но обе вещи сразу — это перебор уже. )))
Q>Я вообще про метапрограммирование на шаблонах не говорил, речь шла об убогости итераторов и потенциальные варианты другого подхода к работе с коллекциями, которые Александреску как раз и пытается в рамках библиотеки для D прорабатывать.
О, вот это уже интересно. Так вы считаете STL убогой? ) Какой бы другой библиотекой вы предпочли заменить её?
Q>Не уверен, что тебе удастся убедить бустовский сборщик с полпинка, что в качестве компилятора надо использовать LLVM, а не GCC, а таргетом будет iOS, а не MacOS.
Ммм, сам не пробовал, поэтому не знаю. Но глянув в гугле первую же ссылку: http://www.danielsefton.com/2012/03/building-boost-1-49-with-clang-ios-5-1-and-xcode-4-3/ — вроде всё автоматом собирается.
Здравствуйте, Аноним, Вы писали:
А>Прочитал тут Google Code Style.
... А>А что Вы думаете по этому поводу?
почитал Google Code Style про питона. даже воспользовался гугловским чекером. чекер обругал матом стандартные питоновские библиотеки и до моего кода даже не добрался как выдохся и упал замертно. не, ну все правильно. у ms vc на /W4 тоже ругается на свои же библиотеки. бывает...
читаю дальше. генераторы. достоинства -- до фига. недостатки -- за отсутствием таковых. слегка офигеваю и решаю, что этот студенческий реферат дальше можно не читать, т.к. на генераторах я уже обжегся. их не все трансляторы питона поддерживают, а трансляторов у питона много. и в жабий байт-код и в jit... из чего я заключил, что без особой нужды генераторы лучше не юзать.
вот на кой ляд мне гайдлайн, который я и сам могу написать? мне бы такой гайдлайн, чтобы соломку за меня подстелил и мне было совсем не больно падать.
ладно, читаю эту лабуду дальше. "Exceptions are allowed but must be used carefully". блин, какой капиан это писал? это вообще о чем? это вообще к психологу. какое слово тут лишнее. правильно. исключения. потому что этот совет справедлив практически для всех языковых возможностей. сильно поменяется смысл если исключения заменить на комментарии, например?
Avoid global variables -- пацаны жгут напалпом. пион уже постарался и в _каждой_ функции, изменяющей значение глобальной переменной, ее необходимо явно описывать как global, в противном случае сработает copy-on-write и все изменения окажутся сугубо локальными. именно благодаря этой фиче глобальных переменных на питоне можно не бояться. это вам не си. кстати, наличие 'global' в пионе создает конфликтную ситуацию. чего рекомендуется избегать -- объектов с глобальной видимостью или объектов, которые можно глобально модифицировать? каковы границы этой глобальности? если в пределах модуля, то всякая функция с точки зрения питона это переменная. у него же динамическая типизация.
Nested/local/inner classes and functions are fine. -- это уже не напалп, а горилка настоенная на ацетоне. вот, цитирую:
Pros: Allows definition of utility classes and functions that are only used inside of a very limited scope. Very ADT-y.
Cons: Instances of nested or local classes cannot be pickled.
Decision: They are fine.
упомянить closures стоило хотя бы для приличия. scope это не повод вилами махать. или тогда вообще ничего не объяснять, а просто сказать They are fine, потому как если мне позарез нужно их замариновать, то это совсем не айс.
вообще, гайдлайны главным образом пишут для унификации и единообразия. плюс еще немного полезных советов в стиле "если вы не можете писать код не более чем с тремя вложениями -- вам вообще лучше не писать". гайдлайны для ядра линуха очень хороший пример правильных гайдлайнов. да, местами они _очень_ спорны, но по крайней мере они направлены против бардака. а у гугла что? "исключения использовать допустимо, но только с головой. вложенные функции это тоже нормально". а если у меня будет 200 уровней вложенности это как? нормально? нет, увы. отступы мы делаем 4 пробелами. макс. длина строки 80 символов (по гайдлайном). определение функции def_имя(): т.е. минимум 8 символов. плюс 4 на отступ. осталось решить задачку -- какой уровень вложенности считается допустимым. я фигею дорогая редакция.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, alex_public, Вы писали:
Q>>Толсто же. Про университетские курсы мне говорит махровый гуманитарий, который слабо представляет себе, что за сущность такая — вектор. _>И что это за сущность? )))
Не, точно гуманитарий. (А судя по смайликам, ещё и малолетний.) Мой комментарий выше про векторное пространство так и не понял. Вот, например, в WPF есть класс Vector, его экземпляры, по сути, элементы пространства, присоединённого к аффинному пространству Point'ов.
В твоих, э... «университетских курсах» про подобное не рассказывали?
_>Не, тут дело не в самоутверждение.
И кого ты хочешь обмануть?
_>Просто раздражает когда люди: _>- ...пишут не зная предмет.
Вот, например, ты. Не знаешь, что двусвязный список в неплюсовых API (например, в Jave и .NET) называются LinkedList (а List'ом называются вполне индексируемые коллекции), и продолжаешь нести чушь про самоучек и «университетские курсы».
_>- пишут вообще не по теме, отвлекаясь на всякие сомнительные языки
Здравствуйте, B0FEE664, Вы писали:
BFE>Кто-нибудь может сказать, что valarray следовало бы назвать vector(вектор), поскольку он является традиционным математическим вектором, а vector следовало бы назвать array(массив), однако терминология развивалась иначе. valarray — это вектор, оптимизированный для численных расчётов, а vector — это гибкий контейнер разработанный для хранения объектов различного типа и манипулирования с ними, массив же — это низкоуровневый встроенный тип.
Красиво сказано, как будто слушаешь наших политиков и их объяснения, что же на самом деле улучшилось
BFE> Бьерн Страуструп BFE>"Язык программирования С++"
Здравствуйте, SleepyDrago, Вы писали:
N>>Вы не объяснили сколь-нибудь внятно, чего именно хотите, а теперь рассказываете про эпик на основании своих домыслов о том, как бы я решал эту задачу. Вам действительно интересны такие игры? Или проще было бы просто ответить на вопросы, а затем уже слушать ответы собеседника? SD>>>А геометрия она бывает не только из чисел. Вот например 2d грань это 2 точки и направление N>>Охотно верю. То есть, если я правильно Вас понял, вся суть ситуации в том, что объект знает, как именно его выводить в конкретном случае, и Вы не хотите расшифровывать внутреннее содержимое потому что 1) это куча громоздкой писанины, 2) это нарушение инкапсуляции. Я правильно понял? SD>да на 1). Самая популярная описка это спутать ось координат точки в выражении .
OK, понятно. Отвечаю на такое: я категорически не против использования потоков для такого применения, более того, даже "за". Впрочем, тут есть пара подводных камней. Например, надо решить, как именно выбирать метод представления в конкретном потоке — где-то двоичная сериализация, где-то легкоразбираемая текстовая (типа JSON), где-то печать для лога... конкретный метод решения сильно разнится по обстоятельствам.
SD>про 2 я вас не понял. Для простоты не нужна там инкапсуляция.
Не знаю, что называется простотой в данном случае, но она тут получается совершенно естественна.
SD>На счет локализации да там будет идеален вариант "текст {идентификатор1} текст {идентификатор2} текст". Но такие программы редко нуждаются в локализации. Так что локализация не нужна.
Для отладочной печати — да, согласен (хотя и тут бывают исключения)
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, netch80, Вы писали: N>>Завидую Вам — потому, что не знаете, что эта "очень узкая область применения" сейчас преобладает во всей области так называемого "внутреннего ПО" (по Спольски), которая в свою очередь занимает, по разным оценкам, от 70 до 90 процентов всех усилий программистов. Как в анекдоте — "бросить всё и уехать в этот Урюпинск". __>автоматизация работы предприятия? скучно. я не для этого программистом хотел в детстве стать
Я думаю, все, кто хотели стать программистами *в детстве*, хотели не для учёта старых простыней
но даже в таких областях можно придумать много нового.
Здравствуйте, Qbit86, Вы писали:
NB>>коллега с шарпа переходит, у него ломка
Q>Да я с шарпа возвращаюсь, редкоиспользуемые части STL забыл. (Но сам STL по сравнению с Linq, конечно, ад. То, что придумывает Александреску по части ranges vs. iterators конечно, чуть лучше, но, увы, на данный момент в природе не встречается.)
Здравствуйте, Qbit86, Вы писали:
SD>>шаблон был изначально под именем slist как расширение, так что кому надо могли пользоваться.
Q>Вопрос не про list, slist, forward_list, а про смешное утверждение, что де в других языках контейнеры названы для ПТУ-шников, а в C++ всё «чотко и ровно».
Здравствуйте, alex_public, Вы писали:
_>По теме. В C++ есть:
_>- удобное, небезопасное — printf _>- неудобное, безопасное — cout<< _>- удобное, безопасное — boost::format
Помимо осей «удобное—неудобное» и «безопасное—небезопасное» есть ещё оси «быстрое—тормозное» и «доступное—геморное».
А вообще, я давно говорил, что в операции вывода кроме Значения и Потока участвует ещё третья сущность — Форматер. printf и boost::format упрощают/усложняют Форматер до Форматной строки (неполный embedded DSL), iostreams прячут его в состояние Потока и воздействуют на него Манипуляторами. А надо бы его на поверхность вынести и вкусный синтаксис придумать.
#include <iostream>
int main()
{
int flags = 0x16;
std::cout << std::setw(15) << std::hex << flags << "\n";
...
int money = 100;
std::cout << money << "\n";
}
Вопрос:
Что выведет последняя строка? Правильный ответ: не известно.
Всё зависит от .... Если там ничего нет, то выведется 64.
Причем отнюдь не шириной в 15 символов. Ну и с чего это hex более значим чем setw? IMNSHO ввод-вывод не должен иметь такой невнятный state где половина модификаторов сохраняются, а половина нет.
С++ потоки имеют все минусы глобальных переменных без глобальных переменных.
И про костыли вида `std::cout << (std::stringstream() << "foo" << std::setw(8) << "bar").rdbuf() << std::endl;` не надо говорить. И про copyfmt тоже не надо. И про flags. И про Boost.IO_State_Savers. В нормальном I/O такие костыли нафиг не нужны.
И то, что надо тренировать память запоминая что hex это дескать флаг, а width это дескать манипулятор и поэтому первый сохраняется, а второй нет, тоже не надо говорить.
Здравствуйте, Qbit86, Вы писали:
Q>Не, точно гуманитарий. (А судя по смайликам, ещё и малолетний.) Мой комментарий выше про векторное пространство так и не понял. Вот, например, в WPF есть класс Vector, его экземпляры, по сути, элементы пространства, присоединённого к аффинному пространству Point'ов.
Так я так и не увидел обещанного негуманитарного определения вектора. )))
Хыхы, снова .Net выполз. Без него не получается математическое определение? )))
Q>Вот, например, ты. Не знаешь, что двусвязный список в неплюсовых API (например, в Jave и .NET) называются LinkedList (а List'ом называются вполне индексируемые коллекции), и продолжаешь нести чушь про самоучек и «университетские курсы».
И снова .Net и Java. Без них никак не получается говорить про C++? )
Кстати, hint: посмотреть даты создания STL, Java, .Net.
Q>Это раздел КСВ.
О, уже... А изначально C++ был. Вот к чему приводят все эти уходы от темы, как я и говорил.
Здравствуйте, мыщъх, Вы писали:
М>вообще, гайдлайны главным образом пишут для унификации и единообразия. плюс еще немного полезных советов в стиле "если вы не можете писать код не более чем с тремя вложениями -- вам вообще лучше не писать".
С питоновскими гайдлайнами Гугла понятно. А у C++ варианта как дела? )
Здравствуйте, alex_public, Вы писали:
_>Так я так и не увидел обещанного негуманитарного определения вектора. )))
Обещанного? Никто не обещал восполнять твои пробелы в образовании.
_>Хыхы, снова .Net выполз. Без него не получается математическое определение? )))
Ты не улавливаешь связи в последовательных предложениях. Упоминание класса вектора в одном из .NET API служило примером, а не определением вектора в алгебре (который элемент векторного пространства).
В качестве твоей первой книги по линейной алгебре советую Кострикина.
_>И снова .Net и Java. :))) Без них никак не получается говорить про C++? )
Нельзя продуктивно говорить о чём бы то ни было, не пытаясь расширить контекст и проводить сравнения с существующими образцами.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, мыщъх, Вы писали:
М>>вообще, гайдлайны главным образом пишут для унификации и единообразия. плюс еще немного полезных советов в стиле "если вы не можете писать код не более чем с тремя вложениями -- вам вообще лучше не писать".
_>С питоновскими гайдлайнами Гугла понятно. А у C++ варианта как дела? )
А C++ там практически урезан до C с классами (а новый стандарт вообще явно запрещен, разве что смарт-поинтеры можно), зато чОтко регламентировано, где сколько пробелов ставить и дофига КЭПитанства.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Аноним, Вы писали:
А>Прочитал тут Google Code Style. Обратил внимание на пункт Streams, где говорится "Use streams only for logging" и "Do not use streams, except where required by a logging interface. Use printf-like routines instead".
А>Я, конечно, понимаю, что многие вещи в C++ — дело вкуса, но, на мой взгляд, не в данном случае. Почему? Ну, например, хотя бы поэтому:
А>
А>Потоки C++ можно удобно использовать с классами путём перегрузки операторов А>Сами потоки также представляют собой объекты и отлично вписываются в объектно-ориентированную структуру языка А>Интуитивно-понятны (не надо вспоминать, что означает тот или иной спецификатор в строке форматирования) А>Безопасны (хотя некоторые компиляторы и выдают ошибки / предупреждения на попытку некорректного использования функций семейства printf, это лишь исключения из правила — стандарт этого, разумеется, не обязывает) А>
А>Из минусов могу вспомнить лишь, как правило, более медленную работу по сравнению с теми же printf-like функциями (да и тут ещё посмотреть надо, как оно реализовано в той или иной библиотеке, поставляемой производителем компилятора, и задуматься об использовании, возможно, ещё более быстрых API-функций в случае написания платформо-зависимого кода), а также более короткие записи в случае использования многочисленных спецификаторов.
А>А что Вы думаете по этому поводу?
C++ streams are much slower than C-style printf-like functions. My guess is more than 10 times slower.
Здравствуйте, netch80, Вы писали:
N>... Впрочем, тут есть пара подводных камней. Например, надо решить, как именно выбирать метод представления в конкретном потоке — где-то двоичная сериализация, где-то легкоразбираемая текстовая (типа JSON), где-то печать для лога... конкретный метод решения сильно разнится по обстоятельствам.
как я уже писал операция вывода имеет 2 аргумента и тип потока не прибит гвоздями к std. Хотя я не видел особого профита от потоков в бинарном/json виде так как там нет свободной структуры куда можно добавить еще что-то по настроению.
N>>>>Ну признайтесь, что Вы его просто не знаете, и зачем писали чушь — неизвестно. __>>>я у питона только описание читал. как дочитал до места, что там автоматическое управление памятью, закрыл и забыл про него. это очередное баловство, а не язык. N>>Вау. И C# баловство, и Java баловство? Да Вы, батенька, эстет. __>точно с той точки зрения что и iPad — баловство. очень узкая область применения. хотя иногда очень современно и быстро что-то можно сделать.
. 
Для простоты не нужна там инкапсуляция.
