Просто С++ приманивает некий определённый тип программистов, которых я называю метапрограммистами (и к которым сам отношусь, и от этого отношения пытаюсь избавиться). Это люди, которые не хотят решать задачу заказчика, они хотят писать код, который будет писать код', причём этот процесс должен им доставлять максимальное интеллектуальное удовольствие. Причём что должен делать этот код', написанный кодом, не так важно. Теоретически он должен делать то, что хочет заказчик, практически он может это делать, он может делать гораздо больше или он может делать гораздо меньше.
Для них С++ это не инструмент, это религия с библией, заповедями, неверными.
Есть люди, которые воспринимают C++ как инструмент. Не очень удобный инструмент, но в целом жить можно. Они вряд ли будут использовать boost, разве что от большой нужды, они точно не будут ничего городить на шаблонах. Если им надо написать код на C, они просто его напишут, не страдая экзистенциальным кризисом.
В общем первые люди обречены страдать. Они же не дураки, могут в саморефлексию и понимают, что с их подходом что-то ущербно, раз на практике простые вещи выходят сложно. Но переступить через свой идеализм и свою веру не могут. Подозреваю, что они могут уйти в хаскель, т.к. там, имхо, второму типу людей делать нечего. Статья по ссылке это немного подтверждает, кстати.
Здравствуйте, Shmj, Вы писали:
S>попросили написать аналог tar'a. С лимитом по времени 4 часа. И без Qt, пожалуйста. S>1 час я потратил на установку boost'a
Зачем?
S>Еще час я потратил, чтобы узнать, как кроссплатформенно открыть файл и узнать его размер.
Зачем кроссплатформенно?
И да, fopen fseek ftell fstat не?
Или если не трёхэтажный темплейт то пользоваться низзя?
S>Последний час я из спичек и желудей лепил хоть что-нибудь.
Пилять, криворучка!
S>И вот потом я сидел и думал, что же с нами стало.
А ничего не стало. Просто он не умеет в разработку.
S>Вообще, С++ это словно какая-то игра, специально разработанная, чтобы вызывать зависимость. Только не специально!
На помоечку! (тм)
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
L>>Ну что поделать. Не у всех разработка заключается в написании аналогов таров за четыре часа, кому-то и голову включать приходится. CC>Чувак, если у "разраба с опытом" такие простые вещи вызывают подобные сложности — о каких сложных вещах можно вообще говорить?
Мне нравится категоричность. Выдает опыт. И житейскую мудрость. Особенно использование междометия "чувак".
Родной, у нормального инженера просьба переизобрести колесо вызывает лишь один вопрос — "зачем"? Подобные тесты как раз отсеивают опытных инженеров.
Студент-то сходу напишет. Что скажут, то и напишет. Скажут написать tar, напишет tar. Вон, недавно одних таких попросили написать MCAS. Написали MCAS и лишних вопросов не задали. Инженер, которых задавал кучу лишних вопросов, уволен, проект сдан вовремя, заказчик щаслив, акционеры рукоплескают. Oh wait...
Тест на позицию по embedded? Какой в пень tar, там либо биты памяти нужно уметь экономить с антикварным-С-компилятором, либо модули ядра линукса писать.
Если позиция плюсовая, то как в такой задаче показать знание собственно плюсов, не выеживаясь на ровном месте? Вот я бы на этом месте, скорее всего и погорел, кстати.
Еще крайне вероятен такой момент — опытный сеньер уже не раз погорел на "нам нужно быстренько прототип, чисто для тестов" или "самая простейшая реализация, код все равно на выброс", поэтому ищет подвоха во всем. Типа сегодня утром был tar, а завтра оказывается, что он должен быть клиент-серверным с репликацией и availability 99.9999%, масштабированием и произвольным доступом.
Короче, проще надо быть.
Требуется писатель таров — так и пишите в вакансии. Получите кого хотите. А то ведь знаешь ли, идти к архитектору Синей Долины с просьбой разработать проект небольшого загородного домика для 10 соток — идея так себе.
Если требуется опытный разработчик — ищите опытного разработчика.
R>Сто мильёнов раз уже обсуждали тему, почему C++ сложный и становится еще сложнее (потому что предназначен для решения широкого круга задач, и, поэтому, в нем должны быть инструменты для разных задач, да еще и кроссплатформенные и без накладных расходов).
Нет там кроссплатформенного ничего. Вернее, что-то есть, но всюду с нюансами, которых почему-то нет в других ЯП-ах, заявленных как кроссплатформенные: java, python, golang. Ибо C++ застрял между верхом, там где java, python etc, где возможен полный кроссплатформ, и низом, миром Си. В результате ни того, ни другого, только кучи понтов и гемора на ровном месте.
И не является C++ ЯП-ом для широокого круга задач (его как таковой нигде и не используют). Он заявлен как таковой, но опять сплошные нюансы, которых нет в других ЯП, а вместо возможностей применять C++ для решения широкого круга задач, в С++ имеются только понты и гемор на ровном месте.
То есть мне ты два дня назад сказал, что на основании моего частного случая нельзя никаких выводов делать (потому что я не вписывался в твою теорию), а тут на освпнии частного случая ты у себя в голове очередные вавилонские башни строишь. Нормально. Ничего нового.
Если что я уже больше 20 лет на С++ пишу, и не маленькие тулзовины, и нет никаких никаких вавилонских башень. Но мой случай, конечно частный, да-да.
Почитал статью. Ничё не понял. Это точно про плюсы? Почему у меня (к счастью) не так?
Всегда считал плюсы(яву/agile/отвёртку/парацетамол/шаблоны/...) — инструментом, под определённые задачи.
Вот, кстати, знаете, есть такой жизненный принцип, который всегда надо проверять: универсальность + простота = 1. Слишком просто в оборащении — теряет в универсальности. Очень универсальное (например язык ассемблера) всегда довольно сложное. Вот плюсы, как мне кажется, можно разместить по всей планке, в завсимости от хотелок. Их, по желанию, можно использовать и просто и универсально (но не сразу, так не бывает, хотя не уверен).
Мне так (не) повезло, что я на плюсах пишу 99% кода. И я время от времени пытаюсь пойти посмотреть, что там новенького, и сползти на другой язык, но не получается, ровно по тому же принципу: универсальность + простота = 1. Новые языки делают слишком удобными-узкопрофильными. Это не плохо и не хорошо — это просто удобно для конкретных задач.
Я радуюсь новым стандартам плюсов, они мне существенно добавили удобств. Почему у людей не так — я не понимаю.
Я особо не вижу что-то сложное в плюсах(при этом я довольно тупой по природе), если людям кажется, что с++ — слишком сложный, я аппелирую всегда к универсальности. Но это не значит, что вам надо делать, как тимлид/стандарт/босс требует (как послать тимлида или босса — отдельная песня), вполне достаточно делать так, как вам удобно, главное соблюдайте порядок в коде, проекте и голове — это к любому языку относится — и вам будет счастье!
В любом языке программирования самое главное — это ум программиста. Если его нет, то это не в языке проблема, а в программисте. (Йопрст, зачем я это написал, теперь мне же будут этим тыкать в мой код... )
$>Либо ты так троллишь, либо один тех павлинов, которые приходят с важным видом и космическим резюме на интервью, и не могут на доске написать разворот строки за O(n).
Строка UTF-8 надеюсь, а то как-то скучно совсем?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, T4r4sB, Вы писали:
TB>>Строка UTF-8 надеюсь, а то как-то скучно совсем?
IID>Утф не особо сложнее. Ну перевернуть ещё каждый символ потом, определяя границы по старшим битам.
Нужно ли реверсировать композитные символы, например, гетеросексуальную семью с разнополыми детьми? Семья из отца, матери, дочери и сына (👨👩👧👦) станет ли при реверсе семьей из матери, отца, сына и дочери? Или Как отреверсить такое: 👫🏿 (мужчина и женщина, держащиеся за руки, Unicode: U+1F46B U+1F3FF, UTF-8: F0 9F 91 AB F0 9F 8F B)
Здравствуйте, Тёмчик, Вы писали:
Тё>Главное, что они не могут- не прошли сертификацию ФСБ. Фактически, ваши дроны существуют в экосистеме импортозамещения. И не надо говорить, что они лучше чем DJI- когда ваши дроны будут покупать не из-за прямого требования министерств покупать именно у вас, а не у DJI, тогда и можно будет рассуждать, что ваши дроны могут такого, что не могут DJI.
Ладно, ты меня раскусил. Я работаю в госконторе, где мы из говна, палок и С++ лепим макеты, которые даже и не летают. И не хватает мозгов выучить ПХП.
Был я относительно недавно на собеседовании (на позицию embedded-программиста), где меня попросили написать аналог tar'a. С лимитом по времени 4 часа. И без Qt, пожалуйста.
Штош, подумал я, где наша не пропадала?
1 час я потратил на установку boost'a (не встал, какие-то жэсточайшие ошибки, не было времени дальше копать).
Еще час я потратил, чтобы узнать, как кроссплатформенно открыть файл и узнать его размер. Кажется, никак, если нет С++17 c std::filesystem.
Последний час я из спичек и желудей лепил хоть что-нибудь.
И вот потом я сидел и думал, что же с нами стало.
Вообще, С++ это словно какая-то игра, специально разработанная, чтобы вызывать зависимость. Только не специально!
Что происходит? Можно назвать одним словом — Вавилон. Когда люди делают какой-то грандиозный проект (таким проектом была Вавилонская башня, к примеру) — появляется уйма стандартов (диалектов и т.д.) и приводит к тому, что уже никто не может во всем этом зоопарке разобрваться. Эта программа заложена где-то в нашем разуме — в самой основе.
Карантин-с. У народа на почве отсутствия возможности потрепать языком в офисе совсем крышку сорвало. Вот и появляются на RSDN, хабре и других местах темы-тупняки чисто "на поболтать".
Пустой треп от разговора по делу отличить элементарно. Разговор по делу — это обмен информацией (полезной) и после него сразу ответишь на вопрос: "А чего полезного я узнал (или какую задачу решил)?" Пустой треп — это обмен эмоциями (по форме похож на разговор по делу, но только по форме), и после него, возможно, возникнет чисто эмоциональное ощущение, как клево потрепались (и то не факт), но ничего полезного на практике не узнаешь (вопрос "а чего полезного ты узнал" поставит в ступор).
Сто мильёнов раз уже обсуждали тему, почему C++ сложный и становится еще сложнее (потому что предназначен для решения широкого круга задач, и, поэтому, в нем должны быть инструменты для разных задач, да еще и кроссплатформенные и без накладных расходов). Тут очередной "прозревший" выдает стереотипную тягомотину "C++ сложный — я устал". Блин, бери другой инструмент и действуй! Чё очередную статью-нудятину писать? Думаю, оттого, что по делу сказать нечего, а высказаться очень хочется — вот и рождается очередной стереотипный тупняк.
> Еще час я потратил, чтобы узнать, как кроссплатформенно открыть файл и узнать его размер. Кажется, никак, если нет С++17 c std::filesystem.
Ну, да, конечно, без Qt и boost'а этого никак не сделать. ftell щас ваще не в моде, особенно, когда ты 17 лет в профессии. Очередной балабол, очередная статья (возможно, статья-провокация от человека, не имеющего никакого отношения к разработке).
На сипипи давно уже никто в здравом уме не начинает проекты. Только лютый кал мамонта, который переписать на жаву дороже, так и мучаются сектанты-мазохисты, пока их вместе с продуктом не выкинут на свалку истории.
Здравствуйте, Тёмчик, Вы писали:
S>>Тогда вы сильно недооцениваете количество находящихся "не в здравом уме".
Тё>Наверите "C++" на сайте по поиску работы, и посмотрите предложения. Поддержка кала мамонта и тех раз-два и обчелся.
Из того, что на новые проекты не набирают по объявлениям вовсе не проистекает то, что этих самых новых проектов нет.
Но вот почему вас C++ до сих пор беспокоит? Какие-то фантомные боли? Или когда вы программировали на C++, то были дороже, пользовались большим успехом у противоположного (а может и своего, по нынешним толерантным временам не поймешь) пола и здоровье позволяло этим успехом пользоваться? А сейчас уже остается только вспоминать, как трава была зеленее, вода мокрее, а хрен крепче?
Здравствуйте, landerhigh, Вы писали:
L>Ну что поделать. Не у всех разработка заключается в написании аналогов таров за четыре часа, кому-то и голову включать приходится.
Чувак, если у "разраба с опытом" такие простые вещи вызывают подобные сложности — о каких сложных вещах можно вообще говорить?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, landerhigh, Вы писали:
L>Я не про любого джуна спрашиваю. Тут уже двое били себя пяткой в грудь, что там на полчаса неспешного тайпанья. L>Еще раз. Зум сессия, лимит времени четыре часа. Напишешь?
Конечно напишу.
Осталось только заинтересовать меня в этом.
Здравствуйте, kaa.python, Вы писали:
Тё>>Как у современных микроконтроллеров обстоит с C++ exceptions и heap?
KP>Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17
KP>Рекомендую посмотреть вот это выступление дабы понять что может современный C++ и перестать писать тот бред что ты пишешь в этой теме. Если досмотришь до конца и поймешь о чем там говорят, тебе может даже стыдно станет
На какой секунде там C++ exceptions и heap? То, что чувак написал примитивную игру без исключений и динамической аллокации памяти- подтверждает мой пойнт. Полноценному C++ не место в ядре, не место в контроллерах.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>>>А расскажи, будь любезен, чем, по-твоему, "настоящий С++" отличается от "Си с классами"?
Тё>>Исключения, динамическая память, шаблоны, весь STL.
SVZ>Это всего лишь инструменты. Ты можешь их использовать, но не обязан. SVZ>Этим с++ и хорош.
Вы там определитесь- есть Стандарт C++. И тут же некоторые сиплюсплюсники бегают с костылями
Ты можешь их использовать, но не обязан.
Двойные стандарты. Именно поэтому под железки пишут на C, и только отдельные наркоманы делают доклады "смотрите, можно в микроконтроллер". Сектанты, как есть.
Здравствуйте, Nuzhny, Вы писали:
N>Потому что люди чаще всего выбирают не столько язык, сколько предметную область. В твоей области С++ был плох
Погоди погоди. Я всё-таки работал и работаю можно сказать, на bleeding edge технологий в интересных областях. Никогда не занимался т.н. "оперднями" и "формошлёпством". Именно поэтому C++ таким архаизмом видится. Ну, ты ж не пишешь в прод на q-бейсике из школы начала 90-х? И на турбо-паскале не пишешь. Но почему-то держишься за C++. Вот ты сам писал, что гуя у вас- десктоп на Qt. А Qt- наследник MFC.
N>не С++, а другой язык: Qt Widgets -> QML. Это нормально.
Нет, это ненормально. Это говорит лишь о застое в заросшей тиной распил-откатной конторе. Ибо для себя ты не потерпишь, чтобы за ради каждого чиха ставить дистрибутив на свой компьютер. Хороший маркер застрявших в эпохе FIDO — пользователи оффлайн клиента рсдн.
N> Не нормально, что ты превратился в кулика и хвалишь исключительно своё болото
Я лишь вижу, что обычные конторы с вменяемым руководством ушли от C++ в 2005г. Осталось узко-специфичные HFT, железячники, и игроделы. Очень специфичные области, очевидно, накладывают тяжёлый отпечаток на работников.
N>Хорошее видео про то, почему С++ так неудобен для многих задач
Да потому, что мир программирования ушёл вперёд. Зачем плестись в хвосте прогресса на уровне с дельфистами и VB6-ми, когда есть React.native например.
Здравствуйте, kaa.python, Вы писали:
KP>Я не знаю что у вас там в JS, но в языках близких к железу О-нотация не работает на маленьких объемах данных из за промахов по кэшу. О чем, собственно, тут и говорят. Вспоминай базу
Здравствуйте, netch80, Вы писали:
N>>>В этой дискуссии вы успешно показали непонимание предмета вами. Поэтому, действительно, обсуждать с вами нечего.
Тё>>Сливайтесь, сливайтесь. Ведь вам больно от того, что кто-то приоткрыл вам глаза на правду. Лучше живите в вымышленном мирке грёз про "сипипи круче всех".
N>Я в этой ветке вообще ни слова про C++ не сказал. Так что вы выдали себя по Фрейду
Вы в этой ветке продемонстрировали наивность и зашоренность. Отличительные признаки школьника, вчера узнавшего про шаблоны.
Здравствуйте, Тёмчик, Вы писали:
Тё>>>Текст в статье подтвердил моё первоначальное предположение- вы тупой сплит строки переусложнили в кромешный шаблонный ад. S>>Писать для каждого из таких заголовков тупой сплит строки нерационально. Тё>Если бы вы открыли букварь учебник Ахо, вы бы не изобретали это убожище. Тё>Сканер генерит поток токенов, из которого парсер строит AST. Оба являются конечными автоматами. Тё>Я хз нахрена у вас в сканере шаблон "probably_with_comma", когда всего-то нужно бить входной поток на токены. Там нужен простейший автомат.
Видите ли, Тёмчик... вы не пробовали и даже не пытались. Если бы попытались, то поняли бы, в чём проблема.
Ахо с компанией — "книга дракона" — это, конечно, стильно (толстый том полный странных букв... нет, я его читал). Проблема в том, что это не имеет никакого отношения к действительности — в частности, к той, которую формирует IETF.
Я буду дальше объяснять на примере SIP, а не HTTP — хотя они с точки зрения общего стиля применённого извращения близнецы-братья, но детали разные. Так вот — парсинг в принципе не укладывается в концепцию "бить входной поток на токены" "простейшим автоматом".
Для начала возьмём адресный поле (header field) (From, To, Contact, Route и ещё несколько) — хотя сплошь и рядом говорят только header. Вот варианты такого заголовка:
Вот мы начинаем разбирать то, что после "From:", пропустили пробелы, можем дальше искать или token (это такой грамматический элемент — да, именно так и зовётся, хотя бывают и другие токены), или quoted-string (как в (5)). OK, нашли token. Теперь после него если ':', то это короткая форма (как в (1) или (2), элемент addr-spec), но мы уже начали разбирать URL, найдя его схему. Если после него шёл ещё token, то это на самом деле display-name длинной формы (name-addr). Следовательно, нам уже нужен в стандартных понятиях предпросмотр минимум на 2 токена вперёд, чтобы выбрать вариант разбора.
Теперь в угловых скобках. В (2) foo.bar:5000 это хост foo.bar и порт 5000. В (3) foo.bar:5000 это юзер foo.bar и пароль 5000. Чтобы их различить, надо было добраться до '@' — если она есть, то всё перед ней было юзером и паролем. То есть это предпросмотр на 3 токена? Как бы не так. В доменной части может быть hostname, которое может быть в варианте IPv4 и IPv6. В варианте IPv4 его длина не ограничена, и если считать токеном один элемент между точками, то предпросмотр будет на неограниченную длину, а если всё за один, и определите его как то, что допустимо в DNS, вы в этом месте не отличите его от того же token. В варианте IPv6, например, у него есть символы [:], которые допустимы только тут, и ещё в элементе hvalue (см. случай (8)), но не в других местах.
Или вот например, в user допустимы кроме базового набора символов "&" / "=" / "+" / "$" / "," / ";" / "?" / "/", а в пароле только "&" / "=" / "+" / "$" / "," (на три меньше). Вы не сведёте это под один тип токена, если не будете токеном считать один символ.
А вот в примере (7) одинаковые с виду конструкции и с реально одинаковым значением параметра. Но address parameters имеют совсем другие правила квотинга, чем URI parameters или user parameters. Мало того, в address parameters (x3 в примере) грамматика неоднозначна: если будет x3=a.b.c.d, это соответствует правилу как token, так и host. Как отличать? А никак — пока вы по имени параметра это не определите.
Если вы это попытаетесь перевести на сканер, выдающий токены, вы не сможете это сделать без контекстов (как бы они ни назывались — conditions в flex и re2c, например): например, в начале адреса контекст будет выбирать quoted-string или single token, после второго надо выбрать — если ':', то это была схема и надо войти в соответствующий контекст (ой, а какой? для схемы sip и схемы tel они разные!) Но если станете переключать контекст на каждом прочтении, то у вас лексер быстро превратится в парсер, потому что будет знать все эти контексты сам. Ну и писать это на языке описания лексера — практически сразу повеситься.
И ещё: если во From: написано sip:foo.bar:5000;tag=123, то tag=123 это параметр адреса. А если в первой строке запроса, то это уже параметр URI. Чтобы сделать параметр URI, надо было писать: From: <sip:foo.bar:5000;tag=123> (всё в угловых скобках). Что, для этого надо было двоить контексты в лексере?
А если ещё учесть, что в авторизационных заголовках есть URI, который в кавычках, но внутри него полная грамматика URI... мне уже самому страшно, хоть у меня это всё и работает.
А вот на PEG такие вещи пишутся влёгкую — по крайней мере на >90% их, потому что 1) эти парсеры включают в себя грамматику лексем и контекст лексера сразу оказывается нужным в явном виде, 2) у них есть откат на произвольную длину назад.
Мало того, всё это влёгкую парсится на регэкспах! Это смешно звучит, но эти грамматики при всех их странностях нерекурсивны (максимум — есть списки), стандартных проблем регэкспов с грамматикой (в рекурсивном случае) нет, и на каком-нибудь Питоне на регэкспах (сишным движком) получается на порядки быстрее, чем на явной грамматике. А вот уже на Java лучше всего писать на циклах по классам символов (да, вручную, но быстро).
И никакая книга дракона вам такое не опишет: там авторы заняты совсем другими классами задач. Впрочем, она не поможет и для C++, где видя >> надо определить, это оператор сдвига вправо или закрытия двух шаблонных скобок. Кстати, PEG у них нет — для них он, видимо, некошерен?
Тё> И далее простой в доску парсер- генератор AST. Совсем по феншую, если сделать StAX интерфейс с visitor-м.
Ну сделайте. Только полный разбор, а не выбранных 5% стандарта... а мы посмотрим... а я, если потребуется написать что-то такое на C++, таки посмотрю на тот RESTinio (или на Spirit, если подойдёт по условиям).
А то разобрать стандартный Паскаль, где нет никакой зависимости лексера от контекста — все дартаньяны в белом, а как только что-то реальное — почему-то быстро переходят на более практические средства...
Здравствуйте, Homunculus, Вы писали:
H>Если что я уже больше 20 лет на С++ пишу, и не маленькие тулзовины, и нет никаких никаких вавилонских башень. Но мой случай, конечно частный, да-да.
Здравствуйте, landerhigh, Вы писали:
L>Ну что поделать. Не у всех разработка заключается в написании аналогов таров за четыре часа, кому-то и голову включать приходится.
Либо ты так троллишь, либо один тех павлинов, которые приходят с важным видом и космическим резюме на интервью, и не могут на доске написать разворот строки за O(n). Видимо, интервьювер им нитакой попался, слишком джуниорский вопрос дал.
Imho задачка написать простой аналог tar- весьма годная:
1) проверяет, что чувак не только языком чесать модет
2) приближенная к реальности бекенда
3) не заточенная на какой-то ЯП
4) и ненавязчиво посмотреть, применит ли правильные структуры и алгоритмы, или наговнит
Здравствуйте, CreatorCray, Вы писали:
CC>Впрочем в любом случае если embedded чел за 4 часа не способен накропать аналог tar — это лютое фиаско. Я не embedded а просто системщик, tar-ы ежедневно не пишу, но мне на это надо ну полчаса неспешного тайпания.
Давай так — создаем чат в зуме. И ты пишешь тар за полчаса четыре часа неспешного тайпанья
Здравствуйте, landerhigh, Вы писали:
L>Давай так — создаем чат в зуме.
Ты меня ещё убеди это говно поставить.
L> И ты пишешь тар за полчаса четыре часа неспешного тайпанья
Деньги за шоу вперёд!
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Хорошее в мире IT не приживается. Всюду C++ и прочие голанги и бидоны вместо лиспа, докеры вместо solaris zone, линуксы вместе благородных юниксов и BSD.
Здравствуйте, so5team, Вы писали:
Тё>>Эта статья разбор HTTP-заголовка Authorization с помощью easy_parser из RESTinio?
S>Да.
Тё>>Ну я почитал сейчас.
S>Не заметно.
Тё>>Текст в статье подтвердил моё первоначальное предположение- вы тупой сплит строки переусложнили в кромешный шаблонный ад.
S>Писать для каждого из таких заголовков тупой сплит строки нерационально.
Если бы вы открыли букварь учебник Ахо, вы бы не изобретали это убожище.
Сканер генерит поток токенов, из которого парсер строит AST. Оба являются конечными автоматами.
Я хз нахрена у вас в сканере шаблон "probably_with_comma", когда всего-то нужно бить входной поток на токены. Там нужен простейший автомат. И далее простой в доску парсер- генератор AST. Совсем по феншую, если сделать StAX интерфейс с visitor-м.
Почитал каменты тут. По-моему, автор абсолютно прав в параграфе, где в ++03 вектор писался за полчаса, а сейчас ты офигеешь учитывать все случаи копируемости-исключительности-итд объекта, офигеешь учитывать все непонятные UB и прочее? А что, не так разве?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
KP>>ЮАР безусловно прикольнее по куче параметров таких как природа, еда, вино, города и т.д...
М>Приснопамятный Мыщъх помню любил ЮАР нахваливать... Вроде он там жил даже какое-то время.
в притории
и работал в нормальной компании, мы с ним обшались но почему то не встретились
у меня была отличная черная мейд, но я тогда не знал на что его заманить
Привет,
Прочел что чел программировал 17 лет что составляет 2/3 его жизни и что он устал. Он еще статьи какие то читает по С++ (во странный...)
Дальше я читать поленился.
Я так думаю что С++ тут не причем, может человек влюбился, авитаминоз, может просто он не видит результатьов своего труда...
Здравствуйте, vsb, Вы писали:
vsb>Есть люди, которые воспринимают C++ как инструмент. Не очень удобный инструмент, но в целом жить можно. Они вряд ли будут использовать boost, разве что от большой нужды, они точно не будут ничего городить на шаблонах. Если им надо написать код на C, они просто его напишут, не страдая экзистенциальным кризисом.
Это точно. Страдать будут следующие разработчики, которым этот говнокод придется поддерживать.
Здравствуйте, Poopy Joe, Вы писали:
vsb>>Есть люди, которые воспринимают C++ как инструмент. Не очень удобный инструмент, но в целом жить можно. Они вряд ли будут использовать boost, разве что от большой нужды, они точно не будут ничего городить на шаблонах. Если им надо написать код на C, они просто его напишут, не страдая экзистенциальным кризисом.
PJ>Это точно. Страдать будут следующие разработчики, которым этот говнокод придется поддерживать.
Угу, слишком мало шаблонов — говнокод. Слишком мало абстракции, а вдруг придётся этот SIP-сервер, который щас крутится на 16-ядерном зионе-линуксе, портировать на 8-битный контролёр, нужно срочно навернуть абстракций.
А я тебе так скажу. Я лично видел ситуацию, когда один проект, написанный метапрограммистом, где шаблоны бустами погоняли, выкинули и переписали на простом "C с классами". Потому, что не осилили поддерживать это, после того, как создатель уволился. И новый вариант вполне себе живёт и развивается.
Здравствуйте, andyp, Вы писали:
A>Здравствуйте, vsb, Вы писали:
vsb>>PS это про Qt 4 примерно 15-летней давности, с тех пор может и туда пробрались шаблонисты.
A>Да, я тоже скучаю по голым new и delete и горам ООПшного бойлерплейта, реализующего тараканы абстракции из книжки по ООП к несчастью зачитанной писателем без толку и смысла. А как всё это текло, как дырявое корыто! Золотое было времечко
linux вообше запилин на Си
и нечего фатально не течет
Здравствуйте, Homunculus, Вы писали:
H>Если что я уже больше 20 лет на С++ пишу, и не маленькие тулзовины, и нет никаких никаких вавилонских башень. Но мой случай, конечно частный, да-да.
Аналогично. И тоже не понимаю всей этой истерики вокруг сложности.
$>Здравствуйте, landerhigh, Вы писали:
L>>Да нет конечно. Особенно имбеддед. Куда ж мне до светил программерской мысли!
$>По твоим батхертам на простые вопросы как-то даже непонятно, что ты вообще знаешь. Никогда никаких идей, только жалобы на плохих интервьюеров.
А ты себя к каким интервьюверам относишь?
L>>Родной, есть всего два варианта — выбираешь, какой сегодня нравится больше.
$>я
$>Ну так и рассказать про оба варианта, и когда лучше один, а когда- другой.
Рассказать? Ты о чем? Задача — один на один с компьютером. Рассказывать некому. "Мы вам позвоним".
L>>сомневаюсь, что за 4 часа у тебя дойдет до этого.
$>С такими кандидатами, сомневаюсь что дойдёт хотя бы до кривого единственного варианта
Уже как минимум двое в этом чати заявили, что там работы на полчаса от силы. Давай так — создаем чат в зуме и ты пишешь за четыре часа решение в онлайне.
Ты как маленький. Подобные "задачи" — отличная возможность слить кандидата. Докопаться можно до всего. Написал коротко и чисто на си без классов — не знает плюсов. Написал с использованием ООП — не знает шаблонов. Написал с шаблонами — переусложняет на ровном месте. Написал свой обработчик аргументов командной строки — не умеет пользоваться библиотеками. Использовал буст — тащит библиотеки на каждый чих. Можно и к оформлению придраться.
Димон, не доставай... LVV>>И разработчики, которые с модулями более 10 лет работают, сами неграмотные? DO>Какие разработчики работают с модулями?
Тут в соседних постах PM сказал, что над модулями работают более 10 лет... LVV>>Посмотреть на Модулу-2 не в состоянии? DO>Ну посмотрели на Модулу-2 и что? Валерий Викторович, вы вот пишите: DO>
А модулей нормальных нет до сих пор...
DO>Какие требования к модулям в С++? Чего вы от них хотите? Почему их отсутствие мешает? Почему их наличие хорошо? Какую проблему они решат? Судя по тому, что вы пишете ответы на эти вопросы у вас уже есть, продуманные, есть видение. Чего бы его не изложить?
Я занят более важными для меня делами.
Когда напишу диссер, напишу книжку еще одну, если не помру — напишу...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Poopy Joe, Вы писали:
PJ>Есть код простой, а есть код примитивный. Так вот шаблоны позволяют писать код простой, когда читателю достаточно понимать и оперировать абстракциями. А не утруждающие себя рассуждениями пейсатели обычно фигачат код примитивный, где читателю приходится декодировать полет их мысли в километровых спагетти-простынях.
У спагетти-кода есть большое преимущество — его легко поддерживать даже джуниору.
А С++ код может превратиться во что-то ещё более гадкое, чем спагетти-код, но чтобы его поддержать, придётся искать очень опытного С++ желающего во всём этом копаться.
Здравствуйте, alzt, Вы писали:
A>Ищет конктерный кусок, исправляет. Задача выполнена. Всё. Не надо разбираться в паттернах, изучать архитектуру. A>Вот, я когда освоил шаблоны С++, прочитал книжку Вандевурда, и минимизировал код, то следующему было сложно. Я вывел в компайл тайм всё, что смог. А я способный. Я думаю, что человек, который это поддерживал, многое бы отдал, чтобы это был просто спагетти код. Ему хотя бы шаблоны учить не пришлось. И разгребать было бы легче.
Высокоабстрактный код это не когда освоил шаблоны и вставил их как смог. Это когда когда читатель кода понимает, что именно хотел сделать автор, без вникания в детали как, даже не запуская его. В спагетти коде обычно все наоборот, мелкие шаги как это сделано, но непонятно зачем. Это первый уровень.
Второй, это когда корректные изменения сделать легко, а некорректные трудно, компилятор не даст. Ну и третий уровень, когда все это выражено на с++.
Здравствуйте, kaa.python, Вы писали:
KP>А ты как себе представляешь стек автономного автомобиля на Ноде?
Ну т.е. за неимением других инструментов, или за неумением готовить, начали пилить на C++. Хотя, не вижу принципиальных препятствий крутить ноду на arm линуксе.
Тё>>Сейчас на JS и микросервисах распределенных делаем вещи на порядки круче, чем было наивный монолит-копролит C++ в РФ.
KP>Ну UI же опять и всякие перделки, это побоку на чем делать. Представь себе Redis, ClickHouse, Mongo, Tarantul и т.п. на Ноде и всплакни.
Не пофигу. Redis и Mongo можно на go сделать. Плюсы там, как телеге пятое колесо
KP>Кстати, на Эликсире будет сильно элегантнее и проще в поддержке чем на Ноде.
Это хорошо, только где между титанами нодой и эликсиром место у сипипи?
Здравствуйте, kaa.python, Вы писали:
KP>Обеспечить прогнозируемое время отклика, прогнозируемое потребление памяти, прогнозируемое поведение при возникновении ошибок — никак не возможно.
Так это всё камешки в огород сипипи
Реалтаймовые системы не на плюсах делают.
KP> теории там мог бы подойти Rust, но смысла замены одного сложного, но хорошо известного инструмента с большой базой библиотек на другой сложный, но мало изученный в дикой природе и без библиотек так себе идея.
Раст себя уже показал в FF- тормозное г
KP>Нельзя. Для примера можно взять популярную базу данных написанную на Go — CockroachDB. Да, часть отвечающая за логику и распределенное управление данными написана на Go, что разумно. Но вот сам движок базы данных, внезапно плюсовый RocksDB.
Ну это фиаско, я считаю.
KP>>>Кстати, на Эликсире будет сильно элегантнее и проще в поддержке чем на Ноде. Тё>>Это хорошо, только где между титанами нодой и эликсиром место у сипипи?
KP>Задачи разные. Для всего есть место. Просто в странах с отсталым АйТи обычно остаётся только самый легок окупаемый минимум. Как раз Node, PHP и т.д. У меня в родном Бишкеке тоже только на Ноде да PHP работа, но это же не означает что C++ в целом не нужен.
Это ты про Сингапур? Вицепрезидент из Сингапура равняется середнячку- помидорке в Сиднее.
Здравствуйте, so5team, Вы писали:
Тё>>Так это всё камешки в огород сипипи Тё>>Реалтаймовые системы не на плюсах делают.
S>Артём, вы это сейчас всерьез, в здравом уме и трезвой памяти? Вот на полном серьезе утверждаете, что real-time не пишут на C++?
Ну особо упоротые, конечно, и STL в ядро запихивают (реальный случай кстати, чел на полном серьёзе предлагал зафигачить в виндовый драйвер C++ с STL-м).
S>Или уже успели бухнуть после рабочего дня?
Что, попка пригорело?
Вот это вот в многих C++ -в присутствует черта, апломб "С++ круче всех". В то время как жавист спокойно делают масштабируемые отказоустойчивые распределённые системы, С++ -к ведёт битву за очередной попорченный кусок памяти, проявляющийся в зависимости от фазы луны.
Здравствуйте, landerhigh, Вы писали:
L>Тёма, более того, на плюсах с шаблонами прекрасно пишутся прошивки для современных микроконтроллеров.
Как у современных микроконтроллеров обстоит с C++ exceptions и heap?
Здравствуйте, Тёмчик, Вы писали:
L>>Тёма, более того, на плюсах с шаблонами прекрасно пишутся прошивки для современных микроконтроллеров. Тё>Как у современных микроконтроллеров обстоит с C++ exceptions и heap?
Перефразируя анекдот:
Холмс научился программировать без динамической памяти и исключений.
А Тёма без трубки уже не мог.
Здравствуйте, Тёмчик, Вы писали:
L>>Холмс научился программировать без динамической памяти и исключений. Тё>Предлагаю т.н. экспертам C++ почитать стандарт C++. Вообще, такой степени упоротости у C++ ков в моё время (до 2010г) не было.
Артёмка, ты ж банально в С++ не умеешь и это бросается в глаза.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Тёмчик, Вы писали:
Тё>Исключения
На практике нужны редко но если уж так припёрло то можно поиметь и их на довольно таки многих платформах.
Тё> динамическая память
Делается на любой платформе где памяти достаточно.
Тё> шаблоны
А что с ними? Никуда они не деваются.
Тё> весь STL.
Который не сам язык С++ а просто вспомогательная библиотека, полностью написанная на нём же. Нет никаких проблем поиметь этот функционал на нужной платформе
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Nuzhny, Вы писали:
N>прости, но в какой именно конторе? За последние 10 лет я работал в 4-х, включая АМД и automotive в Люксофте.
Ну т.е. аутсорснутый кал мамонта.
N>Catalyst в АМД раньше тоже был написан на C# и его... закопали! Потому что глючил и тормозил.
Так его ж наверное, точно такой же орёл писал в бангалорском Люксофте, научившийся копипасту на диезе.
N>О, этот список гораздо шире. Я тут уже приводил выше, что множество проектов для нейросетей начинается именно на С++.
Множество проектов OS начинается на ассемблере. Значит, весь инструментарий на ассемблере.
N> серверов на С++. В России вакансий много в таких больших иностранных компаниях.
Ээээ чта?
Тё>>Да потому, что мир программирования ушёл вперёд. Зачем плестись в хвосте прогресса на уровне с дельфистами и VB6-ми, когда есть React.native например.
N>Эээ, ок. Fire and Motion, беги в голове прогресса.
Я в прошлом посещал митапы C++. Когда крутейшие мега-хацкеры докладчики C++ ниасилили линух и делают доклады на VC++ с форточки, про "новые открытия" кривая попытка клона Maven которому 20 лет, и кривая тормозная попытка клона ко-рутин с Питона, которым тоже 20 лет, ощущение, что попал на машине времени в диал-апные времена.
Здравствуйте, Тёмчик, Вы писали:
Тё>Какое место у C++ в программтровании FPGA например?
Вообще-то с++ для программирования ПЛИСов используется с незапамятных времен. Просто ты не в теме.
Тё>Матлабщики делают рокет саенс, а сиплюсники подносят снаряды, ничем не лучше жавистов или нодщиков.
Спасибо! Поржал!
Мы (сиплюплюсники) как раз делаем библиотеки для матлаба. Весь рокет саенс внутри. А матлаб это клей, как и питон.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Тёмчик, Вы писали:
Тё>Пойми, что амортизированная сложность C константа у V8 сравнима с Oracle JVM, а у той- с C++. Ибо обращение к свойствам JS обьекта в V8 происходит по смещению в памяти, там вставлен кусочек оптимизорованного C++-го кода. Специалистами Google оптимизированного, а не хайлендером, неспособным вызвать lower/upper bound ибо за 20 лет в индустрии, ниасилившего бинарный поиск.
Я что ты там принимаешь, но JS заметно медленнее даже на тупых синтетических задачах.
Тё>Хотя нет, не так. Жависты в среднем знают алгоритмы и многопоточку значительно лучше плюсников. Вот теперь можешь тушить коллектор.
А побоку, ты пока что демонстрируешь тотальную деградацию проф.уровня, так что твое мнение в данном вопросе имеет около нулевой вес.
Ты, кстати, не задумывался на тему того, что если довольно много людей со сравнительно не плохой квалификацией говорят тебе "Тема, ты несешь бред", то вероятность того что ты несешь бред сильно не нулевая? Делюсь тайным знанием: в таких ситуациях стоит остановиться и задуматься "а не несу ли я бред".
Здравствуйте, netch80, Вы писали:
N> Но вот хотя бы move-семантика, emplace*... — это то, что абсолютно неизбежно при желании писать хоть как-то оптимально.)
move-семантика это как раз худшее из нововведений. Оптимизировать нужно только отдельные участки кода. Вместо сложного синтаксиса rvalue-ссылок, лучше сделать элементарный метод move() в тех паре участков программы, где это действительно даст выигрыш.
Фанатики современного C++ обычно начинают возражать, что без move-семантики не получился бы unique_ptr<>, но это слабый аргумент.
Теоретически мув-семантика интересная фича, но на практике только усложняет код.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Marty, Вы писали:
Тё>>Не слежу за всеми. Основные гиганты это Angular (Google) и React (Facebook).
M>Фейсбук уже давно написал свой транспилятор своей пехапешечки в плюсики
А ты я смотрю, знаток пэхапе.
M>С JS/TS проблема тут только одна — нету компилеров в плюсики. Хотя, я вроде слышал, что уже что-то появилось
Где эти плюсики запускать?
M>Ты бы это — ну не смог — так не смог, зачем позорится-то?
Что именно не смог?
В своё время у меня был 99% рейтинг в тесте C++. А теперь какая-то школота, которая ниасилила строку развернуть, что-то там ко ко.
Здравствуйте, Тёмчик, Вы писали:
Тё>Ну так я что, с этим спорю? Да, узкие места расшивать на C (или C++, если оченно хочется именно плюсы). Это всё узкие ниши, много народа туда не требуется. Гугл написал tensor flow к примеру, и все её вызывают из питона.
Без всякого желания спорить, просто замечание. Вспомнил мнения разных людей, что TensorFlow и многие гугловские проекты, которые мы видим как открытые на Гитхабе, Гуглом практически заброшены и поддерживаются о остаточному принципу. Типа то, чем пользуются сотрудники для внутренних своих разработок, очень сильно отличается от того, что открывается для всех остальных. Гуглу, например, не очень интересно гонять нейросетки на видеокартах, им важнее их TPU. TensorFlow поэтому весьма медленный и проигрывает конкурентам, но его всё равно используют (сейчас уже намного меньше, PyTorch рулит), потому что исследователям, мелким конторам и одиночкам и так не написать. Тот же Abby делает альтернативу для себя (ресурсы позволяют) и оно работает быстрее и удобнее в обращении.
Майкрософт делает свой фреймворк, выкладывает его. А потом оказывается, что сами сотрудники внутри компании им и не пользуются, а переходят на продукты конкурентов.
Ну и так далее, много таких историй. Я недавно проходил собеседование в одну контору с международными продажами в сфере AI (очень известная в узких кругах), там у них тоже свой фреймворк для инференса сетей. И они одни из мировых лидеров в одной узкой области применения нейросеток.
Я к тому, что это всё идёт по старому сценарию, озвученному Joel Spolsky — "Fire and motion". Условные Гуглы выкатывают свои фреймворки, подсаживают на них людей, потом выкатывают новые версии и получается так, что все подсаженные идут в фарватере, виляя за лидером: не рядом, не впереди или в сторону. Им приходится поддерживать, переходить на новые версии, оставаться в рамках предложенного извне технического решения. Кому-то этого достаточно и он кормится внутри чужой экосистемы. Но многим мало и они создают свои решения и уже с ними могут вырваться. Не факт, что они вырвутся, но могут. Вот все эти условные Питоны и TensorFlow — это хороший путь для того, чтобы в предсказуемые сроки, делать предсказуемые продукты и получать предсказуемую прибыль. Это хороший путь, но может быть скучновато.
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, Shmj, Вы писали:
S>>Статья вышла в топ: https://habr.com/ru/post/497114/ Так же комменты доставляют:
Тё>На сипипи давно уже никто в здравом уме не начинает проекты. Только лютый кал мамонта, который переписать на жаву дороже, так и мучаются сектанты-мазохисты, пока их вместе с продуктом не выкинут на свалку истории.
Не знаю как сейчас в РФ, а в Германии вакансий С/C++ больше чем на джаву, по моей оценке. Причем половина проектов практически с нуля. Просто в РФ ничего в плане железа не производится и отсюда специфика рынка. Но это далеко не везде так. И шансов получить интересную задачу (со сложной алгоритмикой и т.д.) на плюсах в Германии гораздо больше, чем на джаве.
Здравствуйте, vsb, Вы писали: S>>я бы сказал С++ привлекает людей которым нравиться возиться с железом S>>или решать ресурсоемкие задачи
vsb>Ну я на всех не обобщал. В C++ полно кода, который просто работает и делает свою задачу. Я вот в Qt когда-то возился, в его исходниках в том числе. Всё там приятно и понятно написано. Но, уверен, идеалистам он не по вкусу. Исключения не используются, код не exception-safe, шаблоны только для классов-коллекций и вообще вместо STL свои классы, сигналы на генераторе кода, хотя можно было бы навернуть на шаблончиках и всего делов. Везде поганое наследование с виртуальными методами вместо статического полиморфизма на шаблонах. Уух, дряной фреймворк.
vsb>PS это про Qt 4 примерно 15-летней давности, с тех пор может и туда пробрались шаблонисты.
В теме уже несколько человек отметилось высказываниями что на C++ пишут многоэтажные шаблоны и некоторые проекты пришлось после таких творцов переписать, чтобы упростить. А можно для примера привести хотя бы кусок кода который был "шаблонный ужас" и стало "теплоламповое почти Си со вкраплениями классов"?
Ответ вам, т.к. форум не позволяет упоминать сразу нескольких пользователей, ну и "простой" код smeeld я кажется уже видел.
Я сейчас работаю на С++ проекте, которому лет 15, и он написан (на мой взгляд) в стиле Java — сплошной ООП с кучей интерфейсов (часто в роли callback с единственным методом) и с единственным классом-наследником для реализации; стратегии, фабрики-синглтоны, чтобы это единственную реализацию динамически создавать; самописный смарт-поинтер со счетчиком ссылок, для всех этих динамческих объектов, ну и само собой куча велосипедов для работы с файловой системой, процессами, потоками, блокировками и т.п. в библиотеке Util. Зато без буст и почти без шаблонов. Но с дикими перерасходом, фрагментацией памяти и враждебностью к кэшу. К счастью, это маскируется тем, что приложение работает в связке с Java и .Net частями на многоядерном железе с прорвой памяти.
Всё это добро даже в 2005 году можно было проектировать и писать проще — без лишнего догматизма, что интерфейсы рулят, а шаблоны это сложно и только для Александреску.
vsb>Угу, слишком мало шаблонов — говнокод. Слишком мало абстракции, а вдруг придётся этот SIP-сервер, который щас крутится на 16-ядерном зионе-линуксе, портировать на 8-битный контролёр, нужно срочно навернуть абстракций.
Не, слишком мало абстракций — говнокод. Шаблоны это их средство выражения в с++.
vsb>А я тебе так скажу. Я лично видел ситуацию, когда один проект, написанный метапрограммистом, где шаблоны бустами погоняли, выкинули и переписали на простом "C с классами". Потому, что не осилили поддерживать это, после того, как создатель уволился. И новый вариант вполне себе живёт и развивается.
Есть код простой, а есть код примитивный. Так вот шаблоны позволяют писать код простой, когда читателю достаточно понимать и оперировать абстракциями. А не утруждающие себя рассуждениями пейсатели обычно фигачат код примитивный, где читателю приходится декодировать полет их мысли в километровых спагетти-простынях.
$>Типичный говнокодер в комменте, каких тысячи. Проблема плюсников (не всех, но примазавшихся), что они принииают опыт хождения по граблям плюсов за знания программирования. Есть тру прогеры, которые могут за полчаса на коленке этот аналог tar накидать хоть на плюсах, хоть на си, питоне, ноде и чём угодно. Но их мало.
Да, а потом эти аналоги таров приходится вручную из продакшена выкорчевывать. Тру прогеры, my ass.
Здравствуйте, landerhigh, Вы писали:
L>Да, а потом эти аналоги таров приходится вручную из продакшена выкорчевывать. Тру прогеры, my ass.
Велосипедизмом тоже плюсники чаще страдают, кстати. Питонисты или нодщики просто берут и готовят из готовых библиотек. В случае нужды, могут и на C модуль сделать. Но плюсники часто пытаются забивать микроскопом гвозди, а нередко и не знают алгоритмов,
— ведь их опыт, это борьба с граблями.
Здравствуйте, vsb, Вы писали:
vsb>PS это про Qt 4 примерно 15-летней давности, с тех пор может и туда пробрались шаблонисты.
Да, я тоже скучаю по голым new и delete и горам ООПшного бойлерплейта, реализующего тараканы абстракции из книжки по ООП к несчастью зачитанной писателем без толку и смысла. А как всё это текло, как дырявое корыто! Золотое было времечко
Здравствуйте, kaa.python, Вы писали:
KP>Два сложных свежака начали на C++17 за последнии пару месяцев.
Каких и почему выбрали C++? Крыша протекла от сидения в карантине, или какие-то обьективные причины? Чем node не подошёл?
KP>И именно C++ в этих проектах самое оно. Но там да, это не опердень, это не JS с формочками
Сейчас на JS и микросервисах распределенных делаем вещи на порядки круче, чем было наивный монолит-копролит C++ в РФ.
Здравствуйте, Тёмчик, Вы писали:
Тё>Ну т.е. за неимением других инструментов, или за неумением готовить, начали пилить на C++. Хотя, не вижу принципиальных препятствий крутить ноду на arm линуксе.
Поднять — никаких проблем. Обеспечить прогнозируемое время отклика, прогнозируемое потребление памяти, прогнозируемое поведение при возникновении ошибок — никак не возможно. В теории там мог бы подойти Rust, но смысла замены одного сложного, но хорошо известного инструмента с большой базой библиотек на другой сложный, но мало изученный в дикой природе и без библиотек так себе идея.
Тё>Не пофигу. Redis и Mongo можно на go сделать. Плюсы там, как телеге пятое колесо
Нельзя. Для примера можно взять популярную базу данных написанную на Go — CockroachDB. Да, часть отвечающая за логику и распределенное управление данными написана на Go, что разумно. Но вот сам движок базы данных, внезапно плюсовый RocksDB.
KP>>Кстати, на Эликсире будет сильно элегантнее и проще в поддержке чем на Ноде. Тё>Это хорошо, только где между титанами нодой и эликсиром место у сипипи?
Задачи разные. Для всего есть место. Просто в странах с отсталым АйТи обычно остаётся только самый легок окупаемый минимум. Как раз Node, PHP и т.д. У меня в родном Бишкеке тоже только на Ноде да PHP работа, но это же не означает что C++ в целом не нужен.
$>Imho задачка написать простой аналог tar- весьма годная:
$>1) проверяет, что чувак не только языком чесать модет
$>2) приближенная к реальности бекенда
$>3) не заточенная на какой-то ЯП
$>4) и ненавязчиво посмотреть, применит ли правильные структуры и алгоритмы, или наговнит
Слишком много для собеседования. Ты же когда колбасу в магазине покупаешь, не претендуешь сожрать полбатона, чтобы распробовать, как она смотрится в разных конфигурациях. Непонятно, почему конторы претендуют сожрать полдня рабочего времени соискателя на должность, чтобы его получше распробовать.
По-моему, сомневаетесь — заключите разовый контракт и дайте небольшое *оплачиваемое* задание.
Здравствуйте, smeeld, Вы писали:
S>Нет там кроссплатформенного ничего. Вернее, что-то есть, но всюду с нюансами, которых почему-то нет в других ЯП-ах, заявленных как кроссплатформенные: java, python, golang. Ибо C++ застрял между верхом, там где java, python etc, где возможен полный кроссплатформ, и низом, миром Си. В результате ни того, ни другого, только кучи понтов и гемора на ровном месте.
Ну во-первых, C++ можно с успехом использовать на устройствах, на которых вообще нет понятия "открыть файл".
Во-вторых, если ограничиться дисковыми файлами и директориями, таки упаковщик можно написать на C++ кросс-платформенно. А если не ограничиваться, то ни на каком языке нельзя, потому что некоторые свойства файлов (например, является ли файл character device'ом), не являются кросс-платформенными.
Здравствуйте, Тёмчик, Вы писали:
N>>Так я и говорю. Будет эксплуататор с дохлым ноутом в поле (а защищённые ноуты все дохлые, потому что сложно сделать нормальную вентиляцию и охлаждение) смотреть на слайд-шоу и проклинать разработчиков. Оно мне надо? Оно надо этим людям, которым и так нелегко? Никому не надо. В кресле с игровым компом под столом можно писать и на js, я не против — пиши. Тё>А предложите вашим "эксплуататорам" воспользоваться айпадом про. И там всё плавненько в вебе полетит- вот будет облом C++ дрочерам.
Ты намеренно или по невнимательности предлагаешь использовать попсовый айпад про вместо защищенного ноута?
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, Nuzhny, Вы писали:
N>>Не 800х600, а вплоть до FullHD, не Атом, а i5-i7 U.
Тё>Действительно пропасть, и не смешно. Тё>
Тё>2,732 x 2,048 (265ppi)
Троль 80lvl запускает тему и смотрит, как другие колошматят друг друга виртуальными табуретками.
А ты создал тему, где все пинают тебя и ржут с комментов Надо работать над собой!
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Тёмчик, Вы писали:
Тё>Ну особо упоротые, конечно, и STL в ядро запихивают (реальный случай кстати, чел на полном серьёзе предлагал зафигачить в виндовый драйвер C++ с STL-м).
Виндовые дрова замечательно пишутся на С++, я это лично делал с десяток лет назад.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Тёмчик, Вы писали:
KP>>Да, приходят потом в мой код добавлять фич, случается адский песец, ну что, не все могут расширять мой гениальный код.
А это хороший повод для сомнений в гениальности кода. Ты уверен, что твоя оценка твоего кода правильная? Что говорят про гениальность кода другие разработчики?
Здравствуйте, Тёмчик, Вы писали:
Тё>Нужно называть вещи своими именами- C with classes.
... and (variadic) templates, RAII, static/dynamic polimorphysm, и прочие ништяки, которые встроены в сам язык а не сделаны на языке в виде библиотек (которые точно так же при необходимости подтачиваются под нужды платформы).
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Lexey, Вы писали:
Тё>>Почитай, узнаешь много нового. Я ж говорил- застряли в развитии в 1995г. L>Спасибо, но мне ехать, а не шашечки. Если мне понадобиться асинхронная обработка событий, то подходящие инструменты для нее я найду и без твоей помощи.
Здравствуйте, Умака Кумакаки, Вы писали:
УК>удаление из вектора для данного кейса (когда порядок элементов не важен) это O(1) операция, т.е. не зависит от размера вектора
Что ты заливаешь? Удаление из list это O(1), так как там всего лишь перекинуть prev-ы и next-ы. Для удаления из массива нужно или искать его в массиве, причём линейным брутфорсом, а не бинарным поиском, так как не массив неупорядочен, или при закидывании в массив сохранять индекс, и при удалении сдвигать все эелементы с изменением их индексов. И это вместо перекыдвания prev-ов и next-ов. Что касается упоянутого so5stream-ом неэффективного расхода памяти, при использовании list-а, то это, наверно, в его практике такое возможно. Обычно в нормальных проектах пилятся свой аллокаторы памяти для объектов, выделяющих память из пула, и хранящих сами куски в линейных массивах. Объекты для list будут жить там.
Здравствуйте, so5team, Вы писали:
S>Использование списка, массива или какой-либо другой структуры для хранения подписок -- это более чем принципиальный момент. Скажем, если "возвращать обьект Subscription с методом unsubscribe и внутри ссылкой на node", то vector для подписок будет не самым лучшим выбором. А при использовании list-а у вас будет оверхед по памяти и отсутствие локальности данных.
Попытаюсь объяснить упёртому...
Ну смотри — удаление подписки. Как ты её собрался искать в контейнере? Какова стоимость?
S>оверхед по памяти и отсутствие локальности данных
Ты это серьёзно сейчас? Из кривых тормозных кусков кода ты готов замерить оверхед и локальность данных?
S>Но хватит зубы заговаривать, повторяю вопрос: каким боком здесь "устройство цикличного списка и возможность возвращать обьект Subscription с методом unsubscribe и внутри ссылкой на node"?
S>>>Зачем нам шаблоны какого-то Boost-а, если у нас своих полно? Тё>>Ну так а я про то, что мазохисты-сектанты с верой, что компилятор C++ из говна O(n*n) сделает ракету.
S>Ничего не понял, что сказать-то хотели?
Тё>>О чём с фанатиками разговаривать. И конторы плюсные поэтому специфические.
S>Пока что единственный фанатик здесь вы. Фанатично верите в каких-то абстрактных C++ников.
Одного из этих "отдельных представителей профессии" ты можешь увидеть в зеркале.
Здравствуйте, Тёмчик, Вы писали:
Тё>Ну смотри — удаление подписки. Как ты её собрался искать в контейнере? Какова стоимость?
Зависит от обстоятельств. К которым мы перейдем ниже, там где фрагменты кода появятся.
S>>оверхед по памяти и отсутствие локальности данных Тё>Ты это серьёзно сейчас?
Гораздо более серьезно, чем когда вы заявляете, что C++ не используется для рилтайма.
Тё>Из кривых тормозных кусков кода ты готов замерить оверхед и локальность данных?
Как бы когда жизнь заставляет, то приходится замерять. Вне зависимости от качества кода. Более того, чем ниже качество, тем актуальнее становятся замеры.
S>>Но хватит зубы заговаривать, повторяю вопрос: каким боком здесь "устройство цикличного списка и возможность возвращать обьект Subscription с методом unsubscribe и внутри ссылкой на node"?
Тё>https://en.wikipedia.org/wiki/Sentinel_node#Linked_list_implementation
Да уж, так откровенно расписаться в незнаниях C++... Это нужно постараться. Хотя, возможно, когда вы еще имели дело с C++, вам даже C++98 был недоступен.
Ибо в C++ Node<T> хранил бы экземпляр T не по указателю, а по значению. А то у вас получится по две аллокации на объект в списке: первая для самого T, вторая для Node<T>.
Кроме того, приведенный выше код можно считать документально зафиксированным подтверждением того, что местный Тёмчик говнокодер, неспособный в простейшие структуры данных. Ибо такая наивная реализация изъятия элемента из двусвязного списка без проверки на null значений node.prev/node.next -- это про*б сравнимый с неспособностью развернуть строку. Тёмчик, почему меня не удивляет факт того, что вы говнокодер?
Тё>Сложность удаления O(1). Сложность добавления в конец либо в начало (по вкусу) O(1).
А теперь давайте по сути. Допустим, у вас есть что-то вроде:
template<typename T> class Node {
T value_;
Node<T> * prev_;
Node<T> * next_;
};
class Subscription {
Node<T> * item_;
...
};
В качестве T у нас POD с двумя указателями.
Итак, нужно хранить два указателя. Для чего нам потребуется еще три указателя (два в Node, один в Subscription). Плюс добавим сюда тот факт, что Node будет аллоцироваться как отдельный объект. Т.е., скорее всего, ему должен предшествовать какой-то непустой memory-control-block + Node должен быть соответствующим образом выровнен (не будем сейчас брать вырожденные случаи с супер-пупер аллокаторами, которые не нуждаются в MCB и определяют принадлежность куска памяти по значению указателя). Скорее всего получится, что оверхед на хранение информации в списке будет раза эдак в два.
Далее, если пописчиков немного (не более десятка), то на современных процессорах тупой линейный поиск по маленькому (но непрерывному) вектору с последующим изъятием, будет эффективнее, чем скакание по разным кускам памяти для модификации соседних элементов в списке.
Далее, можно коснуться вопроса эргономики. Если у нас появляется объект Subscription, то его нужно будет хранить. Что далеко не всегда удобно. Бывают случаи (и таких случаев, могу утверждать из собственного опыта, немало) когда все, что нужно для отписки -- это указатель на сам callback. Даже не обязательно значение opaque-pointer-а, который при подписке связывается с callback-ом.
Если достаточно всего лишь указателя на callback, то хранение для каждой подписки Subscription -- это дополнительная головная боль. Особенно в C++, где ничего не защищает от обращения к повисшим указателям. Использовали экземпляр subscription для отписки один раз, а потом, по ошибке, сделали отписку повторно. И что будет в итоге? Хорошо, если при первой отписке значение в Subscription::item_ занулили. А если нет? Тут ведь и на ABA проблему можно нарваться.
Так что, как бы вам не привычно было бы видеть объект Subscription, в разных ситуациях привлекательность этого подхода может быть ну совершенно разной. Включая и "ниже плинтуса".
Тё>>>Посмотри на реализацию событийной модели здорового человека- может что-нибудь новое для себя узнаешь.
S>>На какую именно? Тё>http://reactivex.io/RxCpp/ Тё>http://reactivex.io/RxCpp/rx-publish_8hpp.html
Ок, спасибо. Посмотрю.
Тё>Одного из этих "отдельных представителей профессии" ты можешь увидеть в зеркале.
Для аргумента "сам дурак" вы что-то слишком сильно щеки надули.
Здравствуйте, so5team, Вы писали:
Тё>>>>Ну смотри — удаление подписки. Как ты её собрался искать в контейнере? Какова стоимость?
S>>>Зависит от обстоятельств. К которым мы перейдем ниже, там где фрагменты кода появятся. Тё>>Не юли.
S>Сперва прочитайте то, что вам пишут, потом уже отвечайте.
OMG да я понял, что вы давно слились, когда запели про "10 подписок".
S>>>Гораздо более серьезно, чем когда вы заявляете, что C++ не используется для рилтайма. Тё>>Я заявлял, что в ядре не место C++. Именно полноценному C++, ибо C-с-классами не является полноценным C++ в понимании стандарта C++.
S>Вы заявили следующее (http://rsdn.org/forum/job/7907304.1):
Реалтайм бывает soft и hard. Soft вообще похрен на чём делать, а для hard плюсы не подходят (если не рассматривать C с классами).
>> Реалтаймовые системы не на плюсах делают.
S>Все ходы записаны.
Тё>>И часто вас жизнь заставляет замерять оверхед на 10 элементах?
S>Нет. Но бывает.
S>>>Ибо в C++ Node<T> хранил бы экземпляр T не по указателю, а по значению. А то у вас получится по две аллокации на объект в списке: первая для самого T, вторая для Node<T>. Тё>>Ты в курсе, что есть указатель на T, в данном случае? Может быть, это указатель на какой-то родительский объект или другую подписку, которого можно дёрнуть для оповещения об изменениях. Может быть, его и заполнять необязательно.
S>Тёмчик, давайте говорить о примере от B0FEE664. В котором под T можно подразумевать только std::pair<OnPress, void*>. Если вы хотите ввести в обсуждение еще что-то, то потрудитесь это описать, чтобы люди понимали, о чем речь.
Почему у вас onpress в типе? Почему у вас void*? Вы что, про статическую типизацию не слыхали?
По уму, там интерфейс нужен типа такого
S>Т.е. вы для хранения списка подписок предлагаете хранить еще и специальный sentinel node?
Я не "предлагаю" — это оптимизация связного списка для упрощения его операций, почитайте, учиться ведь всегда полезно.
Тё>>Если пописчиков немного, то не стоит заморачиваться на алгоритмическую сложность.
S>Если вы еще не заметили, то речь идет не про алгоритмическую сложность, а о стоимости по памяти и времени исполнения. В случаях, когда подписчиков немного.
Тё>>Кто управляет временем жизни callback?
S>Подписчик.
Ну вот ваш подписчик должен хранить интерфейс для отписки. Может хранить пачку таких подписок в списке, и отписываться в деструкторе, например. Тоже такой наивный способ. Элегантный способ в http://reactivex.io/ — использовать оператор takeUntil().
S>>>Если достаточно всего лишь указателя на callback, то хранение для каждой подписки Subscription -- это дополнительная головная боль. Особенно в C++, где ничего не защищает от обращения к повисшим указателям. Тё>>У хорошего плюсника не бывает тухлых указателей. Вы к таким определённо не относитесь.
S>Без разницы к каким вы меня относите. Суть в том, что такая проблема есть. И решений, которые ее провоцируют, следует избегать. Тогда будет не важно, хороший плюсник работает с кодом или нет.
S>>> Использовали экземпляр subscription для отписки один раз, а потом, по ошибке, сделали отписку повторно. И что будет в итоге? Тё>>В итоге будет nullptr и это правильно. Ибо кривые руки повторно-вызывальщиков отписок, релизов, диспозов и прочих делетов нужно испрямнять жёстко и без церемоний.
S>На словах все герои. Только вот если у вас отписка работает через поиск (по указателю на callback или по какому-то уникальному Id), то она оказывается более устойчивой к подобным ошибкам.
Т.е. вы смирились с фактом, что в вашем говнокоде нет определённости, придёт отписка дважды, или вообще не придёт. И поэтому вы городите тормозной кривой код, оправдывая это порно "локальным кэшем".
S>Кроме того, в C++ объекты по умолчанию копируются. Т.е. если есть: S>
S>То потребуется еще позаботится о том, чтобы объекты Subscription не копировались. Потому что зануление node_ в копии никак не скажется на исходном объекте. А до C++11 нормальных средств для этого в языке не было (а код от B0FEE664 явно написан для C++98).
Возвращается ссылка на интерфейс Subscription. Это может быть наследник от Node имплементирующий Subscription. О каком каком копировании вы поёте?
Здравствуйте, so5team, Вы писали:
S>Как удобно: когда по делу сказать нечего, то нужно наговорить собеседнику кучу гадостей.
S>Вот реально не понимаю, как паттерн Visitor поможет при работе с C API. Ладно бы еще какой-нибудь Facade был упомянут, ну или Bridge хотя бы, но Visitor... Просветите старика, плиз.
Дано: одно или несколько сторонних API. Нужно: сделать бесшовную интеграцию. Передаём visitor на нужное API. Это широко используемая практика в обработке данных от пачки разных API разных версий.
S>По поводу накладных расходов все было уже расписано ранее, перечитайте. По поводу "мутно", если вам не понятно, то речь шла про понятность политки владения сущностями в вашем подходе. В C++ сборщика мусора нет. Возвращать голые владеющие указатели так себе способ.
Можете сделать умный указатель для subscription. Да, C++ это боль.
S>PS.
>> Готов ответить за звиздёж в любое время.
S>Видели:
>>> Реалтаймовые системы не на плюсах делают.
S>Ответили за звиздеж, да.
Не на плюсах. Вот вы влезли в тему событийной модели, которой я сейчас плотно занимаюсь (использую RxJs). Я указал вас ссылку, что использовать вместо кривого велопеда — RxCpp.
Читайте и просвещайтесь. Может быть, в вашей области событий нет, отсюда и пустота в голове.
Здравствуйте, Lexey, Вы писали:
L>Безнадежен тут только ты. Ты даже не попытался объяснить, каким боком приведенный кусок кода относится к поставленной задаче. И зачем в нем нужен визитор, а не просто какой-то интерфейс, выполняющий роль колбэка.
Визитор, внезапно, это колбек.
Тё>>Вы зачем-то пытаетесь притянуть shared_ptr. Зачем?
L>В предложенной тобой схеме каждый Subscription должен владеть списком подписок.
Каждая подписка должна владеть списком подписок? Ты сам-то понял, что написал?
Кто чем владеет- не обсуждалось.
Можно сделать, что если Observable удалён раньше, чем последняя подписка- отцепить его sentinel от циклического списка и оставить неотписавшихся висеть в памяти. Когда неотписавшиеся отпишутся, они себя очистят.
Тё>>Если вы его суете во все дыры, — это ещё не значит, что его нужно сувать во все дыры. И кроме того, даже shared_ptr можно реализовать без разделяемого счётчика на куче. Но вы же этого ничего не знаете.
L>Да, несомненно, сокровенное знание про make_shared доступно только тебе. И интрузивных поинтеров никто кроме тебя в своей жизни не писал.
Ещё один безграмотный. Речь про shared_ptr без разделяемого счётчика на куче.
Тё>>Ещё раз. Когда я писал на C++, ни у кого не было претензий к моему уровню, и максимальные баллы на тестах это подтверждали. Вы же просто сынок в сравнении с нормальным C++ м.
L>Это прекрасно. Правда, в этом свете не очень понятно, почему ты сейчас демонстрируешь крайне низкий уровень понимания C++. И практически полное отсутствие самокритики.
Перечисление граблей- это по-твоему понимание C++? Ну так тогда ты на 100% попадаешь под моё описание C++ ка.
Тё>>RO-данные можно загружать в удобоваримой форме. Но откуда вам знать про это- вы же ничего в структурах данных и алгоритмах не понимаете. Весь интеллект потрачен на хождение по костылям.
L> Внезапно, чаще всего эта удобоваримая форма как раз и соответствует вектору, unordered map'у или map'у, или их комбинациям. То, что ты этого не знаешь, говорит только о твоем опыте использования C++, и ни о чем больше.
Если тебе использование C++ разжижило мозг, то это твоя проблема. Ибо на массиве, r-b tree и hash map, структуры данных не заканчиваются.
L>Откровенное хамство никак не добавляет веса твоим словам.
Взаимно.
Здравствуйте, so5team, Вы писали:
S> Но ведь вы же как попрыгунья-стрекоза: "интересно делать новые проекты, изучать новые технолигии, (старые) алгоритмы, и т.д."
А вот тут обидно было (вспоминая портянку языков с которыми работал последние 10 лет )
Здравствуйте, so5team, Вы писали:
S>У меня было всего одно собеседование много-много лет назад. И там никому не нужно было обсуждать знания алгоритмов. S>Да сколько угодно. К нам обращаются за поддержкой старого кода.
Вот он, диагноз: незнание алгоритмов, надроч на шаблоны, копролит мамонта.
Интересно за kaa-python конечно, но он скорее исключение, а вот вы — подтверждение правила.
Здравствуйте, so5team, Вы писали:
Тё>>Что я не бегаю с безумными глазами и не твержу "С++ всех быстрее"?
S>Покажите C++ников в этой теме, которые бы твердили "C++ всех быстрее". С ссылками и цитатами.
Вы сами твердили в споре про sentinel node и демонстрировали непонимание предмета. А когда я предложил решение на ёлку залезть (O(1)) и непоцарапаться (cache locality), вы перешли на оскорбления.
Тё>>Квалификацию этих людей можно проверить на интервью.
S>Квалификация на интервью не проверяется. Происходит это уже после интервью, на испытательном сроке, и требует гораздо больше времени, чем даже многоэтапные интервью.
Это только в том случае, что интервью успешно пройдено. Я вас уверяю- с вашими познаниями алгоритмов и претензиями на превосходство в профессионализме, вы бы не прошли интервью.
S>Тёмчик, еще раз: у некоторых из тех, кого вы называете "не знающими алгоритмы плюсодрочерами" в OpenSource десятки тысяч строк код.
Мне неинтересно читать ваш отлаженный код. Я уважаю ваше стремление делиться наработками, поэтому не буду искать, где бы докопаться.
Вы же, со своей стороны, продемонстрировали нежелание вести конструктивный диалог. Вы докопались к синтаксису шаблонов, в то время как синтаксис быстро забывается, но вернуться к языку я могу в любой момент. Это как кататься на велосипеде.
Когда-то я любил C++. К сожалению, тусовка C++ сейчас не та. Многие хорошие программисты ушли из этой темы, рано или поздно. Любого старого жависта посмотреть историю- найдёшь плюсника в молодости.
Здравствуйте, Тёмчик, Вы писали:
S>>>>Покажите C++ников в этой теме, которые бы твердили "C++ всех быстрее". С ссылками и цитатами. Тё>>>Вы сами твердили в споре про sentinel node и демонстрировали непонимание предмета. S>>Если я это твердил, то вам не составит труда дать ссылку на конкретную цитату. Тё>http://rsdn.org/forum/job/7913002.1
S>>Кроме того, приведенный выше код можно считать документально зафиксированным подтверждением того, что местный Тёмчик говнокодер, неспособный в простейшие структуры данных. Ибо такая наивная реализация изъятия элемента из двусвязного списка без проверки на null значений node.prev/node.next -- это про*б сравнимый с неспособностью развернуть строку. Тёмчик, почему меня не удивляет факт того, что вы говнокодер?
Ну и где здесь хоть слово про "С++ всех быстрее"?
Тё>>>А когда я предложил решение на ёлку залезть (O(1)) и непоцарапаться (cache locality), вы перешли на оскорбления.
S>>Было предложение хранить ноды в преаллоцированном векторе фиксированного размера. За такое сразу в сад. Ибо если есть возможность заранее предсказать количество подписок, то пляски с динамическими контейнерами не нужны. Тё>http://rsdn.org/forum/job/7913532.1
Нет. Пока ни одной по теме разговора.
Тё>Вы сами завели объект sentinel в теле SubscriptionStorage
Во-первых, я ничего не заводил. Прочитайте оригинал:
У меня пока проблема в том, чтобы разобраться с предложенным вами вариантом. Т.е. понять, что это за вариант вообще.
Пока что вырисовывается приблизительно такая картина:
Вы не привели ни строчки нормального кода и мне пришлось фантазировать с ваших слов. Т.е. это мой набросок вашего решения, что вы и подтвердили:
Примерно так, только названия поменять:
Тё>а потом докопались, в оскорбительной форме "со времен 1990-х по рукам бъют" SubscriptionStorage присваивать указатель на поле из тела SubscriptionStorage.
Ну что поделать, если за такие присваивания в C++ бьют по рукам с 1990-х.
S>>просьба обратить строку от чайника, который не в курсе, какие способы представления строк встречаются в природе, она о многом говорит. О многом плохом, касающемся конторы. Тё>
Тё>In computer programming, a string is traditionally a sequence of characters
Тёмчик, "последовательность" вовсе не означает, что строка представлена в виде одного непрерывного вектора, ваш К.О.
Тё>Я продолжаю задавать написать функцию "перевернуть строку", но сразу с сигнатурой reverseString(char[] a): void — больше никаких open-ended.
Вы уже окрасили себя в те цвета, в которые... Короче, поздно отмываться.
S>>>>Тёмчик, еще раз: у некоторых из тех, кого вы называете "не знающими алгоритмы плюсодрочерами" в OpenSource десятки тысяч строк код.
Тё>Я не наезжаю на вас неаргументированно. Только по делу. И ваша библиотека в опен сорсе мне неактуальна. Может быть, она неплохая, я не знаю.
Во-первых, она не одна. Во-вторых, вопрос не про актуально ли для вас что-то. Может для вас актуально, когда вас в 40 лет со всей дури в боксерском зале по башке мутузят. Если уж вы заговорили о недостаточной квалификации собеседников, то вам прозрачно намекают на способ проверить эту самую квалификацию. Так что либо аргументы в студию, либо рот закройте.
Тё>Набросились, коршуны . Я перестал писать на C++ до введений C++ 11. Ну да, неправильно использовал emplace_back. Это страшный грех, учитывая, что этих вещей не было в моё время в C++?
Здравствуйте, Тёмчик, Вы писали:
L>>Лет 15 назад, разве что. Не думаю, что речь идет про настолько старый код. Тё>C++ 2011 не "Лет 15 назад," вышел,плюс ещё лет 5 индустрия догоняла.
Я тебе говорил уже, что в 2005-м уже точно были нужные контейнеры, хоть и не в стандарте. Те, кому нужно было, их спокойно использовали.
Тё>Тема и так твердит про убогость инструмента C++ и дремучесть отдельных представителей профессии.
Вместо этого Теме стоило бы консерваторию подправить, чтобы понимать области применимости тех или иных решений, а не тупо напирать на big-O.
Здравствуйте, $$, Вы писали:
L>>Да, а потом эти аналоги таров приходится вручную из продакшена выкорчевывать. Тру прогеры, my ass.
$>Велосипедизмом тоже плюсники чаще страдают, кстати. Питонисты или нодщики просто берут и готовят из готовых библиотек. В случае нужды, могут и на C модуль сделать. Но плюсники часто пытаются забивать микроскопом гвозди, а нередко и не знают алгоритмов,
$>- ведь их опыт, это борьба с граблями.
S>Другой пример. Год назад про PEG-парсинг я знал только название. Но когда потребовалось, то не только разобрался, но и сделал средства для описания PEG-грамматик средствами C++14 (о результатах можно прочитать здесь, код посмотреть здесь и здесь).
Заставь дурака богу молиться...
template<
typename Container,
typename Element_Producer >
RESTINIO_NODISCARD
auto
maybe_empty_comma_separated_list_p( Element_Producer element )
{
static_assert( impl::is_producer_v<Element_Producer>,
"Element_Producer should be a value producer type" );
return impl::maybe_empty_comma_separated_list_producer_t<
Container,
Element_Producer >{ std::move(element) };
}
Здравствуйте, netch80, Вы писали:
N>Видите ли, Тёмчик... вы не пробовали и даже не пытались. Если бы попытались, то поняли бы, в чём проблема.
Я не пробовал и не пытался писать парсеры к фидам сообщений с бирж и брокеров, много лет. Много их форматов, все не вспомнить.
N>Ахо с компанией — "книга дракона" — это, конечно, стильно (толстый том полный странных букв... нет, я его читал).
Читать вы её может быть, читали, но ничего не поняли.
Здравствуйте, Тёмчик, Вы писали:
N>>Не поняли её как раз вы — судя по вашим прогонам про "поток лексем из парсера" и "тривиальные автоматы". N>>Жаль, я надеялся на конструктивное обсуждение. Тё>Чтобы что-то с вами обсуждать, у вас должно быть какое-то понимание предмета.
В этой дискуссии вы успешно показали непонимание предмета вами. Поэтому, действительно, обсуждать с вами нечего.
Здравствуйте, Тёмчик, Вы писали:
Тё>Визитор, внезапно, это колбек.
Угу, только вот, внезапно, колбэк не обязан быть визитором. И никаких аргументов в пользу того, что тут нужен именно визитор, а не простой указатель на функцию или std::function, например, от тебя не наблюдается.
L>>В предложенной тобой схеме каждый Subscription должен владеть списком подписок. Тё>Каждая подписка должна владеть списком подписок? Ты сам-то понял, что написал?
Я-то прекрасно понял. Потому что решал подобные задачи на практике. А вот ты упорно не понимаешь проблему.
Тё>Кто чем владеет- не обсуждалось.
Эта тема поднималась, только ты с нее соскочил на наезды на детали реализации. Исходная схема, когда единой точкой входа и для подписок и для отписок являлся менеджер подписок, тебя не устроила. Ты вместо нее предложил схему, где отпиской управляет отдельный объект Subscription, и про менеджер после подписки можно забыть. Вот и получил необходимость поддерживать жизнь списка подписок через Subscription'ы, а не только через менеджер.
Тё>Можно сделать, что если Observable удалён раньше, чем последняя подписка- отцепить его sentinel от циклического списка и оставить неотписавшихся висеть в памяти. Когда неотписавшиеся отпишутся, они себя очистят.
Ну, то есть, мы возвращаемся к тому, что при отписке никакого сентинела может уже не быть, и это нужно учитывать. И нафига он тогда вообще нужен? Это не говоря о том, что в реальной жизни помимо списка подписок и сентинела почти наверняка нужны будут какие-то вспомогательные флаги/мьютексы/т.п.
Тё>Ещё один безграмотный. Речь про shared_ptr без разделяемого счётчика на куче.
Сам ты безграмотный. Ты можешь, наверное, написать аллокатор, который будет хранить счетчик в статической памяти, например. Или написать свой shared_ptr, который будет его хранить хрен знает где (в TLS, например). Только, это никому не нужно, ибо через make_shared счетчик спокойно аллоцируется в той же памяти, что и объект, которым владеет shared_ptr. А в случае интрузивных поинтеров счетчик просто является частью объекта.
Тё>Перечисление граблей- это по-твоему понимание C++? Ну так тогда ты на 100% попадаешь под моё описание C++ ка.
Если тебе всюду мерещатся грабли, то с этим к психиатру надо бы.
Тё>Если тебе использование C++ разжижило мозг, то это твоя проблема. Ибо на массиве, r-b tree и hash map, структуры данных не заканчиваются.
Мне оно мозг, наоборот, укрепило. Например, я не пытаюсь пихать сомнительные паттерны везде, где только можно. И не хватаюсь использовать сторонние библиотеки только потому, что они выглядят красивее, чем кастомные решения. И главное, не считаю себя умнее всех.
Что касается структур данных, то тут можно вспомнить классическое "правило" 80/20: >80% кейсов покрываются именно векторами, хеш-мапами и упорядоченными мапами.
Здравствуйте, so5team, Вы писали:
S>Так ведь некоторые за год умудряются вобрать в себя больше, чем иные за три. Так что тут все индивидуально.
Но вообще ты однозначно прав, не возможно писать на куче языков и знать эту кучу хорошо, в лучшем случае не очень плохо. Меня периодически глючит и я то один то другой язык забываю, особенно знание C++ страдает. Разве что Go не забывается, т.к. там забывать как-бы и нечего
Здравствуйте, Тёмчик, Вы писали:
S>>Ну и где здесь хоть слово про "С++ всех быстрее"? Тё>Вам мало этой цитаты?
Не просто мало. Она не имеет никакого отношения к "Покажите C++ников в этой теме, которые бы твердили "C++ всех быстрее". В этой цитате нет ни слова про скорость C++ в частности, не говоря уже о каком-либо превосходстве C++ вообще.
Тё>В вашем наброске моего решения sentinel в теле SubscriptionStorage. Побейте себя по рукам.
С ваших слов моим наброском ваш замысел зафиксирован точно. Вы сами подтвердили. Так что a) ко мне никаких претензий, и b) хотите что-то показать -- показывайте сами. Хотя для этого же C++ знать нужно...
S>>Тёмчик, "последовательность" вовсе не означает, что строка представлена в виде одного непрерывного вектора, ваш К.О. Тё>Так ещё лучше. Можете предложить разворот списка.
И не обязательно представлять последовательность в виде списка. Все тот же К.О.
Собственно, я еще в прошлый раз стебал вас тем, что ваши требования написать разворот списка убоги и смешны уже потому, что вы не имеете понятия о разнообразии способов представления строки. В таких обстоятельствах показывать вам что-нибудь -- это метать бисер перед свиньями.
Тё>>>Я не наезжаю на вас неаргументированно. Только по делу. И ваша библиотека в опен сорсе мне неактуальна. Может быть, она неплохая, я не знаю.
S>>Во-первых, она не одна. Во-вторых, вопрос не про актуально ли для вас что-то. Может для вас актуально, когда вас в 40 лет со всей дури в боксерском зале по башке мутузят. Если уж вы заговорили о недостаточной квалификации собеседников, то вам прозрачно намекают на способ проверить эту самую квалификацию. Так что либо аргументы в студию, либо рот закройте. Тё>И чо?
И все. Рот закройте. Или аргументы предьявите.
Тё>Есди вы не можете даже развернуть строку-
См.выше.
Тё>втирайте в более другом месте про вашу неимоверную крутизну.
Не нужно уходить в сторону от обсуждения уровня квалификации. Вы в очередной раз вякнули неподумавши, а когда вас ткнули носом в ответственность, начали вилять.
Приведу вам пару примеров.
Несколько лет назад потребовалось избавится от ACE в зависимостях и написать свою реализацию таймеров вместо ACE-овских. Для чего, среди прочего, потребовалось самостоятельно реализовать структуру данных heap. При том, что на тот момент я знал лишь про ее существование и широкое использование этой структуры данных в приоритеных очередях, но ничего не знал о том, как же она устроена. И ничего, за пару часов разобрался. Получилась своя реализация. Но если сейчас меня попросят рассказать про heap, то я ничего не вспомню. Ибо не нужно.
Другой пример. Год назад про PEG-парсинг я знал только название. Но когда потребовалось, то не только разобрался, но и сделал средства для описания PEG-грамматик средствами C++14 (о результатах можно прочитать здесь, код посмотреть здесь и здесь).
К чему это все? А к тому, что если вас в ВУЗе учили хорошо, то в голову вам должны были вложить не конкретные знания, а способность к обучению. Вот меня учили хорошо, поэтому я могу многого не знать, но быстро осваивать при необходимости.
И это, вообще-то, в свое время было нормой для профессии разработчика ПО.
Тё>Я не разбираюсь в нововведениях C++ 11
Т.е. не разбираетесь в предмете разговора. Кроме того, вы и в C++98 не разбираетесь.
погуглил по нику автора, ничего выдающегося не нашел
вообще это стадия любого "говнокодера", который пол жизни багфиксит
а потом оборачивается, и не видит результат
а результатом кодера должен быть софт(продукт)
а не знания С++ на 30 из 30
Здравствуйте, sergey2b, Вы писали:
S>потом пособеседовался в PCTools и S>выяснилось проценто 30 африканеров возращаються из Австралии домой и я решил не ехать
ЮАР безусловно прикольнее по куче параметров таких как природа, еда, вино, города и т.д... но жить там постоянно с белой рожей не будучу черным как-то сомнительное удовольствие. Каждый день думать не начнут ли резать за не правильный цвет так себе ощущения должны быть. Это я к тому, что не очень понимаю африканеров которые туда возвращаются.
A>>>У спагетти-кода есть большое преимущество — его легко поддерживать даже джуниору. CC>>Шта?
A>Ищет конктерный кусок, исправляет. Задача выполнена. Всё. Не надо разбираться в паттернах, изучать архитектуру. A>Вот, я когда освоил шаблоны С++, прочитал книжку Вандевурда, и минимизировал код, то следующему было сложно. Я вывел в компайл тайм всё, что смог. А я способный. Я думаю, что человек, который это поддерживал, многое бы отдал, чтобы это был просто спагетти код. Ему хотя бы шаблоны учить не пришлось. И разгребать было бы легче.
Ты неверно понимаешь термин "спагетти-код". На самом деле это не простыня кода в виде длинной функции (со свичем или делающей последовательность большого количества операций). Спагетти-код это код, который тронь в одном месте — последствия проявятся в другом совершенно непредсказуемом месте. Аналогия довольно мутная, но примерно такая: представь большую тарелку спагетти в которой одна спегеттина, но настолько длинная, что заполняет тарелку с горкой. Так вот, если ее потянуть в одном месте (любом), то зашевелится вся тарелка в неожиданных местах (потому что они все связаны, но как именно — не видно). Т.е. спагетти-код, это код, у которого много связей с другим кодом (причем, совершенно неожиданных) и если его тронуть, то всплывут ошибки в других частях программы. При этом функции, обычно, тоже длинные, но суть не в размере, а количестве и предсказуемости связей. Длинная простыня — это лишь один из признаков спагетти-кода.
Функция с большим свичем — это нормально. Если в фукнции много последовательных действий — тоже нормально, т.к. с ней можно работать (хотя если разбить ее на более мелкие функции — станет проще понять, что она делает). Аналогия со спагетти — положить ее на тарелку не кучей, а аккуратными витками или другой понятной структурой, чтобы наличие и направление связей прослеживались.
P.S. Кстати, даже спагетти-код это не приговор. Не так давно был ажиотаж по поводу статьи про разработку в Оракле. Там и функции длинные и аргументов у них много и другие антипаттерны в изобилии... Тогда это воспринимали как: "Фуу — бяка". Но на самом деле это про то, что тесты рулят. Потому что весь кода там покрывается огромным количеством тестов в результате чего после внесения любых изменений, добавления новых тестов и исправления ошибок в тестах или самих тестов, код продолжает работать как задумано и возможность дальнейшей разработки также не страдает.
Здравствуйте, Тёмчик, Вы писали:
Тё>Разве? А кто вам, сиплюсплюсникам, разжевывает формулы из научных работ?
Странный вопрос. Научная работа делается учёными, главное достижение — это формулы и алгоритмы. А уж прочитать статью и реализовать — это больше зависит от качества статьи, а не уровня программиста. Тут уж на любом языке.
Другое дело, что в процессе реализации обнаруживается, что результаты статьи не так радужны и рименимы только в очень узкой области. И программисты чаще всего своими силами делают более или менее универсальное решение. Решение описывается также в статье (публикуется она широко или только внутри комании) или оформляется патент. Нормальный такой результат для программиста.
Как оказывает моя практика, Матлабом ограничиться в принципе невозможно, потому что математики имеют слабое представление о том, во что на практике выльются их формулы. Будь то железо (управление устройствами) или просто обработка кучи данных. Поэтому чаще всего работают парами: математик и рограммист, а то и вообще обходятся без математика. Я сейчас говорю не о фундаментальных вещах. Вообще, кажется, что физики полезней математиков, так как лучше онимают суть вещей и умеют ставить грамотные эксерименты.
S>[q] S>Был я относительно недавно на собеседовании (на позицию embedded-программиста), где меня попросили написать аналог tar'a. С лимитом по времени 4 часа. И без Qt, пожалуйста. S>Штош, подумал я, где наша не пропадала? S>1 час я потратил на установку boost'a (не встал, какие-то жэсточайшие ошибки, не было времени дальше копать). S>Еще час я потратил, чтобы узнать, как кроссплатформенно открыть файл и узнать его размер. Кажется, никак, если нет С++17 c std::filesystem. S>Последний час я из спичек и желудей лепил хоть что-нибудь.
Типичный говнокодер в комменте, каких тысячи. Проблема плюсников (не всех, но примазавшихся), что они принииают опыт хождения по граблям плюсов за знания программирования. Есть тру прогеры, которые могут за полчаса на коленке этот аналог tar накидать хоть на плюсах, хоть на си, питоне, ноде и чём угодно. Но их мало.
S>И вот потом я сидел и думал, что же с нами стало.
Лучше бы подумал, как он за 20 лет опыта ничему не научился.
Здравствуйте, sergey2b, Вы писали:
S>linux вообше запилин на Си S>и нечего фатально не течет
Усилиям, которые затрачиваются на повышение качества кода в ядре линукса, стоит найти более достойное применение. Качественно писать на С можно, но дорого.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, sergey2b, Вы писали:
S>>linux вообше запилин на Си S>>и нечего фатально не течет CC>Сколько они это глюкало уже полируют?
$>Imho задачка написать простой аналог tar- весьма годная:
$>1) проверяет, что чувак не только языком чесать модет
$>2) приближенная к реальности бекенда
Хороший у вас бекенд
$>3) не заточенная на какой-то ЯП
Ага. Можно на лиспе в одну строчку записать вообще.
$>4) и ненавязчиво посмотреть, применит ли правильные структуры и алгоритмы, или наговнит
Родной, ты где там структуры и алгоритмы, о которых стоило бы поговорить, нашел?
Здравствуйте, alzt, Вы писали:
A>Ищет конктерный кусок, исправляет.
Ахахаха!
И оно взрывается вообще в неожиданных местах, или просто втихую портит воздух данные. Потому что сия хрень используется из кучи левых мест неочевидным образом — спагетти же, всё знает про всех, всё от всего зависит.
A>Вот, я когда освоил шаблоны С++, прочитал книжку Вандевурда, и минимизировал код, то следующему было сложно. Я вывел в компайл тайм всё, что смог.
А, у нас таких называли "укушенные Александреску".
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Спагетти-код это код, который тронь в одном месте — последствия проявятся в другом совершенно непредсказуемом месте.
Это как раз не про спагетти, это как раз про излишнее увлечение complexity и generic programming, на которые фапают в мире "рассово верного" C++. Это когда у тебя аукается не просто в других участках кода, не просто в других файликах, это когда у тебя аукается на других уровнях абстракции, в других объектах в других пластах. В спагетти отследить почему аукнулось и где аукнулось можно тупо grep-ом. В случае с забористым C++ grep уже не поможет. Нужно разгребать всю эту свёртку шаблонов в то самое спагетти, чтоб потом уже разбирать, где аукнулось и почему аукнулось.
Здравствуйте, Тёмчик, Вы писали:
Тё>На сипипи давно уже никто в здравом уме не начинает проекты. Только лютый кал мамонта, который переписать на жаву дороже, так и мучаются сектанты-мазохисты, пока их вместе с продуктом не выкинут на свалку истории.
Давай скажем честно, у вас почти вся серьезная разработка давно ноги сделала, а та что осталась... тебя туда просто не пускают
Здравствуйте, Тёмчик, Вы писали:
Тё>Давай скажем честно, те проекты, где мы с тобой работали, зачинались в 1995г. Уже в 2007г новые проекты зачинались на более других языках.
Два сложных свежака начали на C++17 за последнии пару месяцев. И именно C++ в этих проектах самое оно. Но там да, это не опердень, это не JS с формочками
Здравствуйте, Тёмчик, Вы писали:
Тё>Каких и почему выбрали C++? Крыша протекла от сидения в карантине, или какие-то обьективные причины? Чем node не подошёл?
А ты как себе представляешь стек автономного автомобиля на Ноде?
Тё>Сейчас на JS и микросервисах распределенных делаем вещи на порядки круче, чем было наивный монолит-копролит C++ в РФ.
Ну UI же опять и всякие перделки, это побоку на чем делать. Представь себе Redis, ClickHouse, Mongo, Tarantul и т.п. на Ноде и всплакни.
Кстати, на Эликсире будет сильно элегантнее и проще в поддержке чем на Ноде.
Здравствуйте, Stanislav V. Zudin, Вы писали:
S>>Или уже успели бухнуть после рабочего дня?
SVZ>Да не, это он так, чтобы срач развести разговор поддержать
Да у меня уже сомнения зародились во вменяемости поциента. Хотелось понять, это уже неотвратимые изменения или же временное под воздействием веществ.
Здравствуйте, Тёмчик, Вы писали:
Тё>Если вы завязались на tensorrt и позиция разработчика tensorrt — педалить на C++, ну педальте на C++. Или сделайте слой и вызывайте из питона. Но с какого перепуга QT? Это ж гуя. Десктоп(!). Ребята, вы там в 1995г застряли что-ли? Веб и облака прошли мимо?
Кстати, не заметил раньше этот твой коммент. Во-первых, Qt — это не только десктоп (хотя и он тоже отлично работает в отличие от js, я уже говорил про отображение карты карту), но и лидер в embedded в automotive. Также как и jetson'ы от Nvidia активно используются как вычислители на конечных устройствах. Так что выбора по факту часто и нет. Мы пишем софт и адаптируем его и под них, и под Интелы — ты почему-то скипнул про OpenVINO кусок. А на чём написан OpenVINO? Как его лучше использовать? Ой, из С++, потому что скорость выше. Нейросети на CPU — это та ещё боль, но не у всех юзеров есть видеокарты, особенно в ноутах. А софт надо делать так, чтобы работал у всех. Вот и поддерживаем самые разные бекенды и под все оптимизируем софт.
Спроси у kaa.python, как они бы отнеслись к тому, что их машина при включённом автопилоте стала бы проезжатть на несколько десятков километров меньше — типа ватты никто не считает и можно их тратить на всё. Короче, добро пожаловать в реальный мир.
Здравствуйте, Nuzhny, Вы писали:
Тё>>Ещё раз. Если питон использовать как клей- ничего там не тормозит. Алгоритмы нужно прокачивать. От того, что ты написал пузырёк на C++ а не на питоне- софт быстрым не станет.
N>Нет, не так. Мы сейчас говорим не про алгоритмы, а про написание софта для решения определённых задач. Типа декодировать видео, подать кадр на вход нейросети, получить результат. Казалось бы всё просто — используй Питон как клей, а всё остальное делают библиотеки. Но внезапно окажется, что на твоём языке-клее кадр декодируется, копируется в оперативную память, потом из YUV конвертируется в RGB, потом он нормируется и раскладывается на слайсы по цветовым каналам. А можно декодировать на GPU, декодированный кадр в YUV не копировать в оперативку и не переводить в RGB, а сразу написать функцию на CUDA, которая оставаясь в пределах видеопамяти сконвертирует во входной тензор из YUV в правильный формат для нейросети. Но такое низкоуровневое API доступно исключительно из C++. Да, мы напишем не 5 строк на Питоне, а 200 строк на С++ (или даже 500 строк на С++ и 100 строк на CUDA), но наш софт будет работать быстро, без фризов, укладываться во все временные рамки и потреблять меньше памяти. И потом также окажется, что наши коптеры летают дольше и при этом ещё и выполняют больше.
Почему упор на "копируется в оперативную память, потом из YUV конвертируется в RGB, потом он нормируется и раскладывается на слайсы по цветовым каналам. А можно декодировать на GPU"? Я же постоянно повторяю- тупо делать на C++, всё равно будет тормозить. Нужно избегать копирования из/в видео память, кроме как когда уже совсем никак. Это же азы программирования графики у игроделов. Вот и использовать питон, чтобы из него заряжать CUDA. Только CUDA imho сейчас не очень- заточено на NVidia. Что там из открытых стандартов сейчас актуально?
N>Это нормальная работа для программиста, ничего особенного и без пузырьковых сортировок при этом.
Я видел кучу плюсников в России, лепящих пузырёк на ровном месте, и считающих себя богами. Ведь они пишут на C++.
N>>>Так выбора нет. Где есть, там на Питончике пишем и не жужжим. Твой js по ссылке — это хрень, прости за откровенность. Мы выводим десяток видео на экран, обрабатываем их шейдерами и рисуем поверх. Твой пример грузит видеокарту на 100% и выдаёт жалких 40 fps. Блин, о таких тормозах я и говорю. Не хочу писать такой галимый софт, на который будут пользователи плеваться. Тё>>Пример что я нагуглил- это шейдеры На моём 4k экране оно упирается в 60fps. Ибо шейдеры загружены в карту, прямо с веб странички. Может, у кого-то карта говно, или браузер ie?
N>Так я и говорю. Будет эксплуататор с дохлым ноутом в поле (а защищённые ноуты все дохлые, потому что сложно сделать нормальную вентиляцию и охлаждение) смотреть на слайд-шоу и проклинать разработчиков. Оно мне надо? Оно надо этим людям, которым и так нелегко? Никому не надо. В кресле с игровым компом под столом можно писать и на js, я не против — пиши.
А предложите вашим "эксплуататорам" воспользоваться айпадом про. И там всё плавненько в вебе полетит- вот будет облом C++ дрочерам.
Здравствуйте, Тёмчик, Вы писали:
Тё>Ну особо упоротые, конечно, и STL в ядро запихивают (реальный случай кстати, чел на полном серьёзе предлагал зафигачить в виндовый драйвер C++ с STL-м).
Как в букварях написано, так и он предлагал делать. C++-ники, те самые, которые считают себя "правильными", вообще на STL молятся как на икону. Ограниченные люди
Здравствуйте, CreatorCray, Вы писали:
Тё>>Ну особо упоротые, конечно, и STL в ядро запихивают (реальный случай кстати, чел на полном серьёзе предлагал зафигачить в виндовый драйвер C++ с STL-м). CC> CC>Виндовые дрова замечательно пишутся на С++, я это лично делал с десяток лет назад.
DJI- лидер в производстве дронов, в томчисле профессиональные с 3/4 сменными линзами. У них софт под ipad. А гос контора обязательно под Шиндоуз делает, чтоб с клавиатурой.
Похоже что ниасилили ios, как и ниасилили за пределы Qt выйти.
Здравствуйте, Тёмчик, Вы писали:
Тё>Предлагаю т.н. экспертам C++ почитать стандарт C++. Вообще, такой степени упоротости у C++ ков в моё время (до 2010г) не было.
Есть ещё C++ и bare metal. Есть многое на свете, друг Горацио...
Здравствуйте, Тёмчик, Вы писали:
SVZ>>А расскажи, будь любезен, чем, по-твоему, "настоящий С++" отличается от "Си с классами"?
Тё>Исключения, динамическая память, шаблоны, весь STL.
Это всего лишь инструменты. Ты можешь их использовать, но не обязан.
Этим с++ и хорош.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, TimurSPB, Вы писали:
S>>на позицию embedded-программиста S>>1 час я потратил на установку boost'a TSP>boost в embedded? Это путь страданий, и ты первый же шаг сделал ещё на собеседовании.
Здравствуйте, Тёмчик, Вы писали:
Тё>Когда мне было актуально, выбил 99% персентиль на тесте C++. Но сектантам, ниасилившим больше одного языка, только и остается попкоболеть.
Что лишний раз доказывает бесполезность подобных тестов: результат у вас отличный, а знания никакие. Не говоря уже про понимание.
смотря что понимать под ембеддедом
если это не esp, где в целом можно но только тем кто умеет
то на армы и прочию чухню легко С++ заходит и с исключением и с стл итд
да и буст если умело готовить то тоже мизер занимает
Здравствуйте, kaa.python, Вы писали:
Тё>>Онлайн текстовый процессор- по-твоему это тоже формошлепство?
KP>А разве нет? Вся или почти вся логика на серверах, рисуете себе на Ангуларах да Реактах контролы
Большая десктопная прилага полностью в html5, феншуйные микросервисы в облаках. И можно пилить и фронт, и бек, выбирай из 50 микросервисов.
А у тебя что? Пилить 1 маленький модуль (считай как 1 микросервис), это элементарно и скучно, никакого челенжа и разнообразия. Секас с костылями C++ я не считаю челленжем- у нормального плюсника всё работает.
Здравствуйте, Тёмчик, Вы писали:
KP>>Я лично занимаюсь прорывными задачами в прорывной области. <b>Детали</b> после 2023, пока никак нельзя рассказать Тё>Ну понятно, надуваешь щёки
У нас в области всё или почти все под NDA. Я не вижу смыслу в его нарушении ради того, что бы Тёмчик снова не понял о чем речь идет и начал про крутость JS вещать
KP>>Ты бы лучше микросервисы на PHP писал Тё>Для микросервисов есть node и go.
Микросервисы — говно. Через лет 5-10 ты это тоже поймешь
Это значит, что если вам потребуется паттерн Observer, то вы сходу затащите в проект самое тяжелое и монстроузное из имеющегося на рынке, но зато модное и молодежное?
Здравствуйте, so5team, Вы писали:
>Т.к. в list-е каждый элемент -- это динамически созданный объект, удаление которого всяко дороже, чем сдвиг нескольких соседей в vector-е.
Если размеры vector-а — миллионы, и это тяжёлые объекты, которые даже мувятся рядом операций копирования, то сколько будет шуршать такой сдвиг?
Здравствуйте, smeeld, Вы писали:
S>Если размеры vector-а — миллионы, и это тяжёлые объекты, которые даже мувятся рядом операций копирования, то сколько будет шуршать такой сдвиг?
Приведенный код — реализация обсервера.
Если подписчиков вдруг ни с того ни с сего — миллионы, то у этого кода есть проблемы посерьезнее стоимости удаления из середины вектора.
Здравствуйте, so5team, Вы писали:
S>Тёмчик, а какое это все имеет отношение к обсуждению уместности применения std::list вместо std::vector?
Блин, так это ж говнокод, что там обсуждать какой сорт говна лучше- через список или массив. Посмотри на реализацию событийной модели здорового человека- может что-нибудь новое для себя узнаешь.
S>Зачем нам шаблоны какого-то Boost-а, если у нас своих полно?
Ну так а я про то, что мазохисты-сектанты с верой, что компилятор C++ из говна O(n*n) сделает ракету.
О чём с фанатиками разговаривать. И конторы плюсные поэтому специфические.
Тё>Небольное количество подписчиков яйца выеденного не стоит. Можете их хоть квадратично перебирать
Грубо говоря, у вас может быть по 2-3 подписчика на каждый условный Button, и 100500 этих самых условных Button-ов.
S>>Это не у меня. Это у человека, который написал пример, приведенный B0FEE664. А тому человеку, возможно (и скорее всего) нужно было в качестве callback-ов использовать чисто сишные функции. А это может потребоваться по разным причинам, начиная от использования легаси-кода и заканчивая интеграцией C++ного кода и кода на каком-нибудь Lua или Python (из которых наружу торчат C-шные интерфейсы). Тё>Про интеграцию с чужим API — почитайте про https://en.wikipedia.org/wiki/Visitor_pattern
Каким боком здесь Visitor?
S>>>>Т.е. вы для хранения списка подписок предлагаете хранить еще и специальный sentinel node? Тё>>>Я не "предлагаю" — это оптимизация связного списка для упрощения его операций, почитайте, учиться ведь всегда полезно.
S>>Так ведь я не про упрощение, а про связанные с этим расходы. Тё>Вот и подумайте про сокращение "C" в формуле C*O(...).
Это вы возьмите и подсчитайте. У вас и так на каждый POD с двумя указателями приходится еще три указателя + MCB + выравнивание. К этому давайте приплюсуем еще и расходы на sentinel node. Получается не так уж и мало для контейнера для нескольких элементов. И если этих самых контейнеров в программе овердофига, то...
А ну да, у TS-еров, как и у JS-еров же память же не ресурс же.
S>>Или он просто хранит у себя указатель на Button и вызывает RemoveOnButtonPress в нужных ему местах. Тё>Блиииин ну это же рафинированный говнокод.
Это зависит. Если подписчик при этом всем еще и оказывается единственным владельцем Button-а, то ему можно об отписках вообще не парится.
S>>>>На словах все герои. Только вот если у вас отписка работает через поиск (по указателю на callback или по какому-то уникальному Id), то она оказывается более устойчивой к подобным ошибкам. Тё>>>Т.е. вы смирились с фактом, что в вашем говнокоде нет определённости, придёт отписка дважды, или вообще не придёт. И поэтому вы городите тормозной кривой код, оправдывая это порно "локальным кэшем".
S>>Мой говнокод, в отличии от вашего идеального, свободно лежит в открытом доступе. И любой желающий может посмотреть и сделать выводы. В отличии от. Тё>Я не обсуждал в этой ветке ваш репозиторий. Сконцентрируйтесь.
Если вы не обсуждаете мой репозиторий и мой код, то вы не можете говорить о моем говнокоде. Моего кода здесь нет. Глаза разуйте.
Тё>>>Возвращается ссылка на интерфейс Subscription. Это может быть наследник от Node имплементирующий Subscription. О каком каком копировании вы поёте?
S>>Тёмчик, мы же про C++ говорим, здесь вы не можете вернуть "интерфейс". Вам нужно возвращать либо экземпляр конкретного класса (и тогда сталкиваться с проблемой копирования экземпляров), либо возвращать (умный) указатель на реализацию интерфейса со всеми вытекающими для этого последствиями.
Тё>https://en.cppreference.com/w/cpp/language/abstract_class
Ну так почитайте сами. Вы не можете создавать экземпляры абстрактных классов. Только конкретных. Соответственно, с абстрактными классами вы можете работать только на уровне ссылок/указателей. И если вы возвращаете ссылку на абстрактный класс, то возникает вопрос: а где живет конкретная реализация и кто контролирует ее время жизни. Отвечая на этот вопрос вы и придете к необходимости возвращать (умный) указатель на реализацию интерфейса.
Здравствуйте, so5team, Вы писали:
S> кто контролирует ее время жизни. Отвечая на этот вопрос вы и придете к необходимости возвращать (умный) указатель на реализацию интерфейса.
unsubscribe() мешает благородному дону удалить instance?
S>Но для этого в C++ немного понимать нужно.
Слушайте, меня конкретно уже разрывает на вашу узколобость в сочетании наскоками на моё знание C++. Вот такие представители профессии и создают негативный стереотип о C++- ках. Это не относится к действительно прокачанным программистам (как Зудин), которые в силу обстоятельств применяют C++ как инструмент.
Здравствуйте, so5team, Вы писали: S>Вы не ответили на вопрос о том, каким боком и зачем бы приплетен паттерн Visitor.
S> тому человеку, возможно (и скорее всего) нужно было в качестве callback-ов использовать чисто сишные функции. А это может потребоваться по разным причинам, начиная от использования легаси-кода и заканчивая интеграцией C++ного кода и кода на каком-нибудь Lua или Python (из которых наружу торчат C-шные интерфейсы).
Почитайте про Visitor, подумайте. S>>> кто контролирует ее время жизни. Отвечая на этот вопрос вы и придете к необходимости возвращать (умный) указатель на реализацию интерфейса. Тё>>unsubscribe() мешает благородному дону удалить instance? S>У меня пока проблема в том, чтобы разобраться с предложенным вами вариантом. Т.е. понять, что это за вариант вообще. S>Пока что вырисовывается приблизительно такая картина:
sentinel иницировать в конструкторе:
sentinel.next = sentinel.prev = sentinel.
Можно ещё поиграться с пре-инициализацией кэша SubscriptionNode как цикличного списка, и чтобы ObservableImpl брал Node оттуда в свой список, а при unsubscribe возвращал обратно. Будет тебе тогда cache locality и избежание динамического выделения памяти:
SubscriptionNode[2048] nodeCache;
S>>>Но для этого в C++ немного понимать нужно. Тё>>Слушайте, меня конкретно уже разрывает на вашу узколобость в сочетании наскоками на моё знание C++. Вот такие представители профессии и создают негативный стереотип о C++- ках. S>
S>-- Этот ваш C++ говно и для разработки реал-тайма не применяется!
S>-- А ты хоть C++ знаешь?
S>-- Да!
S>-- Что такое виртуальный деструктор?
S>-- Какой ты токсичный! Из-за таких как вы и C++ сообщество считается токсичным!
Ну вот для вас виртуальный деструктор- верх сложности? О чём я и говорил: слабость в алгоритмах и религиозная вера в C++. Тё>>Это не относится к действительно прокачанным программистам (как Зудин), которые в силу обстоятельств применяют C++ как инструмент. S>Мне как-то фиолетово, насколько прокачанным вы считаете меня, но таки применяю C++ как инструмент. Т.к. в области интересных для меня задач до недавнего времени широко использовались только C и C++, где-то еще была Ada. Сейчас вот Rust подвезли. Но до настоящего мейнстрима Rust-у еще нужно добираться лет 5.
Я вообще много чем занимался, и нигде из компаний, не являлся C++ рационально обоснованным инструментом. Только исторически или в силу религии.
Здравствуйте, Тёмчик, Вы писали:
Тё>Вы безнадежны .
Безнадежен тут только ты. Ты даже не попытался объяснить, каким боком приведенный кусок кода относится к поставленной задаче. И зачем в нем нужен визитор, а не просто какой-то интерфейс, выполняющий роль колбэка.
Тё>Вы зачем-то пытаетесь притянуть shared_ptr. Зачем?
Тебе вполне популярно объясняли зачем, но ты не понял. В предложенной тобой схеме каждый Subscription должен владеть списком подписок. Иначе список подписок может неожиданно помереть, а подписки об этом даже не узнают.
Тё>Если вы его суете во все дыры, — это ещё не значит, что его нужно сувать во все дыры. И кроме того, даже shared_ptr можно реализовать без разделяемого счётчика на куче. Но вы же этого ничего не знаете.
Да, несомненно, сокровенное знание про make_shared доступно только тебе. И интрузивных поинтеров никто кроме тебя в своей жизни не писал.
Тё>Ещё раз. Когда я писал на C++, ни у кого не было претензий к моему уровню, и максимальные баллы на тестах это подтверждали. Вы же просто сынок в сравнении с нормальным C++ м.
Это прекрасно. Правда, в этом свете не очень понятно, почему ты сейчас демонстрируешь крайне низкий уровень понимания C++. И практически полное отсутствие самокритики.
Тё>RO-данные можно загружать в удобоваримой форме. Но откуда вам знать про это- вы же ничего в структурах данных и алгоритмах не понимаете. Весь интеллект потрачен на хождение по костылям.
Внезапно, чаще всего эта удобоваримая форма как раз и соответствует вектору, unordered map'у или map'у, или их комбинациям. То, что ты этого не знаешь, говорит только о твоем опыте использования C++, и ни о чем больше.
Тё>Только вот ваш уровень можно сравнить не с проктологом, а скорей с ассенизатором.
Откровенное хамство никак не добавляет веса твоим словам.
Здравствуйте, Тёмчик, Вы писали:
S>>Скорее уж тот, кто надувает щеки и не может внятно объяснить, что он имел в виду. Тё>Это вы не можете понять.
Так вы и не пробовали объяснить. Попробуйте, попытка не пытка.
Только вот шансы, что вы вновь обосретесь, но надуете щеки и сделаете вид, что не вы, близки к 100%.
S>>Тем более, что есть серьезные подозрения, что надувание щек в данном случае -- это лишь попытка замять предложение использовать Visitor там, где от него толку нет вообще. Тё>Вы его не умеете готовить. В общем-то, закрадываются сомнения, а что вы можете готовить.
Если вы можете готовить, то что вам мешает показать вменяемый кусок кода? Задача простая, есть C API вот такого вида:
При нажатии на кнопку Ok нужно вызывать somelib_data_on_ready и передать в него указатель, полученный ранее при вызове somelib_data_create. Покажите как, по вашему мнению, здесь может быть применен Visitor.
S>>А там как бы и нет разделяемого счетчика на куче. Тё>Уже нет?
Код посмотрите, тaм все сказано.
Тё>Но почему тогда вы утверждали про выделение на куче под умный указатель?
Цитату можно?
S>>Вопрос только в том, кто был проверяющим для вашего кода. И были ли они вообще. Тё>Мой код был идеален и без review
"Ну и вы говорите, говорите" (c)
Тё>Несколько лет назад на рсдн была эпическая битва вас с вашей библиотекой, и оппонента с чужой библиотекой на Java. Вы тогда тоже упорно ничего не понимали и твердили про превосходство C++, в то время как та жавская библиотека использовалась в матчере на бирже, до таких требований у вас в Бобруйске не дорастут никогда.
Если вы не поленитесь и поднимите этот разговор, то вряд ли найдете там утверждения про превосходство C++. И да, если наша библиотека под рилтайм не заточена, то какой смысл ее сравнивать с тем, что под конкретный сценарий использования затачивалось (речь про Distruptor) мне лично непонятен.
S>>Речь не идет про RO-данные, актитесь. Тё>У вас данные, к которым вам нужно обращаться в процессе работы, ещё и изменяются?
При необходимости. Конечно же.
Тё>В ядре?
Тёмчик, мы про реальное время говорим, не про ядро. Одно к другому не относится.
Тё>C аллокаторами и т.д. Да вы бредите.
Зачем для изменения данных нужны аллокаторы?
Тё>Юноша, я кодил C++ и скрещивал с другими языками, ещё когда вы в первый класс ходили.
Тёмчик, вам же лет около 40? Не слишком ли вы молоды, чтобы незнакомых людей юношами называть?
Здравствуйте, so5team, Вы писали:
L>>Что касается структур данных, то тут можно вспомнить классическое "правило" 80/20: >80% кейсов покрываются именно векторами, хеш-мапами и упорядоченными мапами. S>Золотые слова. Вот прям спасибо.
Кстати, добавлю — недавно понадобилось иметь std::map или std::set, который заполняются лишь однажды и потом почти никогда не модифицируются, но в котором нужно очень иногда искать по ключу, но постоянно приходится просто итерировать.
В закромах буста обнаружился flat_map и flat_set. Вот прям что надо было.
Здравствуйте, landerhigh, Вы писали:
L>>>Что касается структур данных, то тут можно вспомнить классическое "правило" 80/20: >80% кейсов покрываются именно векторами, хеш-мапами и упорядоченными мапами. S>>Золотые слова. Вот прям спасибо.
Просто состим и ты нихрена не понимаете в алгоритмах. А потом ещё обижаетесь на мою формулировку "не понимают в алгоритмах, но мастурбируют на шаблоны".
L>Кстати, добавлю — недавно понадобилось иметь std::map или std::set, который заполняются лишь однажды и потом почти никогда не модифицируются, но в котором нужно очень иногда искать по ключу, но постоянно приходится просто итерировать. L>В закромах буста обнаружился flat_map и flat_set. Вот прям что надо было.
flat_map is similar to std::map but it's implemented like an ordered vector.
Здравствуйте, Тёмчик, Вы писали:
L>>Тема, ты так и не понял, почему для "можно итерировать" вектор предпочтительнее. L>> Тё>Да знаю, сейчас будут страшные слова "cache locality", которые ты не сможешь подтвердить результатами профайлера, например.
Здравствуйте, Тёмчик, Вы писали:
Тё>>>Что я не бегаю с безумными глазами и не твержу "С++ всех быстрее"?
S>>Покажите C++ников в этой теме, которые бы твердили "C++ всех быстрее". С ссылками и цитатами. Тё>Вы сами твердили в споре про sentinel node и демонстрировали непонимание предмета.
Если я это твердил, то вам не составит труда дать ссылку на конкретную цитату.
Тё>А когда я предложил решение на ёлку залезть (O(1)) и непоцарапаться (cache locality), вы перешли на оскорбления.
Было предложение хранить ноды в преаллоцированном векторе фиксированного размера. За такое сразу в сад. Ибо если есть возможность заранее предсказать количество подписок, то пляски с динамическими контейнерами не нужны.
Тё>Это только в том случае, что интервью успешно пройдено. Я вас уверяю- с вашими познаниями алгоритмов и претензиями на превосходство в профессионализме, вы бы не прошли интервью.
У вас не прошел бы. В этом даже никаких сомнений нет. Равно как и контора, в которой меня собеседовали бы вы, упала бы в моих глазах ниже плинтуса. Ибо просьба обратить строку от чайника, который не в курсе, какие способы представления строк встречаются в природе, она о многом говорит. О многом плохом, касающемся конторы.
S>>Тёмчик, еще раз: у некоторых из тех, кого вы называете "не знающими алгоритмы плюсодрочерами" в OpenSource десятки тысяч строк код. Тё>Мне неинтересно читать ваш отлаженный код.
Тогда закройте рот и не звиздите о чужой квалификации. Если вам что-то кажется, то ноги в руки и бегом в религиозное заведение. А если рот публично открываете и пытаетесь на кого-то наезжать, то потрудитесь свои наезды аргументировать.
Когда вы здесь просили отревьювить ваш код, то вам высказали предметные замечания. Из которых как раз таки ваш уровень стал понятен.
Тё>Вы докопались к синтаксису шаблонов, в то время как синтаксис быстро забывается, но вернуться к языку я могу в любой момент. Это как кататься на велосипеде.
Тёмчик, я не докапывался к синтаксису шаблонов. Я указал на то, как должны инициализироваться члены класса. И на то, что вы, не зная, как это делается должным образом, не владеете инструментом, о применимости которого делаете здесь громкие заявления. Т.е. откровенно звиздите о том, в чем не разбираетесь.
В этом камень преткновения. А не в том, что какие-то мифические сиплюспоюсники в вакууме свято верят в самый быстрый на свете C++.
Здравствуйте, netch80, Вы писали:
L>>Это ты Теме расскажи.
N>Я плохо слежу за столь специфическим языком треда, но вроде он что-то похожее как раз и говорит?
Нет, он упорно пытается всем навязывать те структуры, которые являются правильными с его точки зрения (по big-O). То есть, в данном случае хэштаблицы или комбинацию из хэштаблицы и интрузивного списка (aka LinkedHashMap в яве).
Здравствуйте, Тёмчик, Вы писали:
Тё>>>Вы из тупого сплита сделали проблему века.
S>>Скорее вы просто не в курсе. На обычных собеседованиях о таком не спрашивают.
Тё>Это не отменяёт тупого сплита, который вы переусложнили.
Чтобы делать выводы о "переусложнили" или "недоусложнили" следует быть в теме. А вы не.
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, netch80, Вы писали:
N>>Видите ли, Тёмчик... вы не пробовали и даже не пытались. Если бы попытались, то поняли бы, в чём проблема. Тё>Я не пробовал и не пытался писать парсеры к фидам сообщений с бирж и брокеров, много лет. Много их форматов, все не вспомнить.
Ну расскажите про какой-нибудь с аналогичной проблемой. На всякий случай: с FIX я работал.
N>>Ахо с компанией — "книга дракона" — это, конечно, стильно (толстый том полный странных букв... нет, я его читал). Тё>Читать вы её может быть, читали, но ничего не поняли.
Не поняли её как раз вы — судя по вашим прогонам про "поток лексем из парсера" и "тривиальные автоматы".
Жаль, я надеялся на конструктивное обсуждение.
Здравствуйте, Lexey, Вы писали:
BFE>>Только вот при вызове Button::RemoveOnButtonPress() внутри callback'а скорее всего получится segmentation fault или другое UB: ведь в момент вызова callback'а внутри прохода std::for_each будет удалён объект на который указывает текущий итератор.
L>Это легко обходится через копирование колбэков во временный контейнер и вызов for_each поверх него. Это довольно стандартное решение для ситуаций, когда возможны описки из колбэков.
С простым копированием не так все просто: RemoveOnButtonPress может вызываться не только для удаления текущего обработчика, но и для любого другого. В том числе и для тех обработчиков, до которых внутри for_each-а пока не дошли. Если for_each будет идти по временному контейнеру, то получится, что во временном контейнере останется обработчик, который уже изъят из основного. И будет вызван. Что может сильно удивить пользователя, который этот обработчик только что изъял.
Тут нужна более хитрая схема. Например, с дополнительным флагом valid/invalid для каждой подписки. Если подписка удаляется в момент публикации (т.е. внутри for_each-а), то физически она не удаляется, а флаг для нее меняется на invalid (+ еще взводится отдельный флаг, который показывает, что список подписок изменился). Перед вызовом подписчика проверяется флаг для него. Если valid, то вызывается. Если invalid, то пропускается. После выхода из for_each-а публикации проверяется общий флаг наличия изменений в списке. Если изменения есть, то идет еще один цикл с изъятием всех invalid подписок.
А если добавить сюда еще и возможность вызова AddOnButtonPress в момент публикации, то ситуация становится еще интереснее. И, возможно, использование std::list вместо std::vector в таких условиях более оправдано, не смотря на все недостатки std::list-а.
Здравствуйте, Тёмчик, Вы писали:
S>>Тем более, что есть серьезные подозрения, что надувание щек в данном случае -- это лишь попытка замять предложение использовать Visitor там, где от него толку нет вообще. Тё>Вы его не умеете готовить. В общем-то, закрадываются сомнения, а что вы можете готовить.
Наверное я понял, причем здесь Visitor. Вы же кроме Visitor-а ничего-то и не знаете. А про сам Visitor, узнали всего лишь несколько лет назад: http://rsdn.org/forum/job/7263272.1
проходя собеседование в контору, в которую вас не взяли из-за проваленного тестового задания. Проваленного, скорее всего, из-за плохого владения плюсами (как выяснилось здесь: http://rsdn.org/forum/job/7262279
Да и озвученный два года назад вопрос все еще остается очень актуальным: "Как? Как можно много лет программировать на C++ и Java и узнать про Visitor только в 2016-ом?"
А зачем ты какую-то левую реализацию выбрал, а не ту, что на странице?
Node js 11.89с
C++ g++ 8.08с
но по памяти в ~30 раз хуже!
Node js 61,216
C++ g++ 1,900
А таки память еще ресурс в ряде случаев. Твое приложение, которое только на 8 гигах стартует как бы на это намекает тебе.
Тё>И в чём моя деградация? Что я не бегаю с безумными глазами и не твержу "С++ всех быстрее"?
Ну к примеру ты забыл что память это ресурс, все проблемы пытаешь свести в КА и приложению на JS. Мир богаче сильно и разнообразнее.
Тё>Квалификацию этих людей можно проверить на интервью. Пока что у меня большие сомнения в квалификации не знающих алгоритмы плюсодрочеров.
На интервью можно проверить только то, как хорошо человек подготовился к интервью. Вроде это очевидно
я в душе вегда был приверженцем Паскаля
но перешел на Си С++ тк повзояет решить практическую задачу и работает практически под всеми ОС
те на нем можно что угодно напедалить
я бы сказал С++ привлекает людей которым нравиться возиться с железом
или решать ресурсоемкие задачи
Здравствуйте, sergey2b, Вы писали:
S>Здравствуйте, reversecode, Вы писали:
R>>вообще это стадия любого "говнокодера", который пол жизни багфиксит R>>а потом оборачивается, и не видит результат R>>а результатом кодера должен быть софт(продукт) R>>а не знания С++ на 30 из 30
S>согласен, S>и какие есть варианты как уйти из багфикса на С/С++ ?
LVV>>А модулей нормальных нет до сих пор... DO>Валерий Викторович, а у вас есть видение как должны быть реализованы модули в С++, их место, возможности и какие задачи они призваны решать? Ну вот чтобы по пунктам. Может статью запилите?
Естественно, есть. Я ж старый виртовец... В орле регулярно встречаемся.
Гуткнехт приезжал, рассказывал последние их работы — очень интересно!
Посмотрите в сети День Оберона 2-18.
Более того, мы сделали же свой язык для обучения и за образец взяли модули Компонентного паскаля в системе BlackBox.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, sergey2b, Вы писали:
S>я в душе вегда был приверженцем Паскаля
...я также, но четверть века назад...
S>но перешел на Си С++ тк повзояет решить практическую задачу и работает практически под всеми ОС S>те на нем можно что угодно напедалить
+100500
S>я бы сказал С++ привлекает людей которым нравиться возиться с железом S>или решать ресурсоемкие задачи
Да, примерно так и получается. Хотя вот уже порядка 17 лет владею .NET-ом, но заниматься на С++ мне интереснее.
Здравствуйте, Тёмчик, Вы писали:
Тё>Когда мне было актуально, выбил 99% персентиль на тесте C++. Но сектантам, ниасилившим больше одного языка, только и остается попкоболеть.
Потому что люди чаще всего выбирают не столько язык, сколько предметную область. В твоей области С++ был плох, поэтому ты от него и ушёл. И это нормально, ведь даже матёрые сиплюсплюсники для задач GUI выбирают не С++, а другой язык: Qt Widgets -> QML. Это нормально. Не нормально, что ты превратился в кулика и хвалишь исключительно своё болото (это не только про ЯП). но что поделаешь.
Хорошее видео про то, почему С++ так неудобен для многих задач есть у Антона Полухина. Вкратце идея: в комитете сидят люди из довольно узкой области (в основном связанной с быстродействием), которые имеют ограниченное представление о рутинных задачах программистов из остальных областей и почти ничего для них не делают. Типа надо быть ближе к народу, а не обетать на снежных вершинах в безвоздушном пространстве альпинистов-одиночек.
Общее резюме — не уходить в зону комфорта: ни в лёгкую, ни в сложную.
Здравствуйте, _ABC_, Вы писали:
KP>>В АУ на столько все плохо с работой? _AB>Смотря с какой... Но в целом — что ты хочешь от деревни размером с континент?
Деревни разные бывают. Есть какая-нибудь Ирландия с кучей R&D, есть Сингапур где тоже куча R&D. А вот ситуация с Австралией выглядит непонятно, есть ощущение (я туда в конце 2000-х думал понаехать, к счастью не вышло) что раньше там было с R&D сильно лучше.
_AB>А что Артём?
В конце 2000-х, когда мы в Инфотексе работали, он был реально хороший С++ разработчик, сильно выше среднего. А сейчас, может по причини сложности с поиском хорошей работы в АУ, что вынуждает корпеть над примитивом в виде JS, пишет странные вещи
_AB> Всем не дано быть супер-профи. Основа профессии — середняки разной степени вменяемости типа меня или Артёма.
А ты так вообще прибедняешься. Разве не тебя на позицию архитектора (или около того) в Австралию перевезли? Ну так это 99% перцентиль, а не середнячок.
Здравствуйте, vfedosov, Вы писали:
V>Не знаю как сейчас в РФ, а в Германии вакансий С/C++ больше чем на джаву, по моей оценке. Причем половина проектов практически с нуля. Просто в РФ ничего в плане железа не производится и отсюда специфика рынка. Но это далеко не везде так. И шансов получить интересную задачу (со сложной алгоритмикой и т.д.) на плюсах в Германии гораздо больше, чем на джаве.
В Германии же автопром и промпроизводство. Там всегда люди с "железным" опытом нужны. Но там денег мало и немцы. В Штатах многие крупные конторы движутся в сторону своего проприетарного оборудования, потому что для гугла или фейсбука свой чип разработать — копейки, а экономия в пару процентов с учётом их масштабов — хорошо. Нужны эти проценты — С++ без вариатнов. Зачастую даже Си с классами, потому что последнюю каплю из железа будут выжимать узкие специалисты, которые в программирование не очень, зато все значимые публикации IEEE/AMS по своей теме за последние десять лет наизусть помнят.
Здравствуйте, El Camino Real, Вы писали:
ECR>Здравствуйте, vfedosov, Вы писали:
V>>Не знаю как сейчас в РФ, а в Германии вакансий С/C++ больше чем на джаву, по моей оценке. Причем половина проектов практически с нуля. Просто в РФ ничего в плане железа не производится и отсюда специфика рынка. Но это далеко не везде так. И шансов получить интересную задачу (со сложной алгоритмикой и т.д.) на плюсах в Германии гораздо больше, чем на джаве. ECR>В Германии же автопром и промпроизводство. Там всегда люди с "железным" опытом нужны. Но там денег мало и немцы. В Штатах многие крупные конторы движутся в сторону своего проприетарного оборудования, потому что для гугла или фейсбука свой чип разработать — копейки, а экономия в пару процентов с учётом их масштабов — хорошо. Нужны эти проценты — С++ без вариатнов. Зачастую даже Си с классами, потому что последнюю каплю из железа будут выжимать узкие специалисты, которые в программирование не очень, зато все значимые публикации IEEE/AMS по своей теме за последние десять лет наизусть помнят.
помоему попрежнему больше вакансий на Java and Net and Python
но за последнии два года точно стало больше вакансий на С++, у нас MS в соседнем поселке открыла оффис
обычно они хотят знание одного из языков, а тут прямо пишут строго С С++ + linux
Здравствуйте, Тёмчик, Вы писали:
SVZ>>Вообще-то с++ для программирования ПЛИСов используется с незапамятных времен. Просто ты не в теме. Тё>Кидай ссылки. У меня одногрупник в этой теме, правда оч давно не общался- так вот он ничего про C++ не говорил. У него какие-софтины были на десятки тыс $$ где оно проектировалось.
Ключевое слово CatapultC.
Десятки килобаксов это обычные цены в проектировании электроники. Есть софт и подороже.
SVZ>>Мы (сиплюплюсники) как раз делаем библиотеки для матлаба. Весь рокет саенс внутри. А матлаб это клей, как и питон. Тё>Разве? А кто вам, сиплюсплюсникам, разжевывает формулы из научных работ?
Вообще-то это мы делаем — и научные работы, и алгоритмы, и код. Электродинамикой занимаемся.
Тё>Или всё сами, но тогда непонятна бомбежка отдельных представителей профессии на элементарные лёгкие вопросы на собеседовании.
Я за "отдельных преставителей профессии" не отвечаю. У меня на собеседованиях проблем нет.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Максим, Вы писали:
М>В С++ считается хорошем стилем все поля класса инициализировать через списки инициализации? Добавил поле — автоматически добавил : m_value(a_value) во все конструкторы?
Да. К счастью, начиная с C++11 дефолтными значениями можно инициализировать прямо по месту объявления поля. И в C++11 делегирующие конструкторы позволяют уменьшить количество мест в самих конструкторах, где нужно что-то инициализировать явно.
Неинициализированные поля можно оставлять только по показаниям профайлера.
М>Просто присваивания в теле конструктора считаются более error prone?
Здравствуйте, sergey2b, Вы писали:
S>на 10 лет меньше чем винду
Откуда 10 то?
Linux initial release date: September 17, 1991
Windows initial release date: November 20, 1985
И да, винда уже в 2000м была весьма юзабельная
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, sergey2b, Вы писали:
S>>на 10 лет меньше чем винду CC>Откуда 10 то? CC>Linux initial release date: September 17, 1991 CC>Windows initial release date: November 20, 1985
я почему то думал что linux отрелизился в 93
хорошо 6 лет разницы
CC>И да, винда уже в 2000м была весьма юзабельная
так первая версия винды писалась на pascal поэтому там код был более структуированный
NT 3.51 была уже вполне нормальной
S>на позицию embedded-программиста S>1 час я потратил на установку boost'a
boost в embedded? Это путь страданий, и ты первый же шаг сделал ещё на собеседовании.
Здравствуйте, sergey2b, Вы писали:
S>я бы сказал С++ привлекает людей которым нравиться возиться с железом S>или решать ресурсоемкие задачи
Ну я на всех не обобщал. В C++ полно кода, который просто работает и делает свою задачу. Я вот в Qt когда-то возился, в его исходниках в том числе. Всё там приятно и понятно написано. Но, уверен, идеалистам он не по вкусу. Исключения не используются, код не exception-safe, шаблоны только для классов-коллекций и вообще вместо STL свои классы, сигналы на генераторе кода, хотя можно было бы навернуть на шаблончиках и всего делов. Везде поганое наследование с виртуальными методами вместо статического полиморфизма на шаблонах. Уух, дряной фреймворк.
PS это про Qt 4 примерно 15-летней давности, с тех пор может и туда пробрались шаблонисты.
Здравствуйте, Sealcon190, Вы писали:
S>А вообще, граждане, имеющие настолько мало самоуважения, чтобы после 17 лет опыта писать тестовые задания, должны страдать.
Какой на фиг КСВ?
лет 17, это почти две трети моей жизни
Чуваку 25, у него еще юношеский максимализм не прошел.
Здравствуйте, кубик, Вы писали:
К>Привет, К>Прочел что чел программировал 17 лет что составляет 2/3 его жизни и что он устал. Он еще статьи какие то читает по С++ (во странный...) К>Дальше я читать поленился. К>Я так думаю что С++ тут не причем, может человек влюбился, авитаминоз, может просто он не видит результатьов своего труда...
17 лет, 2/3 жизни — молодой пацан, возомнивший себя убеленым сединами мудрецом. Жениться ему надо.
Здравствуйте, landerhigh, Вы писали:
L>Тест на позицию по embedded? Какой в пень tar, там либо биты памяти нужно уметь экономить с антикварным-С-компилятором, либо модули ядра линукса писать.
QNX же embedded, в вики пишут
In January 2017, QNX announced the upcoming release of its SDP 7.0, with support for Intel and ARM 32- and 64-bit platforms, and support for C++14; it was released in March 2017
Здравствуйте, T4r4sB, Вы писали:
TB>А что, не так разве?
Ну так напиши как в ++03 за полчаса, только ограничь множество типов, для которых собираешься его инстанциировать Никто ж не мешает, сейчас это вполне себе можно. Просто к библиотечным контейнерам теперь несколько другие требования, а более общий код получается сложнее.
Здравствуйте, vsb, Вы писали:
vsb>Ну я на всех не обобщал. В C++ полно кода, который просто работает и делает свою задачу. Я вот в Qt когда-то возился, в его исходниках в том числе. Всё там приятно и понятно написано. Но, уверен, идеалистам он не по вкусу. Исключения не используются, код не exception-safe, шаблоны только для классов-коллекций и вообще вместо STL свои классы, сигналы на генераторе кода, хотя можно было бы навернуть на шаблончиках и всего делов. Везде поганое наследование с виртуальными методами вместо статического полиморфизма на шаблонах. Уух, дряной фреймворк.
vsb>PS это про Qt 4 примерно 15-летней давности, с тех пор может и туда пробрались шаблонисты.
Нормальные C++-программисты понимают, что язык поддерживает несколько парадигм разработки, а не пытаются всем навязывать только одну какую-то <правильную>. Поэтому нормальный C++-программист не будет считать Qt дрянным фреймворком за избранную в нем парадигму, так же как не будет таковым считать метапрограммно-ориентированный какой-нибудь boost::hana.
Кроме того, вот для этого: vsb>Исключения не используются, код не exception-safe, сигналы на генераторе кода, хотя можно было бы навернуть на шаблончиках и всего делов
были вполне определенные *исторические* причины, а не идеологические или еще какие-то. В оправданном применении инструмента нет ничего плохого, даже если он лично вам не нравится.
Вы в своем категоричном неприятии тех же исключений не сильно-то отличаетесь о тех, кто везде и всюду пихает шаблоно-код, уместен он или нет.
Вы только вдумайтесь — ДВА креста.
У человека обычно по жизни — один крест.
Что при жизни свой крест несет, что потом на кладбище.
Два креста — это чтоб наверняка, чтоб уже зарыли и не откопали...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Вы только вдумайтесь — ДВА креста. LVV>У человека обычно по жизни — один крест. LVV>Что при жизни свой крест несет, что потом на кладбище. LVV>Два креста — это чтоб наверняка, чтоб уже зарыли и не откопали...
Мда...
Кто то в жизни видит плюсы а кто то — кресты.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, landerhigh, Вы писали:
L>Родной, у нормального инженера просьба переизобрести колесо вызывает лишь один вопрос — "зачем"? Подобные тесты как раз отсеивают опытных инженеров. L>Студент-то сходу напишет. Что скажут, то и напишет. Скажут написать tar, напишет tar. Вон, недавно одних таких попросили написать MCAS. Написали MCAS и лишних вопросов не задали. Инженер, которых задавал кучу лишних вопросов, уволен, проект сдан вовремя, заказчик щаслив, акционеры рукоплескают. Oh wait...
Инженер — да, это его обязанность (задавать вопросы). Если инженера уволили за то, что он работал — ССЗБ, что тут ещё сказать.
С программистами ситуация немного иная: если тебе поставили ТЗ — будь добр, РЕШАЙ. Человек, который занимается не своим делом, во-первых, вносит хаос в поставленный процесс разработки, а во-вторых не занимается своим делом (ибо занят производством хаоса).
L>Еще крайне вероятен такой момент — опытный сеньер уже не раз погорел на "нам нужно быстренько прототип, чисто для тестов" или "самая простейшая реализация, код все равно на выброс", поэтому ищет подвоха во всем. Типа сегодня утром был tar, а завтра оказывается, что он должен быть клиент-серверным с репликацией и availability 99.9999%, масштабированием и произвольным доступом.
Обычно я горел на том, что самая простая реализация (временная, для тестов...), сделанная на скорую руку, потом юзалась годами обрастая мясом, и превращаясь в монстра, суперкомбайн, который умеет много и одновременно непонятно что, одним своим видом лишая надежды в нём разобраться тех, кто туда сунул нос впервые.
Первое, о чём нужно помнить, создавая новый солюшн — нет ничего более постоянного, чем временное. Эту мантру нужно повторить трижды, прежде чем создавать вот такой новый проект — иначе это начало новой большой беды.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, LaptevVV, Вы писали:
vsb>>Просто С++ приманивает некий определённый тип программистов, которых я называю метапрограммистами (и к которым сам отношусь, и от этого отношения пытаюсь избавиться). Это люди, которые не хотят решать задачу заказчика, они хотят писать код, который будет писать код', причём этот процесс должен им доставлять максимальное интеллектуальное удовольствие. Причём что должен делать этот код', написанный кодом, не так важно. Теоретически он должен делать то, что хочет заказчик, практически он может это делать, он может делать гораздо больше или он может делать гораздо меньше. LVV>Комитет по стандартизации — все такие!
Вы похоже путаете правительство, которое на другой планете, с людьми из комитета. Вся информация по его работе находится в открытом доступе. Есть даже рабочая группа на русском языке https://stdcpp.ru
LVV>Они каждый следующий наворот — для себя, любимых!
У вас тоже есть шанс сделать какой-нибудь наворот, предложение к стандарту С++ может написать каждый, см. ссылку выше
LVV>А модулей нормальных нет до сих пор... LVV>Которые Вирт еще в Модуле сделал... И в ТурбоПаскале они были...
Ну так напишите очередное предложение, может быть оно окажется лучше предыдущих. Я вот собираюсь поэкспериментировать с модулями, которые войдут в С++20
Или пишите на Модуле, ТурбоПаскале. Хотя, погодите-ка.., сейчас требуются только Кобол-программисты.
Здравствуйте, landerhigh, Вы писали:
L>Давай так — создаем чат в зуме. И ты пишешь тар за полчаса четыре часа неспешного тайпанья
Ты формат этого тара видел ? Он же тупой как бревно. Особенно обязательный размер блока в 512 байт. Что-то там ещё было, от чего хотелось разбить себе лицо рукой. Именно от тупости, не от сложности.
Что тебя пугает в нём, расскажи.
Какие-то сомнения могут вызывать только замшелые древние поля, особенно если их использование перекрывается в разных стандартах.
Но упаковывать файлы / распаковывать существующие это не мешает, можно просто заигнорить.
Здравствуйте, landerhigh, Вы писали:
L>Давай так — создаем чат в зуме и ты пишешь за четыре часа решение в онлайне.
Экий ты упорный.
L>Ты как маленький. Подобные "задачи" — отличная возможность слить кандидата. Докопаться можно до всего.
Если на интервью до тебя докапываются то контора не прошла собеседование, работать там не стоит.
Собеседование то в обе стороны работает: они смотрят на тебя, ты смотришь на них.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, landerhigh, Вы писали:
L>>>Давай так — создаем чат в зуме и ты пишешь за четыре часа решение в онлайне. CC>>Экий ты упорный. L>Я тебя за язык не тянул.
Я никому не предлагал устроить демонстрацию. Это у тебя с какого то перепугу случился приступ "а ты докажи!", причём забесплатно, в отличие от пройденного собеседования.
L>Звонят, обещают золотые горы и кучу ништяков. Вроде интересно. Первое собеседование, второе, третье, все в экстазе и тут тебе подсовывают такую маленькую последнюю формальность.
У меня в качестве последней маленькой формальности было побеседовать с боссом босса моего менеджера. Все задачки кончились на первых двух собеседованиях.
Так что да, это плохой звоночек и "спасибо что предупредили" до того как ты уволился с предыдущей работы.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, PM, Вы писали:
PM>>>Вы не могли бы привести пример, когда в С++03 было проще, а в С++11 стало сложнее? Ну или от С++11 к С++14?
Z>>Сколько синтаксических способов создать объект в C++03, а сколько в C++11? PM>Не помню, кажется больше 20.
Вообще-то это были риторические вопросы...
Z>>А эти прекрасные rvalue/glvalue/prvalue/lvalue/xvalue это ведь конечно Z>>чудесное упрощение относительно C++03? PM>Если вам нужен этот новый механизм, тут уж ничего не поделать — придется разбираться как оно работает. Собственно, как и с остальными частями языка, которые вы хотите использовать. Но возможность писать в стиле С++03 никуда не делась, вы по прежнему можете иметь базовое представление о lvalue/rvalue и копировать объекты вместо перемещения.
Вообще-то эти "чудесные" возможности были и в c++03, неужели вы думаете что до C++11 все были
настолько тупые что копировали объекты на каждый чих и только по приходу гениев из комитета,
все прозрели и осознали что можно оказывается не копировать объекты?
PM>Может быть вы бы могли бы привести пример кода, который в С++03 выглядит проще и понятнее, а в С++11 стал сложнее? Ну или от С++11 к С++14, С++17?
Так я же привел кучу примеров.
И по-моему очевидно что я прав и C++ с каждым стандартом становиться сложнее,
а как иначе если сохраняется обратная совместимость и новые конструкции только
прибавляются?
Но если вы так настаиваете давайте конкретику. Обличим мои риторические вопросы
в конкретный код.
Возьмем код состоящий из реализации аналога std::vector, назовем его V.
и строчки кода "двигающей" один экзампляр V в другой.
В C++03: это было реализация: V и строчка типа:
a.swap(b);
b потом выходит из области видимости
В C++11 прибавилось:
1. V(V&&), V& operator=(V&&)
2. Появилось две возможности на выбор:
a = std::move(b);
или старый вариант:
a.swap(b);
Итого кода стало больше, то есть программа сложнее, плюс одно и тоже действие
можно записать двумя способами, это ли не усложнение?
Здравствуйте, Zhendos, Вы писали:
Z>В C++11 прибавилось:
Z>1. V(V&&), V& operator=(V&&) Z>2. Появилось две возможности на выбор: Z>
Z>a = std::move(b);
Z>
Z>или старый вариант: Z>
Z>a.swap(b);
Z>
Z>Итого кода стало больше, то есть программа сложнее, плюс одно и тоже действие Z>можно записать двумя способами, это ли не усложнение?
Это нифига не эквивалентный код. Объект подвергшийся операции std::move находится в валидном но неспецифируемом состоянии. То-есть, он может быть каким угодно.
Здравствуйте, CreatorCray, Вы писали:
A>>У спагетти-кода есть большое преимущество — его легко поддерживать даже джуниору. CC>Шта?
Ищет конктерный кусок, исправляет. Задача выполнена. Всё. Не надо разбираться в паттернах, изучать архитектуру.
Вот, я когда освоил шаблоны С++, прочитал книжку Вандевурда, и минимизировал код, то следующему было сложно. Я вывел в компайл тайм всё, что смог. А я способный. Я думаю, что человек, который это поддерживал, многое бы отдал, чтобы это был просто спагетти код. Ему хотя бы шаблоны учить не пришлось. И разгребать было бы легче.
Здравствуйте, _Artem_, Вы писали:
_A_>Это нифига не эквивалентный код. Объект подвергшийся операции std::move находится в валидном но неспецифируемом состоянии. То-есть, он может быть каким угодно.
Ого. И они ещё плакали, но продолжали стрелять в ногу.
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, уважаемый Zhendos, Вы писали:
Z>>Раньше это не могло быть проблемой. Раз код Z>>скомпилировался, значит все ОК, либо функцию принимала по значению, Z>>ли по ссылке и все с вызовом хорошо. А теперь она может принимать по значению Z>>и нам больше не нужна "v", поэтому здесь ошибка и надо было "std::move(v)". AG> AG>Что же мешало сделать две перегруженные функции: AG>1) аргумент типа константной ссылки AG>2) аргумент типа rvalue AG>тогда: хочешь сэкономить память — бери функцию с аргументом типа rvalue AG>но если не хочешь — просто передай "v" (всё будет работать без ошибки).
И как все это поможет? Я говорю о чтении кода. То есть читаешь:
V v;
f(v);
и не понимаешь что происходит, есть здесь проблемы с производительностью или нет.
Нужно перейти к определению "f", а здесь какая разница будет ли она overload,
или одна, и так станет все понятно. А если таких вызовов и функций много,
то и в IDE это превращается весьма в неудобное занятие, а уж если это code-review в web.
Z>>И это общая проблема C++11/14/17 и т.д., так как сохраняется обратная совместимость, Z>>мы получаем все большую совершенно не нужную нагрузку на программиста, Z>>который мог бы подумать о чем-нибудь еще — типа выбора более оптимального алгоритма, AG> AG>Синтаксис C++11/14/17 — вспонишь за секунды, а новый алгоритм или архитектуру — будешь продумывать не один день.
А причем здесь "вспомнить синтаксис"? Запомнить что есть еще и "enum class",
в дополнение к обычному "enum" это действительно секунды и один раз,
а вот проблемы которые породило это разделение приходится расхлебывать для каждого
enum в своей кодовой базе и во всех сторонних библиотеках которые используешь.
И конечно сложно запомнить какой же вид enum для этих сотен тысяч enum.
И все это конечно отвлекает каждый раз когда пишешь алгоритм, правишь его,
пишешь тесты и т.д. и т.п.
Z>>ок, нам пришла переменная типа Color, я знаю что это enum, Z>>и мне нужно проверить красный ли цвет, как мне это написать? Z>>color == RED или color == Color::RED, Z>>ведь теперь знания что тип enum не достаточно, нужно знать Z>>это enum или enum class. AG> AG>Использую (последнюю пятилетку) enum class — нет нигде никаких проблем.
Если бы это все так просто решалось, например в Qt "5.последняя версия"
есть куча "enum" и куча "enum class".
Z>>Или я объявил новый класс, теперь кроме собственно нужных функций, Z>>типа конструктора для создания экземпляра и методов нужно подумать еще Z>>о пяти сервисных членов класса, вместо трех. Объявлять их default/delete, Z>>писать руками и т.п. AG> AG>Зачем эти усложнения? AG>Компилятор всё правильно воспримет и без этих лишних телодвижений.
Ну стандарт C++ с вами не согласен, если например объявлен `Foo &operator=(const Foo&)`,
то не будет "Implicitly-declared move assignment operator".
Z>>>>Итого кода стало больше, то есть программа сложнее, плюс одно и тоже действие Z>>>>можно записать двумя способами, это ли не усложнение? AG> AG>Одно и то же действие несколькими способоми — это есть даже в старом добром Си AG>Страшного здесь ничего нет (и быть не может).
Конечно есть, даром что ли пишут "coding style" и в которых речь идет не только об растоновки скобочек,
но и именовании функций, способах обработки ошибок и т.д. и т.п.
Характерно что для C++ есть не только обычный "coding style", но и описание типа
где говориться даже о тех же самых конструкторах, операторах копирования и т.п.
догадываетесь почему это нужно и почему такой совершенно неавторитетный в C++ человек как
Bjarne Stroustrup принял участие в составлении таких рекомендаций? Может
именно потому что 100500 сопсобов это не так уж хорошо и замечательно?
S>Что происходит?
Происходит классический фейл.
Одна из задач собеседования понять
а)понимает ли соискатель будущее начальство
б)делает ли он задачу которую от него хотят
в данном случае — не делает, занимается какой ***й
По опыту, программистам "начинающего" уровня свойственно придавать важное значение
1) количеству "выученных" языков
2) глубокому знанию синтаксиса языка 3) статьям на хабре.
Здравствуйте, Nuzhny, Вы писали:
N>дело не в криворукости или пряморукости,
в ней самой
N> быстрый код на плюсах писать легче. И зачастую кроссплатформенный: GUI со сложной визуализацией, выводом видео и других штук проще написать на Qt, местами переходя на OpenGL и что-то на шейдерах. Хоть у нас и не embedded, хотя там тоже Qt безоговорочный лидер в плане GUI. Не говорю уже про логику и вычисления.
Открой для себя, что css давно уже крутится на gpu в современных браузерах. и нейросетки есть на js- ускоренные на gpu, в браузере. Так что может быть у вас сильные люди в плане математики, но слабые как программисты.
Здравствуйте, Тёмчик, Вы писали:
S>>Но, во-вторых, вы не ответили на простой и прямой вопрос. Итак: вы это всерьез про рилтайм и C++? Тё>При желании, можно и писюн сломать. Так вот, делать реалтайм на C++ с его динамическим распределением памяти, фрагментацией памяти, и непредсказуемыми исключениями, от небольшого ума.
Б$%^&, полный п$%^&* какой-то. Да вы реально поехавший.
Здравствуйте, so5team, Вы писали:
S>Б$%^&, полный п$%^&* какой-то. Да вы реально поехавший.
Тёмыч не то чтобы поехавший, у него просто уровень знаний что-то между джун и мидл-, правда во всём сразу, начиная от крестов и заканчивая сёрфершами, видимо проблемы с концентрацией и усидчивостью, поэтому не стоит так бомбить из-за вечного школьника
Здравствуйте, Тёмчик, Вы писали:
Тё>На чистом питоне делать- то ещё извращение, но если его использовать как клей, то тормозов нет. Позиция NVidia что только на C++ — ну вот и ответ. Кто виноват, что NV проталкивает только C++? Вот тебе tensorjs https://www.tensorflow.org/js.
Это же совсем не то, я же другое спрашивал. И Питон тормозит и будет тормозить. Просто мы говорим о разном: мне важна миллисекунда, а тебе и десяток или сотня не так уж. Для некоторых алгоритмов вообще счёт на сотни микросекунд и ватты энергии считаются. Типа, терять минуты полёта коптера никто не хочет, если он и так не более 40 может в воздухе держаться (а зимой и того меньще).
Тё>Просто надрочились на C++ и гребёте, в то время как есть более продуктивные языки.
Так выбора нет. Где есть, там на Питончике пишем и не жужжим. Твой js по ссылке — это хрень, прости за откровенность. Мы выводим десяток видео на экран, обрабатываем их шейдерами и рисуем поверх. Твой пример грузит видеокарту на 100% и выдаёт жалких 40 fps. Блин, о таких тормозах я и говорю. Не хочу писать такой галимый софт, на который будут пользователи плеваться.
Здравствуйте, Stanislav V. Zudin, Вы писали:
Тё>>А предложите вашим "эксплуататорам" воспользоваться айпадом про. И там всё плавненько в вебе полетит- вот будет облом C++ дрочерам.
SVZ>Ты намеренно или по невнимательности предлагаешь использовать попсовый айпад про вместо защищенного ноута?
Здравствуйте, Тёмчик, Вы писали:
SVZ>>Ты намеренно или по невнимательности предлагаешь использовать попсовый айпад про вместо защищенного ноута? Тё>Нет ну если начальство сказало- защищенный ноут 800x600 на чахлом атоме и форточке, тогда конечно защищенный ноут. А реально, с точки зрения не отягощенного указанием сверху, простого юзера- ведь 13'' ipad pro или самсунг топовый, ведь предпочтительнее.
Не 800х600, а вплоть до FullHD, не Атом, а i5-i7 U. Но они защищённые, с ними можно работать и летом, и зимой даже под снегом. Их можно поставить на камень, пень, просто на землю положить. Кроме того, с ними можно работать под солнцем, у моего Getac яркость экрана 1200 кд/м2, а у iPad максимальная 600 кд/м2. Причём он ещё и глянцевый. Между этими устройствами такая пропасть, что даже смешно.
Здравствуйте, Nuzhny, Вы писали:
N>Не 800х600, а вплоть до FullHD, не Атом, а i5-i7 U. Но они защищённые, с ними можно работать и летом, и зимой даже под снегом. Их можно поставить на камень, пень, просто на землю положить. Кроме того, с ними можно работать под солнцем, у моего Getac яркость экрана 1200 кд/м2, а у iPad максимальная 600 кд/м2. Причём он ещё и глянцевый. Между этими устройствами такая пропасть, что даже смешно.
Здравствуйте, Тёмчик, Вы писали:
Тё>Действительно пропасть, и не смешно. Тё>
Тё>2,732 x 2,048 (265ppi)
Да, а ещё iPad будет намного легче и тоньше. Но без клавиатуры. Блин, им могут пользоваться суровые мужики-нефтянники, когда осматривают трубопровод где-нибудь в Сибири. им иногда и защищённый ноут доверить страшно. Это отдельный класс устройств, он нужен людям, их производят не так много, но производят. Ты же пытаешься выдать всему миру iPad'ы и мощные игровые компы, чтобы у них ничего не тормозило. Но, блин, есть реальный мир, где у каждого свой достаток, у каждого свои условия. Даже если бы не было требований к защищённости (а они есть и для нас решающие), то другим надо было бы работать, например, на дохлых ультрабуках. Почему нет? Вон, Abby сами написали свой нейросетевой фреймворк, потому что нужен им (на С++, да). Фотошоп сейчас активно использует нейросети в своих алгоритмах, им тоже не нужен Питон, они должны работать на широком спектре устройств, в том числе и дохлых Wintel ультрабуках. Я не знаю, что ты тут хочешь доказать, что js хватит всем? Серьёзно?
Здравствуйте, LaptevVV, Вы писали:
LVV>Шаблоны с переменным числом параметров — эио для прикладных?
Ну, да. На них отлично реализуется паттерн Chain of responsibility, где параметры шаблона — отдельные обработчики. Или просто абстрактный тип данных, который потенциально содержит заранее неизвестную композицию примитивных данных.
Здравствуйте, Тёмчик, Вы писали:
N>>Могут, конечно. Но причёт тут DJI?
Тё>DJI- лидер в производстве дронов, в томчисле профессиональные с 3/4 сменными линзами. У них софт под ipad. А гос контора обязательно под Шиндоуз делает, чтоб с клавиатурой. Тё>Похоже что ниасилили ios, как и ниасилили за пределы Qt выйти.
А теперь посмотрим на вакансии DJI. В разделе R&D нашлась одна. По языка требования C, C++, Python, Matlab.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, _ABC_, Вы писали:
KP>>>В АУ на столько все плохо с работой? _AB>>Смотря с какой... Но в целом — что ты хочешь от деревни размером с континент?
KP>Деревни разные бывают. Есть какая-нибудь Ирландия с кучей R&D, есть Сингапур где тоже куча R&D. А вот ситуация с Австралией выглядит непонятно, есть ощущение (я туда в конце 2000-х думал понаехать, к счастью не вышло) что раньше там было с R&D сильно лучше.
я в 2007 даже экзамен по английскому сдал так хотел уехать туда
потом пособеседовался в PCTools и
выяснилось проценто 30 африканеров возращаються из Австралии домой и я решил не ехать
KP>Но ЮАР это реально то место, для которого "не надо путить туризм с эммиграцией" имеет критическое значение.
Ага, я представляю. У меня преподаватель английского был из ЮАР. Рассказывал про веселые юарские 90-тые. У нас, по сравнению с ними, в это время был просто утренник в садике.
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, denisko, Вы писали:
D>>Темка, мой сотрудник недавно свалил на должность принципала как раз в ДЖИ в шеньженьский офис. Не поверишь, у них там все на ++, без жс и пхп. А на куде/сл вообще все самописное без тф и прочего. Ниасилили (((
Тё>Может, пхп не работает на айпаде?
А может, еще причины есть. Напряги что-нибудь, дорогой, постарайся отыскать.
Здравствуйте, smeeld, Вы писали:
S>Это настолько широко распространено, что стало обыденностью. Вы видели это один раз, мне это встречалось два раза (за последние десять лет). И каждый из коллег по текущей работе такое встречали как минимум один раз. Это явление, когда некий слишком много о себе мнящий С++-ник генерит нечитаемый мусор на многоэтажных шаблонах вперемезку с boost-ом или без него, который только ему кажется простым и лаконичным (он его автор), и который разобрать больше никто не способен. Это выкидывают и переписывают на Cи c классами, и в таком виде это живйт и развивается далее годами. Это явление слишком распространено, почему-то. Почему?
Ну не все могут в C++. Это сложный язык, он не для всех. Вот кто не осилил, те и переписывает. Если вам подсунут язык, которого вы не знаете, то вы тоже перепишите. Люди не знают С++, вот и переписывают.
Здравствуйте, Nuzhny, Вы писали:
N>прости, но в какой именно конторе? За последние 10 лет я работал в 4-х, включая АМД и automotive в Люксофте. Да, две были российскими. Как-то ты знаешь, везде языком для продакшена был С++ и конкурентов не предвидилось. И везде были разработки вполне передовые или касающиеся таковых. Кстати, Catalyst в АМД раньше тоже был написан на C# и его... закопали! Потому что глючил и тормозил.
Но это не потому что C# тормозной, а потому что писали жопоруки. В качестве примера можем взять JVM, с которой у меня есть небольшой опыт. Так что, в мире разработки есть устоявшийся миф о том, что JVM тормозная что ппц... ага, у нас в Самсунге на дохлых MIPS-сах с парой ГБ медленной памяти на всё (не было жесткого разделения на диск и оперативную память насколько я помню) приложения на Java работали очень шустро. Просто там классических джавистов не было и никто ереси типа "память — это не ресурс" не говорил. Так что я более чем уверен что написать быстрое приложение на .NET более чем реально, и это даже более разумно чем туда C++ тащить.
Кое в чем я с Артемом согласен: в современном мире если плюсы можно не брать, из нужно не брать. Но если стек обязывает (та же робототехника, AV, игры и прочее), то да, почему б не плюсы.
Здравствуйте, Тёмчик, Вы писали:
Тё>Когда мне было актуально, выбил 99% персентиль на тесте C++.
Это вообще ни о чём.
Уметь это практика применения а не зазубренная теория без понимания.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Тёмчик, Вы писали:
KP>>Наверное не про них, т.к. они ж и есть классическое формошлёпство Тё>Онлайн текстовый процессор- по-твоему это тоже формошлепство?
Здравствуйте, Тёмчик, Вы писали:
KP>>Наверное не про них, т.к. они ж и есть классическое формошлёпство Тё>Онлайн текстовый процессор- по-твоему это тоже формошлепство?
Таки да. Ещё и бессмысленное к тому же.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, kaa.python, Вы писали:
Тё>>А у тебя что? Пилить 1 маленький модуль (считай как 1 микросервис), это элементарно и скучно, никакого челенжа и разнообразия. Секас с костылями C++ я не считаю челленжем- у нормального плюсника всё работает.
KP>А у меня дофига чего, причем в прорывной области, а не устаревшей микросервисной архитектуре
Что лично ты делаешь в прорывной области? Лично ты программируешь или обучаешь нейросетки или FSM? Какое место у C++ в программтровании FPGA например?
Матлабщики делают рокет саенс, а сиплюсники подносят снаряды, ничем не лучше жавистов или нодщиков.
Здравствуйте, B0FEE664, Вы писали:
BFE>Многие смогут прочитать и понять, например, это?:
какой именно фрагмент кода вызвал непонимание? тайпдеф на обработчик события? Тривиальная реализация publish/subscribe? Или каррирование частичное применение? Код вообще прозрачный, я в детстве такой писал после пары лет изучения крестов. Учитывая то, что это C++98, на C++17 всё будет выглядеть гораздо лаконичней.
Здравствуйте, Тёмчик, Вы писали:
Тё>Почитай, узнаешь много нового. Я ж говорил- застряли в развитии в 1995г.
Спасибо, но мне ехать, а не шашечки. Если мне понадобиться асинхронная обработка событий, то подходящие инструменты для нее я найду и без твоей помощи.
Тё>Даже когда я писал на C++, такое говнище не делал.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, landerhigh, Вы писали:
L>>Инженер должен уметь применять готовые решения, а не городить велосипед на каждый чих, разве нет? CC>Инженер должен находить оптимальные решения а не "сводить задачу к предыдущей", дозабивая едва воткнутый гвоздь по шляпку.
Если нужен tar, самое оптимальное решение — скачать tar и не морочить себе моск.
А тут речь идет о "тестовом задании", оптимальность которого определяется собеседователем.
Здравствуйте, andyp, Вы писали:
S>>Сходу не понятно, какой смысл здесь использовать std::list, а не std::vector.
A>Удаление из середины. Незнание как сделать для вектора эффективно или нежелание заморачиваться. Дупликаты при засовывании тоже не отслеживаются наверное от лени.
Там каждый элемент -- это два указателя, т.е. 16 байт в 64-х битном режиме. Если планируется хранить не более десятка-двух подписчиков, то удаление из середины vector-а на современных процессорах будет эффективнее, чем оное в list-е. Т.к. в list-е каждый элемент -- это динамически созданный объект, удаление которого всяко дороже, чем сдвиг нескольких соседей в vector-е.
Плюс сюда же добавляем и то, что при добавлении новых элементов в list в разное время соседние по list-у элементы скорее всего будут располагаться далеко друг от друга в памяти. Т.е. даже проход от начала списка к концу для нотификации окажется менее эффективным, чем такой же проход по vector-у.
Здравствуйте, smeeld, Вы писали:
>>Т.к. в list-е каждый элемент -- это динамически созданный объект, удаление которого всяко дороже, чем сдвиг нескольких соседей в vector-е.
S>Если размеры vector-а — миллионы, и это тяжёлые объекты, которые даже мувятся рядом операций копирования, то сколько будет шуршать такой сдвиг?
Если бы у бабушки ..., то это был бы дедушка.
Мы же не про сфероконей в вакууме разговариваем, а о конкретном примере кода. В котором хранятся, по сути, POD-ы объемом либо в 8, либо в 16 байт (в зависимости от архитектуры). И который вряд ли предназначен для хранения более 2-3 обработчиков (ну ладно, пусть будет даже десяток).
Даже на миллионах тяжелых объектов может оказаться, что list<T> сольет вчистую какому-нибудь специализированному chunked-list-у с unique_ptr<T> внутри.
S>Там каждый элемент -- это два указателя, т.е. 16 байт в 64-х битном режиме. Если планируется хранить не более десятка-двух подписчиков, то удаление из середины vector-а на современных процессорах будет эффективнее, чем оное в list-е. Т.к. в list-е каждый элемент -- это динамически созданный объект, удаление которого всяко дороже, чем сдвиг нескольких соседей в vector-е.
Есть же эффективная схема, если порядок элементов в векторе не важен — поменять местами с последним и удалить.
S>Плюс сюда же добавляем и то, что при добавлении новых элементов в list в разное время соседние по list-у элементы скорее всего будут располагаться далеко друг от друга в памяти. Т.е. даже проход от начала списка к концу для нотификации окажется менее эффективным, чем такой же проход по vector-у.
Здравствуйте, smeeld, Вы писали:
S>Что ты заливаешь? Удаление из list это O(1), так как там всего лишь перекинуть prev-ы и next-ы. Для удаления из массива нужно или искать его в массиве,
Здравствуйте, smeeld, Вы писали:
S>Скинь ссыль, где написано, что порядок там неважен?
На интерфейс класса глянь — я там гарантий некоего порядка выполнения хендлеров не вижу. Клиент же не знает, куда его хендлер воткнули и какой он там по счету. Также, удаление неэффективно, так как клиенту никакая инфа о положении его обработчика в списке не отдается
Здравствуйте, B0FEE664, Вы писали:
BFE>Зачем? К тому же, если эти данные нужны, то их можно положить в то, что скрывается за void*.
Затем, что во многих ситуациях я хочу оперировать с данными контрола в коллбеке ивента, например сделать кнопку неактивной, получить текст из едитбокса, отписаться от события итд итп. Положить можно в void, только зачем заставлять пользователя библиотеки реализовывать стандартную для любой UI библиотеки машинерию?
BFE>Вообще-то void* — это нечто прямо противоположное к прозрачному, это полностью скрытые данные или интерфейсы о которых ничего не известно.
ты следи за контекстом, прозрачный относилось к коду. И использование void* как пользовательского контекста это вообще практика со времён зарождения си и коллбеков.
УК>>Если честно, твои вопросы меня озадачивают, ты вообще сколько кода читал/писал за свою жизнь? BFE>Много. Сотни мегабайтов, наверное.
А что не гигабайтов? Ты похоже далёк от разработки совсем. Судя по всему, что тебя удивляют стандартные UI паттерны, которые есть в любой UI библиотеке, начиная от MFC и заканчивая HTML DOM с его addEventListener, вероятно ты не настоящий сварщик.
BFE>А вот вы пишите, что это тривиальная реализация. Тогда может объясните, зачем там динамический список обработчиков? Ведь такой список обработчиков имеет смысл только при динамическом изменении этого списка, так как иначе можно просто задать один статический обработчик в котором последовательно и явно в коде написать вызовы всех тех кто хочет быть подписан на эти вызовы. Т.е. один callback в котором просто вписаны вызовы всех других. Если же нужен именно динамический список, тогда может быть вы можете указать на задачу, где у кнопки в рантайме меняется список обработчиков у одной и той же кнопки, причём так, что список этих обработчиков не может быть составлен заранее?
Ты прикалываешься? Это же очевидно UI библиотека, у неё не может быть статических обработчиков, так как они задаются пользователем библиотеки (в рантайме). Боже, какой же ты дремучий.
извини, но я уже сделал вывод что ты просто тупой и не в коня корм, не хочу на тебя тратить время, попробуй сам написать UI библиотеку на C++, может быть что-то прояснится.
Здравствуйте, Тёмчик, Вы писали:
S>>Тёмчик, а какое это все имеет отношение к обсуждению уместности применения std::list вместо std::vector? Тё>Блин, так это ж говнокод, что там обсуждать
Вы не знаете ни кто это писал, ни когда, ни зачем, ни в каких условиях. Но авторитетно заявляете про говнокод. Аргументировать можете?
Тё>какой сорт говна лучше- через список или массив.
Использование списка, массива или какой-либо другой структуры для хранения подписок -- это более чем принципиальный момент. Скажем, если "возвращать обьект Subscription с методом unsubscribe и внутри ссылкой на node", то vector для подписок будет не самым лучшим выбором. А при использовании list-а у вас будет оверхед по памяти и отсутствие локальности данных.
Но хватит зубы заговаривать, повторяю вопрос: каким боком здесь "устройство цикличного списка и возможность возвращать обьект Subscription с методом unsubscribe и внутри ссылкой на node"?
Тё>Посмотри на реализацию событийной модели здорового человека- может что-нибудь новое для себя узнаешь.
На какую именно?
S>>Зачем нам шаблоны какого-то Boost-а, если у нас своих полно? Тё>Ну так а я про то, что мазохисты-сектанты с верой, что компилятор C++ из говна O(n*n) сделает ракету.
Ничего не понял, что сказать-то хотели?
Тё>О чём с фанатиками разговаривать. И конторы плюсные поэтому специфические.
Пока что единственный фанатик здесь вы. Фанатично верите в каких-то абстрактных C++ников.
Здравствуйте, so5team, Вы писали:
Тё>>Ну смотри — удаление подписки. Как ты её собрался искать в контейнере? Какова стоимость?
S>Зависит от обстоятельств. К которым мы перейдем ниже, там где фрагменты кода появятся.
Не юли.
S>>>оверхед по памяти и отсутствие локальности данных Тё>>Ты это серьёзно сейчас?
S>Гораздо более серьезно, чем когда вы заявляете, что C++ не используется для рилтайма.
Я заявлял, что в ядре не место C++. Именно полноценному C++, ибо C-с-классами не является полноценным C++ в понимании стандарта C++.
Тё>>Из кривых тормозных кусков кода ты готов замерить оверхед и локальность данных?
S>Как бы когда жизнь заставляет, то приходится замерять. Вне зависимости от качества кода. Более того, чем ниже качество, тем актуальнее становятся замеры.
И часто вас жизнь заставляет замерять оверхед на 10 элементах?
S>>>Но хватит зубы заговаривать, повторяю вопрос: каким боком здесь "устройство цикличного списка и возможность возвращать обьект Subscription с методом unsubscribe и внутри ссылкой на node"?
Тё>>https://en.wikipedia.org/wiki/Sentinel_node#Linked_list_implementation
S>Да уж, так откровенно расписаться в незнаниях C++... Это нужно постараться. Хотя, возможно, когда вы еще имели дело с C++, вам даже C++98 был недоступен.
S>Ибо в C++ Node<T> хранил бы экземпляр T не по указателю, а по значению. А то у вас получится по две аллокации на объект в списке: первая для самого T, вторая для Node<T>.
Ты в курсе, что есть указатель на T, в данном случае? Может быть, это указатель на какой-то родительский объект или другую подписку, которого можно дёрнуть для оповещения об изменениях. Может быть, его и заполнять необязательно.
S>Кроме того, приведенный выше код можно считать документально зафиксированным подтверждением того, что местный Тёмчик говнокодер, неспособный в простейшие структуры данных. Ибо такая наивная реализация изъятия элемента из двусвязного списка без проверки на null значений node.prev/node.next -- это про*б сравнимый с неспособностью развернуть строку. Тёмчик, почему меня не удивляет факт того, что вы говнокодер?
Чувачелло, величина твоего невежества зашкаливает. Но я же привёл ссылку. Сложно прочитать?
Тё>>Сложность удаления O(1). Сложность добавления в конец либо в начало (по вкусу) O(1).
S>А теперь давайте по сути. Допустим, у вас есть что-то вроде: S>
Что за долбанутые наименования с подчёркиванием на конце.
S>В качестве T у нас POD с двумя указателями.
S>Итак, нужно хранить два указателя. Для чего нам потребуется еще три указателя (два в Node, один в Subscription). Плюс добавим сюда тот факт, что Node будет аллоцироваться как отдельный объект. Т.е., скорее всего, ему должен предшествовать какой-то непустой memory-control-block + Node должен быть соответствующим образом выровнен (не будем сейчас брать вырожденные случаи с супер-пупер аллокаторами, которые не нуждаются в MCB и определяют принадлежность куска памяти по значению указателя). Скорее всего получится, что оверхед на хранение информации в списке будет раза эдак в два.
S>Далее, если пописчиков немного (не более десятка), то на современных процессорах тупой линейный поиск по маленькому (но непрерывному) вектору с последующим изъятием, будет эффективнее, чем скакание по разным кускам памяти для модификации соседних элементов в списке.
Если пописчиков немного, то не стоит заморачиваться на алгоритмическую сложность.
S>Далее, можно коснуться вопроса эргономики. Если у нас появляется объект Subscription, то его нужно будет хранить. Что далеко не всегда удобно. Бывают случаи (и таких случаев, могу утверждать из собственного опыта, немало) когда все, что нужно для отписки -- это указатель на сам callback. Даже не обязательно значение opaque-pointer-а, который при подписке связывается с callback-ом.
Кто управляет временем жизни callback?
S>Если достаточно всего лишь указателя на callback, то хранение для каждой подписки Subscription -- это дополнительная головная боль. Особенно в C++, где ничего не защищает от обращения к повисшим указателям.
У хорошего плюсника не бывает тухлых указателей. Вы к таким определённо не относитесь.
S> Использовали экземпляр subscription для отписки один раз, а потом, по ошибке, сделали отписку повторно. И что будет в итоге?
В итоге будет nullptr и это правильно. Ибо кривые руки повторно-вызывальщиков отписок, релизов, диспозов и прочих делетов нужно испрямнять жёстко и без церемоний.
S>Так что, как бы вам не привычно было бы видеть объект Subscription, в разных ситуациях привлекательность этого подхода может быть ну совершенно разной. Включая и "ниже плинтуса".
Тё>>>>Посмотри на реализацию событийной модели здорового человека- может что-нибудь новое для себя узнаешь.
S>>>На какую именно? Тё>>http://reactivex.io/RxCpp/ Тё>>http://reactivex.io/RxCpp/rx-publish_8hpp.html
S>Ок, спасибо. Посмотрю.
Посмотри. Потом как посмотришь, можно будет предметно обсуждать, говно код та наивная копипаста событийной модели, или нет.
Здравствуйте, Тёмчик, Вы писали:
Тё>>>Ну смотри — удаление подписки. Как ты её собрался искать в контейнере? Какова стоимость?
S>>Зависит от обстоятельств. К которым мы перейдем ниже, там где фрагменты кода появятся. Тё>Не юли.
Сперва прочитайте то, что вам пишут, потом уже отвечайте.
S>>Гораздо более серьезно, чем когда вы заявляете, что C++ не используется для рилтайма. Тё>Я заявлял, что в ядре не место C++. Именно полноценному C++, ибо C-с-классами не является полноценным C++ в понимании стандарта C++.
Все ходы записаны.
Тё>И часто вас жизнь заставляет замерять оверхед на 10 элементах?
Нет. Но бывает.
S>>Ибо в C++ Node<T> хранил бы экземпляр T не по указателю, а по значению. А то у вас получится по две аллокации на объект в списке: первая для самого T, вторая для Node<T>. Тё>Ты в курсе, что есть указатель на T, в данном случае? Может быть, это указатель на какой-то родительский объект или другую подписку, которого можно дёрнуть для оповещения об изменениях. Может быть, его и заполнять необязательно.
Тёмчик, давайте говорить о примере от B0FEE664. В котором под T можно подразумевать только std::pair<OnPress, void*>. Если вы хотите ввести в обсуждение еще что-то, то потрудитесь это описать, чтобы люди понимали, о чем речь.
Тё>Чувачелло, величина твоего невежества зашкаливает. Но я же привёл ссылку. Сложно прочитать? Тё>
Т.е. вы для хранения списка подписок предлагаете хранить еще и специальный sentinel node?
Тё>Если пописчиков немного, то не стоит заморачиваться на алгоритмическую сложность.
Если вы еще не заметили, то речь идет не про алгоритмическую сложность, а о стоимости по памяти и времени исполнения. В случаях, когда подписчиков немного.
Тё>Кто управляет временем жизни callback?
Подписчик.
S>>Если достаточно всего лишь указателя на callback, то хранение для каждой подписки Subscription -- это дополнительная головная боль. Особенно в C++, где ничего не защищает от обращения к повисшим указателям. Тё>У хорошего плюсника не бывает тухлых указателей. Вы к таким определённо не относитесь.
Без разницы к каким вы меня относите. Суть в том, что такая проблема есть. И решений, которые ее провоцируют, следует избегать. Тогда будет не важно, хороший плюсник работает с кодом или нет.
S>> Использовали экземпляр subscription для отписки один раз, а потом, по ошибке, сделали отписку повторно. И что будет в итоге? Тё>В итоге будет nullptr и это правильно. Ибо кривые руки повторно-вызывальщиков отписок, релизов, диспозов и прочих делетов нужно испрямнять жёстко и без церемоний.
На словах все герои. Только вот если у вас отписка работает через поиск (по указателю на callback или по какому-то уникальному Id), то она оказывается более устойчивой к подобным ошибкам.
Кроме того, в C++ объекты по умолчанию копируются. Т.е. если есть:
То потребуется еще позаботится о том, чтобы объекты Subscription не копировались. Потому что зануление node_ в копии никак не скажется на исходном объекте. А до C++11 нормальных средств для этого в языке не было (а код от B0FEE664 явно написан для C++98).
Здравствуйте, Тёмчик, Вы писали:
S>>Сперва прочитайте то, что вам пишут, потом уже отвечайте.
Тё>OMG да я понял, что вы давно слились, когда запели про "10 подписок".
Тё>Реалтайм бывает soft и hard. Soft вообще похрен на чём делать, а для hard плюсы не подходят (если не рассматривать C с классами).
Т.е. когда вас прижали к стенке вашей же цитатой, то вы переобуваетесь и признаете, что речь таки шла про рилтайм. ЧТД.
S>>Тёмчик, давайте говорить о примере от B0FEE664. В котором под T можно подразумевать только std::pair<OnPress, void*>. Если вы хотите ввести в обсуждение еще что-то, то потрудитесь это описать, чтобы люди понимали, о чем речь. Тё>Почему у вас onpress в типе? Почему у вас void*? Вы что, про статическую типизацию не слыхали?
Это не у меня. Это у человека, который написал пример, приведенный B0FEE664. А тому человеку, возможно (и скорее всего) нужно было в качестве callback-ов использовать чисто сишные функции. А это может потребоваться по разным причинам, начиная от использования легаси-кода и заканчивая интеграцией C++ного кода и кода на каком-нибудь Lua или Python (из которых наружу торчат C-шные интерфейсы).
S>>Т.е. вы для хранения списка подписок предлагаете хранить еще и специальный sentinel node? Тё>Я не "предлагаю" — это оптимизация связного списка для упрощения его операций, почитайте, учиться ведь всегда полезно.
Так ведь я не про упрощение, а про связанные с этим расходы.
S>>Подписчик. Тё>Ну вот ваш подписчик должен хранить интерфейс для отписки. Может хранить пачку таких подписок в списке, и отписываться в деструкторе, например.
Или он просто хранит у себя указатель на Button и вызывает RemoveOnButtonPress в нужных ему местах.
S>>На словах все герои. Только вот если у вас отписка работает через поиск (по указателю на callback или по какому-то уникальному Id), то она оказывается более устойчивой к подобным ошибкам. Тё>Т.е. вы смирились с фактом, что в вашем говнокоде нет определённости, придёт отписка дважды, или вообще не придёт. И поэтому вы городите тормозной кривой код, оправдывая это порно "локальным кэшем".
Мой говнокод, в отличии от вашего идеального, свободно лежит в открытом доступе. И любой желающий может посмотреть и сделать выводы. В отличии от.
Тё>Возвращается ссылка на интерфейс Subscription. Это может быть наследник от Node имплементирующий Subscription. О каком каком копировании вы поёте?
Тёмчик, мы же про C++ говорим, здесь вы не можете вернуть "интерфейс". Вам нужно возвращать либо экземпляр конкретного класса (и тогда сталкиваться с проблемой копирования экземпляров), либо возвращать (умный) указатель на реализацию интерфейса со всеми вытекающими для этого последствиями.
Небольное количество подписчиков яйца выеденного не стоит. Можете их хоть квадратично перебирать
S>>>Вы заявили следующее (http://rsdn.org/forum/job/7907304.1):
Тё>>Реалтайм бывает soft и hard. Soft вообще похрен на чём делать, а для hard плюсы не подходят (если не рассматривать C с классами).
S>Т.е. когда вас прижали к стенке вашей же цитатой, то вы переобуваетесь и признаете, что речь таки шла про рилтайм. ЧТД.
Признаю диванное поражение от более умелого бойца.
S>>>Тёмчик, давайте говорить о примере от B0FEE664. В котором под T можно подразумевать только std::pair<OnPress, void*>. Если вы хотите ввести в обсуждение еще что-то, то потрудитесь это описать, чтобы люди понимали, о чем речь. Тё>>Почему у вас onpress в типе? Почему у вас void*? Вы что, про статическую типизацию не слыхали?
S>Это не у меня. Это у человека, который написал пример, приведенный B0FEE664. А тому человеку, возможно (и скорее всего) нужно было в качестве callback-ов использовать чисто сишные функции. А это может потребоваться по разным причинам, начиная от использования легаси-кода и заканчивая интеграцией C++ного кода и кода на каком-нибудь Lua или Python (из которых наружу торчат C-шные интерфейсы).
Про интеграцию с чужим API — почитайте про https://en.wikipedia.org/wiki/Visitor_pattern
S>>>Т.е. вы для хранения списка подписок предлагаете хранить еще и специальный sentinel node? Тё>>Я не "предлагаю" — это оптимизация связного списка для упрощения его операций, почитайте, учиться ведь всегда полезно.
S>Так ведь я не про упрощение, а про связанные с этим расходы.
Вот и подумайте про сокращение "C" в формуле C*O(...). Никто вам в C++ не помешает разместить sentinel node в поле цикличного списка по значению.
S>>>Подписчик. Тё>>Ну вот ваш подписчик должен хранить интерфейс для отписки. Может хранить пачку таких подписок в списке, и отписываться в деструкторе, например.
S>Или он просто хранит у себя указатель на Button и вызывает RemoveOnButtonPress в нужных ему местах.
Блиииин ну это же рафинированный говнокод.
S>>>На словах все герои. Только вот если у вас отписка работает через поиск (по указателю на callback или по какому-то уникальному Id), то она оказывается более устойчивой к подобным ошибкам. Тё>>Т.е. вы смирились с фактом, что в вашем говнокоде нет определённости, придёт отписка дважды, или вообще не придёт. И поэтому вы городите тормозной кривой код, оправдывая это порно "локальным кэшем".
S>Мой говнокод, в отличии от вашего идеального, свободно лежит в открытом доступе. И любой желающий может посмотреть и сделать выводы. В отличии от.
Я не обсуждал в этой ветке ваш репозиторий. Сконцентрируйтесь.
Тё>>Возвращается ссылка на интерфейс Subscription. Это может быть наследник от Node имплементирующий Subscription. О каком каком копировании вы поёте?
S>Тёмчик, мы же про C++ говорим, здесь вы не можете вернуть "интерфейс". Вам нужно возвращать либо экземпляр конкретного класса (и тогда сталкиваться с проблемой копирования экземпляров), либо возвращать (умный) указатель на реализацию интерфейса со всеми вытекающими для этого последствиями.
Вы не ответили на вопрос о том, каким боком и зачем бы приплетен паттерн Visitor.
S>> кто контролирует ее время жизни. Отвечая на этот вопрос вы и придете к необходимости возвращать (умный) указатель на реализацию интерфейса. Тё>unsubscribe() мешает благородному дону удалить instance?
У меня пока проблема в том, чтобы разобраться с предложенным вами вариантом. Т.е. понять, что это за вариант вообще.
Пока что вырисовывается приблизительно такая картина:
template<typename T>
class SubscriptionStorage {
public:
struct Unsubscription {
virtual ~Unsubscription() = default;
virtual void unsubscribe() noexcept = 0;
};
[[nodiscard]]
Unsubscription * subscribe(T && value);
...
private:
struct Link {
virtual ~Link() = default;
Link * prev_;
Link * next_;
};
struct OneSubscription : public Link, public Unsubscription {
T payload_;
...
void unsubscribe() override {
... // Вычеркивание из списка.delete this; // Уничтожение узла.
}
}
Link sentinel_;
};
template<typename T>
Unsubscription * SubscriptionStorage::subscribe(T && value) {
return new OneSubscription(std::move(value), ...);
}
S>>Но для этого в C++ немного понимать нужно. Тё>Слушайте, меня конкретно уже разрывает на вашу узколобость в сочетании наскоками на моё знание C++. Вот такие представители профессии и создают негативный стереотип о C++- ках.
-- Этот ваш C++ говно и для разработки реал-тайма не применяется!
-- А ты хоть C++ знаешь?
-- Да!
-- Что такое виртуальный деструктор?
-- Какой ты токсичный! Из-за таких как вы и C++ сообщество считается токсичным!
Тё>Это не относится к действительно прокачанным программистам (как Зудин), которые в силу обстоятельств применяют C++ как инструмент.
Мне как-то фиолетово, насколько прокачанным вы считаете меня, но таки применяю C++ как инструмент. Т.к. в области интересных для меня задач до недавнего времени широко использовались только C и C++, где-то еще была Ada. Сейчас вот Rust подвезли. Но до настоящего мейнстрима Rust-у еще нужно добираться лет 5.
Здравствуйте, Тёмчик, Вы писали:
S>>Вы не ответили на вопрос о том, каким боком и зачем бы приплетен паттерн Visitor. Тё>
S>> тому человеку, возможно (и скорее всего) нужно было в качестве callback-ов использовать чисто сишные функции. А это может потребоваться по разным причинам, начиная от использования легаси-кода и заканчивая интеграцией C++ного кода и кода на каком-нибудь Lua или Python (из которых наружу торчат C-шные интерфейсы).
Тё>Почитайте про Visitor, подумайте.
Читал. Думал. Пока получается, что Тёмчик звиздун, который звиздит не думая, а потом не может за свой звиздежь ответить.
Так как Visitor поможет в интеграции с C-шным кодом.
Тё>Unsubscription => Subscription (подписка) Тё>SubscriptionStorage => ObservableImpl Тё>Link => Node Тё>OneSubscription => SubscriptionNode
Очень веские замечания, да. При том, что Link принципиально сделан как Link, а не как Node. Обратите внимания, что Link кроме ссылок ничего не содержит.
Тё>sentinel иницировать в конструкторе: Тё>sentinel.next = sentinel.prev = sentinel.
За такие инициализации в конструкторе в C++ со времен 1990-х по рукам бъют. Но откуда вам знать-то.
Тё>Можно ещё поиграться с пре-инициализацией кэша SubscriptionNode как цикличного списка, и чтобы ObservableImpl брал Node оттуда в свой список, а при unsubscribe возвращал обратно. Будет тебе тогда cache locality и избежание динамического выделения памяти: Тё>
Тё>SubscriptionNode[2048] nodeCache;
Тё>
Тёмчик, да вы мало того, что зведун, так еще и архитектор-астронавт? Предложить мутную и сложную схему с большими накладными расходами и звиздеть, что это правильный дизайн.
Теперь становятся более понятными ваши стенания о том, что ваш звиздатый код не понимают, а вас не ценят.
Тё>Ну вот для вас виртуальный деструктор- верх сложности?
Нет, это вы не можете подтвердить свое знание C++. Без чего ваши отзывы и о возможностях C++, и о сфере применимости C++ играют очень яркими красками.
Тё>О чём я и говорил: слабость в алгоритмах и религиозная вера в C++.
Мне вот интересно, где именно в нашем с вами споре в этой теме вы нашли религиозную веру в C++ в моих словах. Пальцем показать сможете?
Тё>Я вообще много чем занимался, и нигде из компаний, не являлся C++ рационально обоснованным инструментом. Только исторически или в силу религии.
Здравствуйте, so5team, Вы писали:
S>>>Вы не ответили на вопрос о том, каким боком и зачем бы приплетен паттерн Visitor. Тё>>
S>>> тому человеку, возможно (и скорее всего) нужно было в качестве callback-ов использовать чисто сишные функции. А это может потребоваться по разным причинам, начиная от использования легаси-кода и заканчивая интеграцией C++ного кода и кода на каком-нибудь Lua или Python (из которых наружу торчат C-шные интерфейсы).
Тё>>Почитайте про Visitor, подумайте.
S>Читал. Думал. Пока получается, что Тёмчик звиздун,
Похоже, что не понял. Не обучаем. Отказать.
S>который звиздит не думая, а потом не может за свой звиздежь ответить.
Готов ответить за звиздёж в любое время. Прилетайте в Сидней (может я и долечу когда нить до Бабруйска- но это врядли), я отвечу.
S>Так как Visitor поможет в интеграции с C-шным кодом.
Читайте ещё раз. Хотя, кому я это пишу. Вы упоротый по самые помидоры.
Тё>>Unsubscription => Subscription (подписка) Тё>>SubscriptionStorage => ObservableImpl Тё>>Link => Node Тё>>OneSubscription => SubscriptionNode
S>Очень веские замечания, да. При том, что Link принципиально сделан как Link, а не как Node. Обратите внимания, что Link кроме ссылок ничего не содержит.
Что это за словесный понос? Попробуйте меньше пить.
Тё>>sentinel иницировать в конструкторе: Тё>>sentinel.next = sentinel.prev = sentinel.
S>За такие инициализации в конструкторе в C++ со времен 1990-х по рукам бъют. Но откуда вам знать-то.
Я не писал в 90х на плюсах. Примерно 2001-2011.
Тё>>Можно ещё поиграться с пре-инициализацией кэша SubscriptionNode как цикличного списка, и чтобы ObservableImpl брал Node оттуда в свой список, а при unsubscribe возвращал обратно. Будет тебе тогда cache locality и избежание динамического выделения памяти: Тё>>
Тё>>SubscriptionNode[2048] nodeCache;
Тё>>
S>Тёмчик, да вы мало того, что зведун, так еще и архитектор-астронавт? Предложить мутную и сложную схему с большими накладными расходами и звиздеть, что это правильный дизайн.
Где там большие накладные расходы? Я уже указывал про "отдельных представителей профессии". Мастурбируете на шаблоны, но простейшие структуры данных для вас — "мутно" и "сложно".
S>Теперь становятся более понятными ваши стенания о том, что ваш звиздатый код не понимают, а вас не ценят.
Упоротых много развелось и не только в C++.
Тё>>Ну вот для вас виртуальный деструктор- верх сложности?
S>Нет, это вы не можете подтвердить свое знание C++. Без чего ваши отзывы и о возможностях C++, и о сфере применимости C++ играют очень яркими красками.
Это вы по виртуальному деструктору определили? Сами у себя спросили, сами ответили. Вы настолько упоротый, что не понимаете, что виртуальный деструктор это как 2+2. Вы остановились в развитии когда, в 1990 году?
Тё>>О чём я и говорил: слабость в алгоритмах и религиозная вера в C++.
S>Мне вот интересно, где именно в нашем с вами споре в этой теме вы нашли религиозную веру в C++ в моих словах. Пальцем показать сможете?
Действительно, сложно разобрать, где религиозная вера в C++, а где просто упоротость.
Тё>>Я вообще много чем занимался, и нигде из компаний, не являлся C++ рационально обоснованным инструментом. Только исторически или в силу религии.
S>Сказал как отрезал.
Здравствуйте, so5team, Вы писали:
S>Да он вроде по всем темам такой, от языков программирования до фотоаппаратов с автомобилями. А к плюсам, скорее, вернулся
Очевидно же, что сходил на собеседование, где ему объяснили, что плюсы он не только забыл, но в общем-то никогда и не знал.
Теперь "объясняет", что плюсы не нужны.
Здравствуйте, Тёмчик, Вы писали:
S>>Вот в этом случае, КМК, не будет проблем с временами жизни. Пока живет хотя бы одна подписка, остается живым объект SubscriptionStorage::Internals. Следовательно, деструкторы Subscription могут спокойно вычеркивать себя из списка подписок даже если сам объект SubscriptionStorage прекратил свое существование. С другой стороны, если все объекты Subscription разрушаются до того, как умрет SubscriptionStorage, то вообще никаких проблем: ссылка на SubscriptionStorage::Internals останется только у SubscriptionStorage и этот Internals умрет сразу вслед за SubscriptionStorage.
Тё>Да просто используй std::unique_ptr с кастомным Deleter.
Здесь не нужен кастомный Deleter для unique_ptr. И вы, походу, невкурили главное: кроме unique_ptr на Subscription нужно еще и выделение отдельного объекта Internals на который все участники будут ссылаться через shared_ptr. Только при этом получается более-менее надежная и безопасная схема владения.
Здравствуйте, so5team, Вы писали:
S>>>Вот реально не понимаю, как паттерн Visitor поможет при работе с C API. Ладно бы еще какой-нибудь Facade был упомянут, ну или Bridge хотя бы, но Visitor... Просветите старика, плиз. Тё>>Дано: одно или несколько сторонних API. Нужно: сделать бесшовную интеграцию. Передаём visitor на нужное API. Это широко используемая практика в обработке данных от пачки разных API разных версий.
S>Понятнее не стало. Вот есть C API вида: S>
S>При нажатии на кнопку Ok нужно вызывать somelib_data_on_ready и передать в него указатель, полученный ранее при вызове somelib_data_destroy.
onData(char[] buffer, int offset, int length, Reader *reader) {
// ... read envelope
reader.accept(envelope)
}
S>Каким образом здесь применим Visitor?
В вашем примитивном мирке, действительно, visitor не нужен. У вас нет API
S>>>По поводу накладных расходов все было уже расписано ранее, перечитайте. По поводу "мутно", если вам не понятно, то речь шла про понятность политки владения сущностями в вашем подходе. В C++ сборщика мусора нет. Возвращать голые владеющие указатели так себе способ. Тё>>Можете сделать умный указатель для subscription.
S>Этого будет мало.
unique_ptr с кастомным deleter-м достаточно.
Тё>>Да, C++ это боль.
S>У вас, похоже, это была боль. Даже нет, у вас это была БОЛЬ. Причем такая, что отзывается до сих пор.
Когда этим занимался, было привычно. Вы просто принюхались — посмотрите на более другие языки, где простейшие вещи не требуют титанических мозгозатрат.
>>>>> Реалтаймовые системы не на плюсах делают.
S>>>Ответили за звиздеж, да. Тё>>Не на плюсах.
S>Вот опять звиздеж. Делают. В том числе и на современных. В том числе и с использованием кусков из STL. Ничего не мешает в рилтайм-коде использовать std::find, std::accumulate, std::array и подобный код. Да даже аллоцирующие контейнеры вроде vector, map, set можно применять, если они наполняются в момент инициализации приложения.
Какой толк от "аллоцирующие контейнеры вроде vector, map, set", если они не могут аллцировать в момент работы приложения?
S>Если где-то до сих пор в рилтайме ограничиваются C++98, то, скорее всего, из-за отсутствия сертифицированных компиляторов с поддержкой более новых стандартов.
Тё>>Вот вы влезли в тему событийной модели, которой я сейчас плотно занимаюсь (использую RxJs).
S>Да это очевидно, что сейчас у вас с RxJs конфетно-букетный период.
Надеюсь, в течение нескольких месяцев текущий большой проект c RxJS уйдёт в суппорт, а я займусь новым green field проектом, возможно даже на другом языке. Хотя, TypeScript мне понравился.
А Вы так и будете булькаться на уровне "аллоцирующие контейнеры вроде vector, map, set".
S>>При нажатии на кнопку Ok нужно вызывать somelib_data_on_ready и передать в него указатель, полученный ранее при вызове somelib_data_destroy.
Тё>
Тё>onData(char[] buffer, int offset, int length, Reader *reader) {
Тё> // ... read envelope
Тё> reader.accept(envelope)
Тё>}
Тё>
Что это за кусок говна, пардон май френч? И каким боком этот кусок к вопросу о применимости Visitor для работы с C API?
S>>Каким образом здесь применим Visitor? Тё>В вашем примитивном мирке, действительно, visitor не нужен. У вас нет API
Т.е. вы в очередной раз публично обосрались?
S>>Этого будет мало. Тё>unique_ptr с кастомным deleter-м достаточно.
Нет. Но, похоже, у вас недостаточно знаний и понимания предмета.
S>>У вас, похоже, это была боль. Даже нет, у вас это была БОЛЬ. Причем такая, что отзывается до сих пор. Тё>Когда этим занимался, было привычно. Вы просто принюхались — посмотрите на более другие языки, где простейшие вещи не требуют титанических мозгозатрат.
Так и в C++ не требуют. Просто к C++ нужно относиться как к C++, к Java как к Java, к JavaScript-у как к JavaScript-у. И не пытаться натягивать сову на глобус.
S>>Вот опять звиздеж. Делают. В том числе и на современных. В том числе и с использованием кусков из STL. Ничего не мешает в рилтайм-коде использовать std::find, std::accumulate, std::array и подобный код. Да даже аллоцирующие контейнеры вроде vector, map, set можно применять, если они наполняются в момент инициализации приложения. Тё>Какой толк от "аллоцирующие контейнеры вроде vector, map, set", если они не могут аллцировать в момент работы приложения?
Они хранят данные, к которым вам нужно обращаться в процессе работы, ваш К.О.
И да, в рилтайме после инициализации и входа в рилтайм режим не аллоцируют вне зависимости от ЯП (будь то С, Ada или "Си с классами").
Тё>А Вы так и будете булькаться на уровне "аллоцирующие контейнеры вроде vector, map, set".
Вы так говорите, как будто в этом есть что-то плохое. Попробуйте еще урологу или проктологу с 30 годами стажа предъявить претензию о том, что они всю жизнь в таких местах колупаются.
Здравствуйте, so5team, Вы писали:
S>С простым копированием не так все просто: RemoveOnButtonPress может вызываться не только для удаления текущего обработчика, но и для любого другого. В том числе и для тех обработчиков, до которых внутри for_each-а пока не дошли. Если for_each будет идти по временному контейнеру, то получится, что во временном контейнере останется обработчик, который уже изъят из основного. И будет вызван. Что может сильно удивить пользователя, который этот обработчик только что изъял.
Это уже совсем странный use case. Но, теоретически возможный, да.
S>Тут нужна более хитрая схема. Например, с дополнительным флагом valid/invalid для каждой подписки. Если подписка удаляется в момент публикации (т.е. внутри for_each-а), то физически она не удаляется, а флаг для нее меняется на invalid (+ еще взводится отдельный флаг, который показывает, что список подписок изменился). Перед вызовом подписчика проверяется флаг для него. Если valid, то вызывается. Если invalid, то пропускается. После выхода из for_each-а публикации проверяется общий флаг наличия изменений в списке. Если изменения есть, то идет еще один цикл с изъятием всех invalid подписок.
А можно просто сказать, что из обработчика события безопасно отписывать можно только его самого. Иначе можно получить гонку.
Или перед вызовом колбэков копировать их не в вектор, а в очередь, и при отписке вычищать колбэк и из исходного вектора и из очереди. Впрочем, это уже будет не сильно проще, чем вариант с флагами.
S>А если добавить сюда еще и возможность вызова AddOnButtonPress в момент публикации, то ситуация становится еще интереснее. И, возможно, использование std::list вместо std::vector в таких условиях более оправдано, не смотря на все недостатки std::list-а.
Тут, как раз, в схеме c копированием все хорошо.
Ну и, в схеме с флагами этот кейс тоже не сложно обработать — вместо булевского флага сделать enum, в котором будут состояния по типу Ready, Deleted, New. В случае, когда мы в процессе вызова колбэка, добавлять не с Ready, а с New, а потом все New менять на Ready после завершения вызова колбэков. Ну и, естественно, вместо for each придется использовать обычный for по индексам.
Или просто запоминать размер вектора перед вызовом первого колбэка. И ограничить цикл по колбэкам этим размером (все, что может добавиться в процессе, просто не будет вызвано).
Тё>>onData(char[] buffer, int offset, int length, Reader *reader) {
Тё>> // ... read envelope
Тё>> reader.accept(envelope)
Тё>>}
Тё>>
S>Что это за кусок говна, пардон май френч? И каким боком этот кусок к вопросу о применимости Visitor для работы с C API?
Вы безнадежны .
S>>>Каким образом здесь применим Visitor? Тё>>В вашем примитивном мирке, действительно, visitor не нужен. У вас нет API
S>Т.е. вы в очередной раз публично обосрались?
Вам из Бабруйска виднее.
S>>>Этого будет мало. Тё>>unique_ptr с кастомным deleter-м достаточно.
S>Нет. Но, похоже, у вас недостаточно знаний и понимания предмета.
Вы зачем-то пытаетесь притянуть shared_ptr. Зачем? Если вы его суете во все дыры, — это ещё не значит, что его нужно сувать во все дыры. И кроме того, даже shared_ptr можно реализовать без разделяемого счётчика на куче. Но вы же этого ничего не знаете.
S>Так и в C++ не требуют. Просто к C++ нужно относиться как к C++,
Ещё раз. Когда я писал на C++, ни у кого не было претензий к моему уровню, и максимальные баллы на тестах это подтверждали. Вы же просто сынок в сравнении с нормальным C++ м.
S>>> аллоцирующие контейнеры вроде vector, map, set можно применять, если они наполняются в момент инициализации приложения. Тё>>Какой толк от "аллоцирующие контейнеры вроде vector, map, set", если они не могут аллцировать в момент работы приложения?
S>Они хранят данные, к которым вам нужно обращаться в процессе работы, ваш К.О.
RO-данные можно загружать в удобоваримой форме. Но откуда вам знать про это- вы же ничего в структурах данных и алгоритмах не понимаете. Весь интеллект потрачен на хождение по граблям.
S>Вы так говорите, как будто в этом есть что-то плохое. Попробуйте еще урологу или проктологу с 30 годами стажа предъявить претензию о том, что они всю жизнь в таких местах колупаются.
Только вот ваш уровень можно сравнить не с проктологом, а скорей с ассенизатором.
Здравствуйте, Lexey, Вы писали:
L>А можно просто сказать, что из обработчика события безопасно отписывать можно только его самого. Иначе можно получить гонку.
Есть ощущение, что автор кода пошел еще по более простому пути: тупо сказал, что внутри коллбэков изменение подписки делать нельзя!
Зато решение получилось компактным и простым, сходу видно, что с ним делать можно, а чего нет.
Тё>>>onData(char[] buffer, int offset, int length, Reader *reader) {
Тё>>> // ... read envelope
Тё>>> reader.accept(envelope)
Тё>>>}
Тё>>>
S>>Что это за кусок говна, пардон май френч? И каким боком этот кусок к вопросу о применимости Visitor для работы с C API? Тё>Вы безнадежны .
Вряд ли безнадежен тот, кто открыто говорит о непонимании.
Скорее уж тот, кто надувает щеки и не может внятно объяснить, что он имел в виду.
Тем более, что есть серьезные подозрения, что надувание щек в данном случае -- это лишь попытка замять предложение использовать Visitor там, где от него толку нет вообще.
S>>>>Каким образом здесь применим Visitor? Тё>>>В вашем примитивном мирке, действительно, visitor не нужен. У вас нет API
S>>Т.е. вы в очередной раз публично обосрались? Тё>Вам из Бабруйска виднее.
Пока что получается именно так.
Тё>Вы зачем-то пытаетесь притянуть shared_ptr. Зачем? Если вы его суете во все дыры, — это ещё не значит, что его нужно сувать во все дыры. И кроме того, даже shared_ptr можно реализовать без разделяемого счётчика на куче. Но вы же этого ничего не знаете.
А там как бы и нет разделяемого счетчика на куче.
S>>Так и в C++ не требуют. Просто к C++ нужно относиться как к C++, Тё>Ещё раз. Когда я писал на C++, ни у кого не было претензий к моему уровню, и максимальные баллы на тестах это подтверждали.
Вопрос только в том, кто был проверяющим для вашего кода. И были ли они вообще.
Тё>Вы же просто сынок в сравнении с нормальным C++ м.
Еще раз: моего кода в открытом доступе полно, эдак с пару-тройку десятков тысяч строк. Каждый может посмотреть и сделать собственные выводы.
S>>Они хранят данные, к которым вам нужно обращаться в процессе работы, ваш К.О.
Тё>RO-данные можно загружать в удобоваримой форме.
Речь не идет про RO-данные, актитесь.
Тё>Но откуда вам знать про это- вы же ничего в структурах данных и алгоритмах не понимаете.
Мне уже много годиков и работа моя заключается далеко не только (и не столько) в написании кода. Так что мне простительно.
А вот вы несете откровенную херню явно не то, что не разбираясь в предмете, но даже и близко никогда рядом не находившись, вот это доставляет.
Тё>Только вот ваш уровень можно сравнить не с проктологом, а скорей с ассенизатором.
Хоть с ассенизатором, хоть с мусорщиком, хоть с трубочистом. Тут ведь главное что? Что когда мы перестаем работать, вы сразу же оказываетесь в полном дерьме.
Здравствуйте, so5team, Вы писали:
S>Вряд ли безнадежен тот, кто открыто говорит о непонимании.
Вы напоминаете одного, даже двух коллег из exUSSR. Им 20 раз повторили, но продолжает упорно твердить "не понимаю".
S>Скорее уж тот, кто надувает щеки и не может внятно объяснить, что он имел в виду.
Это вы не можете понять.
S>Тем более, что есть серьезные подозрения, что надувание щек в данном случае -- это лишь попытка замять предложение использовать Visitor там, где от него толку нет вообще.
Вы его не умеете готовить. В общем-то, закрадываются сомнения, а что вы можете готовить.
Тё>>Вы зачем-то пытаетесь притянуть shared_ptr. Зачем? Если вы его суете во все дыры, — это ещё не значит, что его нужно сувать во все дыры. И кроме того, даже shared_ptr можно реализовать без разделяемого счётчика на куче. Но вы же этого ничего не знаете.
S>А там как бы и нет разделяемого счетчика на куче.
Уже нет? Но почему тогда вы утверждали про выделение на куче под умный указатель?
S>Вопрос только в том, кто был проверяющим для вашего кода. И были ли они вообще.
Мой код был идеален и без review
Тё>>Вы же просто сынок в сравнении с нормальным C++ м.
S>Еще раз: моего кода в открытом доступе полно, эдак с пару-тройку десятков тысяч строк. Каждый может посмотреть и сделать собственные выводы.
Мне лень ковыряться в вашем коде в открытом доступе. Несколько лет назад на рсдн была эпическая битва вас с вашей библиотекой, и оппонента с чужой библиотекой на Java. Вы тогда тоже упорно ничего не понимали и твердили про превосходство C++, в то время как та жавская библиотека использовалась в матчере на бирже, до таких требований у вас в Бобруйске не дорастут никогда.
S>>>Они хранят данные, к которым вам нужно обращаться в процессе работы, ваш К.О.
Тё>>RO-данные можно загружать в удобоваримой форме.
S>Речь не идет про RO-данные, актитесь.
У вас данные, к которым вам нужно обращаться в процессе работы, ещё и изменяются? В ядре? C аллокаторами и т.д. Да вы бредите.
Тё>>Но откуда вам знать про это- вы же ничего в структурах данных и алгоритмах не понимаете.
S>Мне уже много годиков и работа моя заключается далеко не только (и не столько) в написании кода. Так что мне простительно.
Так вы ещё и руками водитель. Вот откуда берутся неадекватные компании с C++.
S>А вот вы несете откровенную херню явно не то, что не разбираясь в предмете, но даже и близко никогда рядом не находившись, вот это доставляет.
Юноша, я кодил C++ и скрещивал с другими языками, ещё когда вы в первый класс ходили. А с событийной моделью работаю прямо сейчас. И visitor я использовал для собряжения интерфейсов и форматов при получении и конвертации данных. Поэтому я ответственно заявил — код с addButtonSubscription, deleteButtonSubscription — полное говно. Куда на какой сайт идти и что читать до просветления- указал. Хотите- просвещайтесь, не хотите- булькайтесь в своём копролите.
Тё>>Только вот ваш уровень можно сравнить не с проктологом, а скорей с ассенизатором.
S>Хоть с ассенизатором, хоть с мусорщиком, хоть с трубочистом. Тут ведь главное что? Что когда мы перестаем работать, вы сразу же оказываетесь в полном дерьме.
Вам, скинули копролит мамонта поддерживать, вы и рады.
Не всем это интересно. Кому-то интересно делать новые проекты, изучать новые технолигии, (старые) алгоритмы, и т.д.
Здравствуйте, landerhigh, Вы писали:
L>Кстати, добавлю — недавно понадобилось иметь std::map или std::set, который заполняются лишь однажды и потом почти никогда не модифицируются, но в котором нужно очень иногда искать по ключу, но постоянно приходится просто итерировать.
Ага, частый юзкейс.
Положить в массив, отсортировать и std::lower_bound() на него.
Можно всё обернуть в класс и выставить удобный апи наружу.
Делается легко и непринуждённо.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, so5team, Вы писали:
S>Кроме того, приведенный выше код можно считать документально зафиксированным подтверждением того, что местный Тёмчик говнокодер, неспособный в простейшие структуры данных. Ибо такая наивная реализация изъятия элемента из двусвязного списка без проверки на null значений node.prev/node.next -- это про*б сравнимый с неспособностью развернуть строку. Тёмчик, почему меня не удивляет факт того, что вы говнокодер?
А вы нечитатель, после того, как слово "sentinel node" промелькнуло в этой подветке минимум пять раз. Тут про*б ваш, а не его.
(В основном согласен с остатком письма. В целом в тред не хочу глубоко влезать, слишком много бессмысленных метаний с обеих сторон.)
Здравствуйте, so5team, Вы писали:
Тё>>>>sentinel иницировать в конструкторе: Тё>>>>sentinel.next = sentinel.prev = sentinel. S>>>За такие инициализации в конструкторе в C++ со времен 1990-х по рукам бъют. Но откуда вам знать-то. N>>Хм, это почему же? Где ещё такую инициализацию делать, как не в конструкторе списка? S>В списке инициализации конструктора, а не в теле конструктора. Т.е.
[...] S>Надеюсь, почему атрибутам следует присваивать значения в списке инициализации, а не в теле конструктора, объяснять не нужно.
Ну в данном случае откровенно без разницы. Разве что чтобы "не сбивать руку".
Здравствуйте, landerhigh, Вы писали:
L>Да ладно. Чего там в той же джаве-то знать? L>Там нужно библиотеки знать и уметь их готовить.
Может у меня память херовая, конечно, или я просто программист так себе (что уже ближе к истине, как мне кажется), но я реально быстро забываю языки. Навык правильно писать на C++ без постоянной практики теряется очень быстро. Даже Python легко забывается, что уж тут
Здравствуйте, Тёмчик, Вы писали:
Тё>Вот он, диагноз: незнание алгоритмов, надроч на шаблоны, копролит мамонта.
Вы еще и диагнозы по Интернету ставите? Ох, ё, как все запущено...
Тёмчик, если хочется позвиздеть, то давайте предметно, по программированию, по организации процесса разработки и т.п. вещам. Если сможете, конечно. А если ваша единственная цель -- это обосрать собеседника, то зря тратите время.
Во-первых, я про себя знаю много больше чем вы. Доказывать мне уже никому и ничего не нужно. Так что понизить мою самооценку у вас не получится.
Во-вторых, кроме вас это столько народу пыталось делать (да еще и гораздо более умелого), что ваши попытки на их фоне выглядят жалко. RSDN уже не торт и вы как один из самых заметных местных дурачков лишнее тому подтверждение.
Тё>Интересно за kaa-python конечно, но он скорее исключение, а вот вы — подтверждение правила.
Здравствуйте, landerhigh, Вы писали:
L>>>Тема, ты так и не понял, почему для "можно итерировать" вектор предпочтительнее. L>>> Тё>>Да знаю, сейчас будут страшные слова "cache locality", которые ты не сможешь подтвердить результатами профайлера, например.
L>Где же она, эта оценка "фейспалм"...
Ну т.е. подтвердить собственные слова не можешь, про бинарный поиск не слыхал. Зато научился тянуть каку в проект линковать бесполезные классы из буста. Воинствующий дремучий фанатик.
Здравствуйте, Тёмчик, Вы писали:
Тё>>>Да знаю, сейчас будут страшные слова "cache locality", которые ты не сможешь подтвердить результатами профайлера, например. L>>Где же она, эта оценка "фейспалм"... Тё>Ну т.е. подтвердить собственные слова не можешь, про бинарный поиск не слыхал. Зато научился тянуть каку в проект линковать бесполезные классы из буста. Воинствующий дремучий фанатик.
Здравствуйте, kaa.python, Вы писали:
Тё>>Пойми, что амортизированная сложность C константа у V8 сравнима с Oracle JVM, а у той- с C++. Ибо обращение к свойствам JS обьекта в V8 происходит по смещению в памяти, там вставлен кусочек оптимизорованного C++-го кода. Специалистами Google оптимизированного, а не хайлендером, неспособным вызвать lower/upper bound ибо за 20 лет в индустрии, ниасилившего бинарный поиск.
KP>Я что ты там принимаешь, но JS заметно медленнее даже на тупых синтетических задачах.
Тё>>Хотя нет, не так. Жависты в среднем знают алгоритмы и многопоточку значительно лучше плюсников. Вот теперь можешь тушить коллектор.
KP>А побоку, ты пока что демонстрируешь тотальную деградацию проф.уровня, так что твое мнение в данном вопросе имеет около нулевой вес.
И в чём моя деградация? Что я не бегаю с безумными глазами и не твержу "С++ всех быстрее"?
KP>Ты, кстати, не задумывался на тему того, что если довольно много людей со сравнительно не плохой квалификацией говорят тебе "Тема, ты несешь бред", то вероятность того что ты несешь бред сильно не нулевая? Делюсь тайным знанием: в таких ситуациях стоит остановиться и задуматься "а не несу ли я бред".
Квалификацию этих людей можно проверить на интервью. Пока что у меня большие сомнения в квалификации не знающих алгоритмы плюсодрочеров.
Почему единственная реализация на NodeJS- правая?
KP>но по памяти в ~30 раз хуже!
KP>Node js 61,216 KP>C++ g++ 1,900
Как считали память?
KP>А таки память еще ресурс в ряде случаев. Твое приложение, которое только на 8 гигах стартует как бы на это намекает тебе.
У меня win10 тормозит на <8г ещё до старта приложения.
Тё>>И в чём моя деградация? Что я не бегаю с безумными глазами и не твержу "С++ всех быстрее"?
KP>Ну к примеру ты забыл что память это ресурс, все проблемы пытаешь свести в КА и приложению на JS. Мир богаче сильно и разнообразнее.
А ты забыл, что есть реальный мир. В этом мире, когда ты хочешь найти нужную вещь в амазоне например, ты не хочешь ставить какое-то кривое поделие на MFC, которое ещё и форточку хочет. Ты привык открывать веб сайт.
Тё>>Квалификацию этих людей можно проверить на интервью. Пока что у меня большие сомнения в квалификации не знающих алгоритмы плюсодрочеров.
KP>На интервью можно проверить только то, как хорошо человек подготовился к интервью. Вроде это очевидно
Жаль, что для тебя это очевидно. Для меня очевидно, что если человек на интервью не знает про bigO- будут проблемы с производительностью его кода.
Здравствуйте, so5team, Вы писали:
S>>>Покажите C++ников в этой теме, которые бы твердили "C++ всех быстрее". С ссылками и цитатами. Тё>>Вы сами твердили в споре про sentinel node и демонстрировали непонимание предмета.
S>Если я это твердил, то вам не составит труда дать ссылку на конкретную цитату. http://rsdn.org/forum/job/7913002.1
S>Кроме того, приведенный выше код можно считать документально зафиксированным подтверждением того, что местный Тёмчик говнокодер, неспособный в простейшие структуры данных. Ибо такая наивная реализация изъятия элемента из двусвязного списка без проверки на null значений node.prev/node.next -- это про*б сравнимый с неспособностью развернуть строку. Тёмчик, почему меня не удивляет факт того, что вы говнокодер?
Тё>>А когда я предложил решение на ёлку залезть (O(1)) и непоцарапаться (cache locality), вы перешли на оскорбления.
S>Было предложение хранить ноды в преаллоцированном векторе фиксированного размера. За такое сразу в сад. Ибо если есть возможность заранее предсказать количество подписок, то пляски с динамическими контейнерами не нужны. http://rsdn.org/forum/job/7913532.1
sentinel иницировать в конструкторе:
sentinel.next = sentinel.prev = sentinel.
Можно ещё поиграться с пре-инициализацией кэша SubscriptionNode как цикличного списка, и чтобы ObservableImpl брал Node оттуда в свой список, а при unsubscribe возвращал обратно. Будет тебе тогда cache locality и избежание динамического выделения памяти:
SubscriptionNode[2048] nodeCache;
Тё>sentinel иницировать в конструкторе:
Тё>sentinel.next = sentinel.prev = sentinel.
За такие инициализации в конструкторе в C++ со времен 1990-х по рукам бъют. Но откуда вам знать-то.
Тё>Можно ещё поиграться с пре-инициализацией кэша SubscriptionNode как цикличного списка, и чтобы ObservableImpl брал Node оттуда в свой список, а при unsubscribe возвращал обратно. Будет тебе тогда cache locality и избежание динамического выделения памяти:
Тё>
Тё>SubscriptionNode[2048] nodeCache;
Тё>
Тёмчик, да вы мало того, что зведун, так еще и архитектор-астронавт? Предложить мутную и сложную схему с большими накладными расходами и звиздеть, что это правильный дизайн.
Достаточно привёл цитат? Вы сами завели объект sentinel в теле SubscriptionStorage, а потом докопались, в оскорбительной форме "со времен 1990-х по рукам бъют" SubscriptionStorage присваивать указатель на поле из тела SubscriptionStorage.
S>просьба обратить строку от чайника, который не в курсе, какие способы представления строк встречаются в природе, она о многом говорит. О многом плохом, касающемся конторы.
In computer programming, a string is traditionally a sequence of characters
Open-ended question предполагает задать мутный вопрос, и ожидается наводящий вопрос от кандидата- например, про в каком представлении, а может даже и в какой кодировке.
Я продолжаю задавать написать функцию "перевернуть строку", но сразу с сигнатурой reverseString(char[] a): void — больше никаких open-ended.
S>>>Тёмчик, еще раз: у некоторых из тех, кого вы называете "не знающими алгоритмы плюсодрочерами" в OpenSource десятки тысяч строк код. Тё>>Мне неинтересно читать ваш отлаженный код.
S>Тогда закройте рот и не звиздите о чужой квалификации. Если вам что-то кажется, то ноги в руки и бегом в религиозное заведение. А если рот публично открываете и пытаетесь на кого-то наезжать, то потрудитесь свои наезды аргументировать.
Я не наезжаю на вас неаргументированно. Только по делу. И ваша библиотека в опен сорсе мне неактуальна. Может быть, она неплохая, я не знаю. Для меня актуальна http://reactivex.io/.
S>Когда вы здесь просили отревьювить ваш код, то вам высказали предметные замечания. Из которых как раз таки ваш уровень стал понятен.
Набросились, коршуны . Я перестал писать на C++ до введений C++ 11. Ну да, неправильно использовал emplace_back. Это страшный грех, учитывая, что этих вещей не было в моё время в C++?
S>Я указал на то, как должны инициализироваться члены класса. И на то, что вы, не зная, как это делается должным образом, не владеете инструментом, о применимости которого делаете здесь громкие заявления. Т.е. откровенно звиздите о том, в чем не разбираетесь.
Я привёл ваши цитаты выше, как вы и просили. Вы так брызжете слюной, а вот мне непонятно, что в этот раз не так-то. Нету там умных указателей и их неправильного использования. Мой код приведён как "псевдо код на доске", для объяснения. А уж вы можете его переделать с учётом вашей экспертизы в C++ 20.
S>В этом камень преткновения. А не в том, что какие-то мифические сиплюспоюсники в вакууме свято верят в самый быстрый на свете C++.
Не мифические. Вы и хайлендер- яркие представители.
S>>>Кроме того, приведенный выше код можно считать документально зафиксированным подтверждением того, что местный Тёмчик говнокодер, неспособный в простейшие структуры данных. Ибо такая наивная реализация изъятия элемента из двусвязного списка без проверки на null значений node.prev/node.next -- это про*б сравнимый с неспособностью развернуть строку. Тёмчик, почему меня не удивляет факт того, что вы говнокодер?
S>Ну и где здесь хоть слово про "С++ всех быстрее"?
Вам мало этой цитаты? Тё>>>>А когда я предложил решение на ёлку залезть (O(1)) и непоцарапаться (cache locality), вы перешли на оскорбления. S>>>Было предложение хранить ноды в преаллоцированном векторе фиксированного размера. За такое сразу в сад. Ибо если есть возможность заранее предсказать количество подписок, то пляски с динамическими контейнерами не нужны. Тё>>http://rsdn.org/forum/job/7913532.1
Тё>>Достаточно привёл цитат? S>Нет. Пока ни одной по теме разговора.
Вы просто как материал к затычке в бутылку с шампанским. Абсолютно невосприимчивый структурам данных. Тё>>Вы сами завели объект sentinel в теле SubscriptionStorage S>Во-первых, я ничего не заводил. Прочитайте оригинал: S>
У меня пока проблема в том, чтобы разобраться с предложенным вами вариантом. Т.е. понять, что это за вариант вообще.
S>Пока что вырисовывается приблизительно такая картина:
S>Вы не привели ни строчки нормального кода и мне пришлось фантазировать с ваших слов. Т.е. это мой набросок вашего решения Тё>>а потом докопались, в оскорбительной форме "со времен 1990-х по рукам бъют" SubscriptionStorage присваивать указатель на поле из тела SubscriptionStorage. S>Ну что поделать, если за такие присваивания в C++ бьют по рукам с 1990-х.
В вашем наброске моего решения sentinel в теле SubscriptionStorage. Побейте себя по рукам.
S>>>просьба обратить строку от чайника, который не в курсе, какие способы представления строк встречаются в природе, она о многом говорит. О многом плохом, касающемся конторы. Тё>>
Тё>>In computer programming, a string is traditionally a sequence of characters
S>Тёмчик, "последовательность" вовсе не означает, что строка представлена в виде одного непрерывного вектора, ваш К.О.
Так ещё лучше. Можете предложить разворот списка. Тё>>Я продолжаю задавать написать функцию "перевернуть строку", но сразу с сигнатурой reverseString(char[] a): void — больше никаких open-ended. S>Вы уже окрасили себя в те цвета, в которые... Короче, поздно отмываться.
Астрологи предсказали неделю загрязнённых отсадков из-за техно-аварии разрыва коллектора в Беларуси. Тё>>Я не наезжаю на вас неаргументированно. Только по делу. И ваша библиотека в опен сорсе мне неактуальна. Может быть, она неплохая, я не знаю. S>Во-первых, она не одна. Во-вторых, вопрос не про актуально ли для вас что-то. Может для вас актуально, когда вас в 40 лет со всей дури в боксерском зале по башке мутузят. Если уж вы заговорили о недостаточной квалификации собеседников, то вам прозрачно намекают на способ проверить эту самую квалификацию. Так что либо аргументы в студию, либо рот закройте.
И чо? Есди вы не можете даже развернуть строку- втирайте в более другом месте про вашу неимоверную крутизну. Тё>>Набросились, коршуны . Я перестал писать на C++ до введений C++ 11. Ну да, неправильно использовал emplace_back. Это страшный грех, учитывая, что этих вещей не было в моё время в C++? S>Вы не разбираетесь в предмете о котором судите.
Я не разбираюсь в
Здравствуйте, Тёмчик, Вы писали:
Тё>Я не разбираюсь в нововведениях C++ 11
Учитывая, что C++11 это первая версия, про которую можно реально сказать, что это C++, а не C-с-классами, такая позиция, мягко говоря, удивляет.
(Нет, я не сторонник всё абстрагировать до предела — обычно наоборот, это я как раз пишу на C-с-классами до тех пор, пока реально не начинается от этого явная неэффективность. Но вот хотя бы move-семантика, emplace*... — это то, что абсолютно неизбежно при желании писать хоть как-то оптимально.)
Здравствуйте, so5team, Вы писали:
Тё>>>>Вы из тупого сплита сделали проблему века.
S>>>Скорее вы просто не в курсе. На обычных собеседованиях о таком не спрашивают.
Тё>>Это не отменяёт тупого сплита, который вы переусложнили.
S>Чтобы делать выводы о "переусложнили" или "недоусложнили" следует быть в теме. А вы не.
Я немного интересовался темой парсеров. Могу подкинуть ссылок для просветления
Здравствуйте, so5team, Вы писали:
Тё>>>>>>Вы из тупого сплита сделали проблему века.
S>>>>>Скорее вы просто не в курсе. На обычных собеседованиях о таком не спрашивают.
Тё>>>>Это не отменяёт тупого сплита, который вы переусложнили.
S>>>Чтобы делать выводы о "переусложнили" или "недоусложнили" следует быть в теме. А вы не.
Тё>>Я немного интересовался темой парсеров.
S>Из того, что вы чем-то и когда-то интересовались вовсе не следует наличия у вас a) знаний и b) хотя бы примерного понимания предмета. Что в разговорах с вами выяснялось уже неоднократно.
Тё>>Этой штукой я анализировал исходники C++ в репозитории одной секьюрной компании Тё>>https://www.boost.org/doc/libs/1_75_0/libs/spirit/doc/html/index.html
S>Если бы вы прочитали статью, ссылку на которую я дал, то нашли бы объяснение причин, по которым ни Boost.Spirit, ни PEGTL не подошли.
Эта статья разбор HTTP-заголовка Authorization с помощью easy_parser из RESTinio?
Ну я почитал сейчас. Текст в статье подтвердил моё первоначальное предположение- вы тупой сплит строки переусложнили в кромешный шаблонный ад. Понимаете разницу, я сделал когда-то анализатор сорцов C++ из доступных средств, и забыл. Оно в том время шустро шевелилось и выводило результат- граф зависимостей с помошью graphviz. А вы сделали простой сплиттер http header. Такое делается троечником на лабораторке за 30 минут.
PS по нику eao197 я вас читал посты в 2003-2004гг, вы и тогда были религиозный фанатик.
Здравствуйте, netch80, Вы писали:
N>>>Видите ли, Тёмчик... вы не пробовали и даже не пытались. Если бы попытались, то поняли бы, в чём проблема. Тё>>Я не пробовал и не пытался писать парсеры к фидам сообщений с бирж и брокеров, много лет. Много их форматов, все не вспомнить.
N>Ну расскажите про какой-нибудь с аналогичной проблемой. На всякий случай: с FIX я работал.
Ну это совсем просто. SBE интереснее.
N>>>Ахо с компанией — "книга дракона" — это, конечно, стильно (толстый том полный странных букв... нет, я его читал). Тё>>Читать вы её может быть, читали, но ничего не поняли.
N>Не поняли её как раз вы — судя по вашим прогонам про "поток лексем из парсера" и "тривиальные автоматы". N>Жаль, я надеялся на конструктивное обсуждение.
Чтобы что-то с вами обсуждать, у вас должно быть какое-то понимание предмета.
Здравствуйте, netch80, Вы писали:
N>В этой дискуссии вы успешно показали непонимание предмета вами. Поэтому, действительно, обсуждать с вами нечего.
Сливайтесь, сливайтесь. Ведь вам больно от того, что кто-то приоткрыл вам глаза на правду. Лучше живите в вымышленном мирке грёз про "сипипи круче всех".
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, netch80, Вы писали:
N>>В этой дискуссии вы успешно показали непонимание предмета вами. Поэтому, действительно, обсуждать с вами нечего.
Тё>Сливайтесь, сливайтесь. Ведь вам больно от того, что кто-то приоткрыл вам глаза на правду. Лучше живите в вымышленном мирке грёз про "сипипи круче всех".
Я в этой ветке вообще ни слова про C++ не сказал. Так что вы выдали себя по Фрейду
Здравствуйте, Shmj, Вы писали:
S>Напиши статью-опровержение — посмотрим.
Вот ты щас серьёзно думаешь что кто то ломанётся писать статью-опровержение на этот плач Ярославны?
"Не шмог Максим — да и хрен с ним" (С)
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Shmj, Вы писали:
S>Статья вышла в топ: https://habr.com/ru/post/497114/ Так же комменты доставляют:
S>Что происходит? Можно назвать одним словом — Вавилон. Когда люди делают какой-то грандиозный проект (таким проектом была Вавилонская башня, к примеру) — появляется уйма стандартов (диалектов и т.д.) и приводит к тому, что уже никто не может во всем этом зоопарке разобрваться. Эта программа заложена где-то в нашем разуме — в самой основе.
По моему, автор статьи просто жалуется на потерю смысла жизни. Есть такая поговорка от любителей ходить налево: "даже мышка устает в одну и ту же норку бегать." Тут что-то похожее.
А вообще, да. С++ имеет только два плюса. Остальное только минусы.
Большинство задач необходимо решать на ЯП 4GL, хотя еще сильны суеверия против того, что 1С это чума!
Но посмотрите, — UI готов(тонкий/толстый), безопасность готова, куча готовых модулей.
Есть более гибкие системы на java. Но тоже с кучей готовых плюшек.
Здравствуйте, vsb, Вы писали:
vsb>Просто С++ приманивает некий определённый тип программистов, которых я называю метапрограммистами (и к которым сам отношусь, и от этого отношения пытаюсь избавиться). Это люди, которые не хотят решать задачу заказчика, они хотят писать код, который будет писать код', причём этот процесс должен им доставлять максимальное интеллектуальное удовольствие.
Вы перепутали лисперов с C++-никами. Было время когда первые постоянно стебали вторых, доказывая вторым их ущербность. Но вторые всегда считали себя и ылитой, а C++ как самый великий ЯП из всех существующих (это не так), невзирая на все доводы. Вторые и сейчас таковыми остаются, невзирая на доводы. Тогда это было простительно, они все были школотой, но и сейчас они таковой остаются.
Здравствуйте, CEMb, Вы писали:
CEM>Вот, кстати, знаете, есть такой жизненный принцип, который всегда надо проверять: универсальность + простота = 1. Слишком просто в оборащении — теряет в универсальности. Очень универсальное (например язык ассемблера) всегда довольно сложное.
Кхм. Если иметь ввиду практическую применимость языка под разные задачи, то с ассемблером, по-моему, наоборот. Он не очень сложный, в сущности даже примитивный, но не универсальный.
CEM>В любом языке программирования самое главное — это ум программиста. Если его нет, то это не в языке проблема, а в программисте. (Йопрст, зачем я это написал, теперь мне же будут этим тыкать в мой код... )
причем здесь тип программистов ?
это требования рыночка
если завтра появится 90% компаний у которых нет требований к примеру метапрограммирования
даже гиганты это требования вычеркнут из своих вакансий
то метапрограммирование умерт на последнем С++ стандарте
Здравствуйте, $$, Вы писали:
L>>Да, а потом эти аналоги таров приходится вручную из продакшена выкорчевывать. Тру прогеры, my ass.
$>Велосипедизмом тоже плюсники чаще страдают, кстати. Питонисты или нодщики просто берут и готовят из готовых библиотек. В случае нужды, могут и на C модуль сделать. Но плюсники часто пытаются забивать микроскопом гвозди, а нередко и не знают алгоритмов,
Есть тру прогеры, которые могут за полчаса на коленке этот аналог tar накидать хоть на плюсах, хоть на си, питоне, ноде и чём угодно.
Здравствуйте, vsb, Вы писали:
vsb>Я лично видел ситуацию, когда один проект, написанный метапрограммистом, где шаблоны бустами погоняли, выкинули и переписали на простом "C с классами". Потому, что не осилили поддерживать это, после того, как создатель уволился. И новый вариант вполне себе живёт и развивается.
Это настолько широко распространено, что стало обыденностью. Вы видели это один раз, мне это встречалось два раза (за последние десять лет). И каждый из коллег по текущей работе такое встречали как минимум один раз. Это явление, когда некий слишком много о себе мнящий С++-ник генерит нечитаемый мусор на многоэтажных шаблонах вперемезку с boost-ом или без него, который только ему кажется простым и лаконичным (он его автор), и который разобрать больше никто не способен. Это выкидывают и переписывают на Cи c классами, и в таком виде это живйт и развивается далее годами. Это явление слишком распространено, почему-то. Почему?
Здравствуйте, smeeld, Вы писали:
S>Это настолько широко распространено, что стало обыденностью. Вы видели это один раз, мне это встречалось два раза (за последние десять лет). И каждый из коллег по текущей работе такое встречали как минимум один раз. Это явление, когда некий слишком много о себе мнящий С++-ник генерит нечитаемый мусор на многоэтажных шаблонах вперемезку с boost-ом или без него, который только ему кажется простым и лаконичным (он его автор), и который разобрать больше никто не способен. Это выкидывают и переписывают на Cи c классами, и в таком виде это живйт и развивается далее годами. Это явление слишком распространено, почему-то. Почему?
Ух, 8 лет назад мне достался в наследство DAL нафигаченный "синьором помидором" в лучших традициях почитателей Александреску, до сих пор глаз дергается, как вспоминаю.
Здравствуйте, reversecode, Вы писали:
R>вообще это стадия любого "говнокодера", который пол жизни багфиксит R>а потом оборачивается, и не видит результат R>а результатом кодера должен быть софт(продукт) R>а не знания С++ на 30 из 30
согласен,
и какие есть варианты как уйти из багфикса на С/С++ ?
я за 8 лет видел проектов 7-10 на Си а потом плюсах они начаты в 95-2005 годах что намекает что даже добавления фичи
там не сильно отличаеться от багфикса
Здравствуйте, Reset, Вы писали:
>> Еще час я потратил, чтобы узнать, как кроссплатформенно открыть файл и узнать его размер. Кажется, никак, если нет С++17 c std::filesystem. R>Ну, да, конечно, без Qt и boost'а этого никак не сделать. ftell щас ваще не в моде, особенно, когда ты 17 лет в профессии. Очередной балабол, очередная статья (возможно, статья-провокация от человека, не имеющего никакого отношения к разработке).
Полегче-полегче! Это из каментов такое.
Здравствуйте, vsb, Вы писали:
vsb>А я тебе так скажу. Я лично видел ситуацию, когда один проект, написанный метапрограммистом, где шаблоны бустами погоняли, выкинули и переписали на простом "C с классами".
И правильно сделали. Ибо KISS
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Для UK, к сожалению, это означает "самый дешевый доширак".
Ну и ковыряние с окаменелыми говнами мамонта в спеках и реализациях протоколов в полный рост.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, prog123, Вы писали:
P>>Машиностроение (самолеты, автомобили), роботы и прочее. P>>Например https://www.indeed.com/q-Autonomous-Vehicle-jobs.html
L>Для UK, к сожалению, это означает "самый дешевый доширак". L>Ну и ковыряние с окаменелыми говнами мамонта в спеках и реализациях протоколов в полный рост.
В UK нужно работать в банке.
Спеки тоже обновляются, новые девайсы появляются. Так что не только баг-фиксинг. Опять же упомянутый MCAS, новое ведь)
Здравствуйте, landerhigh, Вы писали:
L>Мне нравится категоричность.
Всегда рад, обращайтесь к нам ещё!
L> Выдает опыт. И житейскую мудрость.
Отож!
L>Особенно использование междометия "чувак".
Сорри, я малость раздражён сегодня лютой идиотией которую творят местные политики.
L>Родной, у нормального инженера просьба переизобрести колесо вызывает лишь один вопрос — "зачем"?
Ты путаешь работу и собеседование. На собеседовании надо понять умеет ли кандидат инженерно мыслить. Когда надо из того ограниченного набора что доступно собрать то, что надо. На работе тоже надо, но колесо там куда более сложной формы и готовых как правило нет.
Потому пример для собеседования выбирается предельно простым.
L> Подобные тесты как раз отсеивают опытных инженеров.
Опытный инженер это не беспомощный инженер.
L>Студент-то сходу напишет.
Если бы!
L>Вон, недавно одних таких попросили написать MCAS. Написали MCAS и лишних вопросов не задали. Инженер, которых задавал кучу лишних вопросов, уволен, проект сдан вовремя, заказчик щаслив, акционеры рукоплескают. Oh wait...
Ну, и на самом интересном месте прервался. Так что дальше то было?
L>Какой в пень tar, там либо биты памяти нужно уметь экономить с антикварным-С-компилятором, либо модули ядра линукса писать.
Вот только для собеседования такие вопросы подходят плохо — не та обстановка и временные рамки.
Впрочем в любом случае если embedded чел за 4 часа не способен накропать аналог tar — это лютое фиаско. Я не embedded а просто системщик, tar-ы ежедневно не пишу, но мне на это надо ну полчаса неспешного тайпания.
L>Если позиция плюсовая, то как в такой задаче показать знание собственно плюсов
Для начала надо определиться что это вообще такое — знание плюсов. Что под этим понимать?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Poopy Joe, Вы писали:
PJ>Есть код простой, а есть код примитивный. Так вот шаблоны позволяют писать код простой, когда читателю достаточно понимать и оперировать абстракциями. А не утруждающие себя рассуждениями пейсатели обычно фигачат код примитивный, где читателю приходится декодировать полет их мысли в километровых спагетти-простынях.
Это работает пока шаблон уровня STL, что то типа стандартных типов, что то крупнее — практически всегда "полёт мысли".
Здравствуйте, landerhigh, Вы писали:
L>Родной, ты где там структуры и алгоритмы, о которых стоило бы поговорить, нашел?
Это эхо старой темы, которую он не понял.
Там шла речь о простом вопросе для собеседования, который можно решить множеством способов. И сам вопрос лишь повод поговорить и посмотреть как кандидат мыслит.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, landerhigh, Вы писали:
L>Хороший у вас бекенд
А ты вообще бекендом занимался, в частности embedded, или зашёл в очередной раз пожаловаться на плохие вопросы на интервью?
L>Ага. Можно на лиспе в одну строчку записать вообще.
Так напиши.
L>$>4) и ненавязчиво посмотреть, применит ли правильные структуры и алгоритмы, или наговнит
L>Родной, ты где там структуры и алгоритмы, о которых стоило бы поговорить, нашел?
Например, в каком порядке обходить иерархию директорий. В каком порядке размещать содержимое и имена файлов. Если добавить фичу "добавить папку к существующему архиву", какой порядок нужен, чтобы можно было дописать в конец архива.
vsb>Просто С++ приманивает некий определённый тип программистов, которых я называю метапрограммистами (и к которым сам отношусь, и от этого отношения пытаюсь избавиться). Это люди, которые не хотят решать задачу заказчика, они хотят писать код, который будет писать код', причём этот процесс должен им доставлять максимальное интеллектуальное удовольствие. Причём что должен делать этот код', написанный кодом, не так важно. Теоретически он должен делать то, что хочет заказчик, практически он может это делать, он может делать гораздо больше или он может делать гораздо меньше.
Комитет по стандартизации — все такие!
Они каждый следующий наворот — для себя, любимых!
А модулей нормальных нет до сих пор...
Которые Вирт еще в Модуле сделал... И в ТурбоПаскале они были...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, sergey2b, Вы писали:
S>так первая версия винды писалась на pascal поэтому там код был более структуированный
Первая это которая 1.0?
S>NT 3.51 была уже вполне нормальной
Для обычных пользователей ещё была недоступна, в основном потому что юзерское типичное железо не тянуло.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
LVV>>Два креста — это чтоб наверняка, чтоб уже зарыли и не откопали... CC>Мда... CC>Кто то в жизни видит плюсы а кто то — кресты.
Я С/С++ с первого издания Кернигана-Ричи знаю...
И работал на нем с 1989 года.
Так что я знаю, о чем говорю.
Кстати, и сейчас работаю.
И преподаю.
С точки зрения обучения начинающих программистов — там кресты, а не плюсы.
Ну, а мне лично С++ нравится.
Особенно после книжки Ивана Чукича о функциональном программировании на С++.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, CreatorCray, Вы писали:
S>>так первая версия винды писалась на pascal поэтому там код был более структуированный CC>Первая это которая 1.0?
Эта городская легенда, что первая Windows была написана на Pascal, живуча емнип лишь потому что функции API объявлены c соглашением вызовов __stdcall. И в те древние времена оно называлось __pascal. Оказывается, было еще __fortran. Значит ли это что Windows 0.1 пытались сделать на Фортране?!
Здравствуйте, $$, Вы писали:
L>>Хороший у вас бекенд
$>А ты вообще бекендом занимался, в частности embedded, или зашёл в очередной раз пожаловаться на плохие вопросы на интервью?
Да нет конечно. Особенно имбеддед. Куда ж мне до светил программерской мысли!
L>>$>4) и ненавязчиво посмотреть, применит ли правильные структуры и алгоритмы, или наговнит L>>Родной, ты где там структуры и алгоритмы, о которых стоило бы поговорить, нашел?
$>Например, в каком порядке обходить иерархию директорий.
Родной, есть всего два варианта — выбираешь, какой сегодня нравится больше.
$>В каком порядке размещать содержимое и имена файлов.
для версии, которую можно худо-бедно наговнякать за 4 часа, существует только один худо-бедно работающий вариант.
$>Если добавить фичу "добавить папку к существующему архиву", какой порядок нужен, чтобы можно было дописать в конец архива.
Здравствуйте, LaptevVV, Вы писали:
LVV>А модулей нормальных нет до сих пор...
Валерий Викторович, а у вас есть видение как должны быть реализованы модули в С++, их место, возможности и какие задачи они призваны решать? Ну вот чтобы по пунктам. Может статью запилите?
Здравствуйте, landerhigh, Вы писали:
L>Да нет конечно. Особенно имбеддед. Куда ж мне до светил программерской мысли!
По твоим батхертам на простые вопросы как-то даже непонятно, что ты вообще знаешь. Никогда никаких идей, только жалобы на плохих интервьюеров.
L>>>$>4) и ненавязчиво посмотреть, применит ли правильные структуры и алгоритмы, или наговнит L>>>Родной, ты где там структуры и алгоритмы, о которых стоило бы поговорить, нашел? L>$>Например, в каком порядке обходить иерархию директорий.
L>Родной, есть всего два варианта — выбираешь, какой сегодня нравится больше.
я
Ну так и рассказать про оба варианта, и когда лучше один, а когда- другой.
L>$>В каком порядке размещать содержимое и имена файлов.
L>для версии, которую можно худо-бедно наговнякать за 4 часа, существует только один худо-бедно работающий вариант.
Тот, который кандидат худо-бедно накидал на коленке? Ну хорошо, если накидал. А то может, час буст ставил, 2 часа думал о шаблонах и в остальное время накидал нерабочий бред.
L>$>Если добавить фичу "добавить папку к существующему архиву", какой порядок нужен, чтобы можно было дописать в конец архива.
L>сомневаюсь, что за 4 часа у тебя дойдет до этого.
С такими кандидатами, сомневаюсь что дойдёт хотя бы до кривого единственного варианта
Здравствуйте, Философ, Вы писали:
Ф>Инженер — да, это его обязанность (задавать вопросы). Если инженера уволили за то, что он работал — ССЗБ, что тут ещё сказать. Ф>С программистами ситуация немного иная: если тебе поставили ТЗ — будь добр, РЕШАЙ.
Это в какой вселенной существуют такие ТЗ, которые можно просто взять и решать?
Ф>Обычно я горел на том, что самая простая реализация (временная, для тестов...), сделанная на скорую руку, потом юзалась годами обрастая мясом, и превращаясь в монстра, суперкомбайн, который умеет много и одновременно непонятно что, одним своим видом лишая надежды в нём разобраться тех, кто туда сунул нос впервые. Ф>Первое, о чём нужно помнить, создавая новый солюшн — нет ничего более постоянного, чем временное. Эту мантру нужно повторить трижды, прежде чем создавать вот такой новый проект — иначе это начало новой большой беды.
Вот это одна из причин, по которой данный тест — это антитест.
LVV>>Комитет по стандартизации — все такие! PM>Вы похоже путаете правительство, которое на другой планете, с людьми из комитета. Вся информация по его работе находится в открытом доступе. Есть даже рабочая группа на русском языке https://stdcpp.ru
а) вот как у вас мысль на правительство повернуло?
б) читаю я группу LVV>>Они каждый следующий наворот — для себя, любимых! PM>У вас тоже есть шанс сделать какой-нибудь наворот, предложение к стандарту С++ может написать каждый, см. ссылку выше
а) я — пользователь данного языка
б) все навороты — не для среднего программиста. А именНо для метапрограммистов... LVV>>А модулей нормальных нет до сих пор... LVV>>Которые Вирт еще в Модуле сделал... И в ТурбоПаскале они были... PM>Ну так напишите очередное предложение, может быть оно окажется лучше предыдущих. Я вот собираюсь поэкспериментировать с модулями, которые войдут в С++20
Опять же — НАФИГА КОТУ БАЯН. PM>Или пишите на Модуле, ТурбоПаскале. Хотя, погодите-ка.., сейчас требуются только Кобол-программисты.
Да мы проще поступили.
Сделали свой язык для обучения и его учим. А потом переводим в С++, чтоб народ не отставал от тенденций.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
DO>>Валерий Викторович, а у вас есть видение как должны быть реализованы модули в С++, их место, возможности и какие задачи они призваны решать? Ну вот чтобы по пунктам. Может статью запилите? LVV>Естественно, есть. Я ж старый виртовец... В орле регулярно встречаемся. LVV>Гуткнехт приезжал, рассказывал последние их работы — очень интересно! LVV>Посмотрите в сети День Оберона 2-18. LVV>Более того, мы сделали же свой язык для обучения и за образец взяли модули Компонентного паскаля в системе BlackBox.
Это всё хорошо, но речь не о собственном языке и не о паскале и его наследниках, а о С++. Вы можете написать предложения и вынести их на комитет? Я, собственно, об этом.
Здравствуйте, PM, Вы писали:
PM>Здравствуйте, CreatorCray, Вы писали:
S>>>так первая версия винды писалась на pascal поэтому там код был более структуированный CC>>Первая это которая 1.0?
PM>Эта городская легенда, что первая Windows была написана на Pascal, живуча емнип лишь потому что функции API объявлены c соглашением вызовов __stdcall. И в те древние времена оно называлось __pascal. Оказывается, было еще __fortran. Значит ли это что Windows 0.1 пытались сделать на Фортране?!
у меня есть книга по win sdk 90-91 года издания
где глава посвяшенна началу проектов win и excel там про pascal прямо сказанно
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Комитет по стандартизации — все такие! PM>>Вы похоже путаете правительство, которое на другой планете, с людьми из комитета. Вся информация по его работе находится в открытом доступе. Есть даже рабочая группа на русском языке https://stdcpp.ru LVV>а) вот как у вас мысль на правительство повернуло? LVV>б) читаю я группу
Простите, но выделенное напомнило. Ладно, это будет скатывание в политику, не будем здесь.
LVV>>>Они каждый следующий наворот — для себя, любимых! PM>>У вас тоже есть шанс сделать какой-нибудь наворот, предложение к стандарту С++ может написать каждый, см. ссылку выше LVV>а) я — пользователь данного языка LVV>б) все навороты — не для среднего программиста. А именНо для метапрограммистов...
Вы не могли бы привести пример, когда в С++03 было проще, а в С++11 стало сложнее? Ну или от С++11 к С++14?
Лично для себя, как простого прикладного программиста, я наоборот с каждым следующим стандартом вижу упрощение. На С++14 писать проще и выразительнее, чем на С++11, а С++17 принес много полезного в стандартную библиотеку.
LVV>>>А модулей нормальных нет до сих пор... LVV>>>Которые Вирт еще в Модуле сделал... И в ТурбоПаскале они были... PM>>Ну так напишите очередное предложение, может быть оно окажется лучше предыдущих. Я вот собираюсь поэкспериментировать с модулями, которые войдут в С++20 LVV>Опять же — НАФИГА КОТУ БАЯН.
Не могу понять здесь вашу позицию, модулей в языке нет или они не нужны? Уже сейчас существует их экспериментальная реализация как минимум в 2-х компиляторах, и это вероятно будет принято в следующем стандарте. Если у вас есть идея как это сделать лучше с учётом существующих и будущих ограничений, так поделитесь ей. А то может быть все те люди, которые работают больше 10 лет над модулями зря время тратят.
PM>>Или пишите на Модуле, ТурбоПаскале. Хотя, погодите-ка.., сейчас требуются только Кобол-программисты. LVV>Да мы проще поступили. LVV>Сделали свой язык для обучения и его учим. А потом переводим в С++, чтоб народ не отставал от тенденций.
Переводите кому, или где? Не очень понятно. А курсовые и дипломы ваши студенты на каких языках пишут? И после выпуска чем будут пользоваться?
Здравствуйте, IID, Вы писали:
IID>Ты формат этого тара видел ? Он же тупой как бревно. Особенно обязательный размер блока в 512 байт. Что-то там ещё было, от чего хотелось разбить себе лицо рукой. Именно от тупости, не от сложности.
В задаче не требуется повторять формат. Требуется сделать аналог с какой угодно упаковкой.
IID>Что тебя пугает в нём, расскажи.
Здравствуйте, sergey2b, Вы писали:
S>>>>так первая версия винды писалась на pascal поэтому там код был более структуированный CC>>>Первая это которая 1.0?
PM>>Эта городская легенда, что первая Windows была написана на Pascal, живуча емнип лишь потому что функции API объявлены c соглашением вызовов __stdcall. И в те древние времена оно называлось __pascal. Оказывается, было еще __fortran. Значит ли это что Windows 0.1 пытались сделать на Фортране?!
S>у меня есть книга по win sdk 90-91 года издания S>где глава посвяшенна началу проектов win и excel там про pascal прямо сказанно
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, sergey2b, Вы писали:
S>>на 10 лет меньше чем винду CC>Откуда 10 то? CC>Linux initial release date: September 17, 1991 CC>Windows initial release date: November 20, 1985
Это не та винда. "Ту" только в 1988 начал Dave Cutler делать. А Линукс я бы отсчитывал с Белл лабс.
PM>И сегодня я не смог найти ни одного подтверждения в пользу Паскаля. Версия про смесь Си и ассемблера выглядит для меня правдоподобнее.
я когда добирусь до книжки сделаю фото страниц
для меня Си и асм тоже выглядят более правдоподобно, единственное косвенное подтверждение это даты релизов
к тому же в USSR была деформированная история MS многие считали MS антогонистом Apple и CP/M
а выяснилось что MS зарабатывало существенный процент денег именно на продуктах для Apple и поддержке CP/M (как языков так и железа)
те что мы думаем о раннем MS +- не соответсвует действительности
Здравствуйте, IID, Вы писали:
L>>В задаче не требуется повторять формат. Требуется сделать аналог с какой угодно упаковкой. IID>И все ???
IID>>>Что тебя пугает в нём, расскажи. L>>Ну так за 4 часа напишешь? IID>Да любой Джун знакомый с рекурсией и понятием TLV напишет.
Я не про любого джуна спрашиваю. Тут уже двое били себя пяткой в грудь, что там на полчаса неспешного тайпанья.
Еще раз. Зум сессия, лимит времени четыре часа. Напишешь?
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, sergey2b, Вы писали:
S>>те что мы думаем о раннем MS +- не соответсвует действительности
IID>Не знаю что вы думаете, любой эрудированный человек это знает. Как и то, ,то у МС был свой юникс в 1984 году, xenix.
про MS xenix были книжки на русском языке, я видел у отца их
скажем для меня было откровением что MS массово прадавала платы расширения RAM для apple II и платы CP/M с z80
что все Apple II plus и старше шли с MS BASIC и компиляторы pascal COBOL FORTRAN тоже были от MS
те MS покрайней мере до 83 года более чем активно зарабатывала на Apple
LVV>>>>Они каждый следующий наворот — для себя, любимых! PM>>>У вас тоже есть шанс сделать какой-нибудь наворот, предложение к стандарту С++ может написать каждый, см. ссылку выше LVV>>а) я — пользователь данного языка LVV>>б) все навороты — не для среднего программиста. А именНо для метапрограммистов... PM>Вы не могли бы привести пример, когда в С++03 было проще, а в С++11 стало сложнее? Ну или от С++11 к С++14? PM>Лично для себя, как простого прикладного программиста, я наоборот с каждым следующим стандартом вижу упрощение. На С++14 писать проще и выразительнее, чем на С++11, а С++17 принес много полезного в стандартную библиотеку.
Не-не-не...
Сложнее не стало .
Но навороты — не для средних программистов.
Вот описывал Алесандреску списки типов. Теперь стало проще.
Но списки типов — это разве пишет средний программист?
Шаблоны с переменным числом параметров — эио для прикладных?
forward — это для прикладных?
Семантика перемещения — это, как минимум, для миддлов.
И правила перегрузки усложнились.
Для прикладных — auto, лямбды, таплы, и дополнения стандартной библиотеки.
Которую пишут отнюдь не рядовые программеры.
Вот, например, усовершенствования позволили Ивану Чукичу писать на С++ в функциональном стиле. О чем он книжку написал.
Но Иван Чукич — это разве рядовой программер? LVV>>>>А модулей нормальных нет до сих пор... LVV>>>>Которые Вирт еще в Модуле сделал... И в ТурбоПаскале они были... PM>>>Ну так напишите очередное предложение, может быть оно окажется лучше предыдущих. PM>>>Я вот собираюсь поэкспериментировать с модулями, которые войдут в С++20 LVV>>Опять же — НАФИГА КОТУ БАЯН. PM>Не могу понять здесь вашу позицию, модулей в языке нет или они не нужны? Уже сейчас существует их экспериментальная реализация как минимум в 2-х компиляторах, и это вероятно будет принято в следующем стандарте. Если у вас есть идея как это сделать лучше с учётом существующих и будущих ограничений, так поделитесь ей. А то может быть все те люди, которые работают больше 10 лет над модулями зря время тратят.
Да потому, что Вирт уже давно все написал. А комитет в ту сторону даже не смотрит. Более 10 лет не могут модули из Модулы-2 взять — ЭТО ПЯТЬ! PM>>>Или пишите на Модуле, ТурбоПаскале. Хотя, погодите-ка.., сейчас требуются только Кобол-программисты. LVV>>Да мы проще поступили. LVV>>Сделали свой язык для обучения и его учим. А потом переводим в С++, чтоб народ не отставал от тенденций. PM>Переводите кому, или где? Не очень понятно. А курсовые и дипломы ваши студенты на каких языках пишут? И после выпуска чем будут пользоваться?
1. Сейчас пацан на основе нашего предыдущего опыта (с 2012 года среда для начинающих программеров) делает Slang IDE на основе VS Code
2. C языком Slang. Который конвертируется в С++ (это он тоже уже написал: парсер на antlr, остальное — ручками)
3. Эта среда а) автономная б) клиент к олимпиадной системе (которую тоже пацан пишет — на C# в NET Core)
4. Первый семестр для выравнивания абитура поступившая учится в нашей учебной среде Semantic IDE.
Там можно на русском или на английском. Кто понимает — сразу уходит в английский, кто не понимает — сначала на русском.
Там же и первую курсовую делают.
5. Далее у нас был С++, но опыт показал, нужен переход.
Вот за 2 года сделали Slang IDE — будем внедрять в классы. Тем более знакомство с VS Code по-любому полезно.
6. на 2 курсе — плотно С++ в разных курсах.
На 3 курсе — С++ и C# в разных курсах.
Где-то у нас там есть и ВЕБ-программирование — там JavaScript и весь остальной нужный инструметарий.
И где-то там же у нас есть мобильные приложения — и там Java и/или Котлин.
На всем этом и пишут курсовые. И дипломы.
Посмотрим, как пойдет Slang IDE — мож и курсовая будет на Slang.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>Ну, а мне лично С++ нравится. LVV>>Особенно после книжки Ивана Чукича о функциональном программировании на С++. R>это в той где переливание воды перевели в картинки ? R>вчера спецом пошел и скачал в оригинале на инглыше с гугла R>вода водой
Мы типа такие крутые, что Иван Чукич — отстой.
Поделитесь с миров вашими сакральными знаниями — Чукич у вас поучится.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
DO>Это всё хорошо, но речь не о собственном языке и не о паскале и его наследниках, а о С++. Вы можете написать предложения и вынести их на комитет? Я, собственно, об этом.
Я — пользователь языка. У меня другие работы БОЛЕЕ приоритетны, чем писать модули в С++.
И разработчики, которые с модулями более 10 лет работают, сами неграмотные?
Посмотреть на Модулу-2 не в состоянии?
Или это отстой ?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, PM, Вы писали:
PM>Здравствуйте, LaptevVV, Вы писали:
PM>Вы не могли бы привести пример, когда в С++03 было проще, а в С++11 стало сложнее? Ну или от С++11 к С++14?
Сколько синтаксических способов создать объект в C++03, а сколько в C++11?
Сколько теперь конструкторов и операторов копирования нужно правильно реализовать
или объявить =default в C++03, а сколько в C++11?
Сколько перегрузок функций, методов, конструкторов добавилось из-за move семантики,
и сколько всякого bolitrate кода добавилось с std::move/std::forward ?
А эти прекрасные rvalue/glvalue/prvalue/lvalue/xvalue это ведь конечно
чудесное упрощение относительно C++03?
Здравствуйте, PM, Вы писали:
PM>А можно посмотреть на это? А то вроде бы в 2005 году явных доказательств так и не было: http://rsdn.org/forum/winapi/1142042
Здравствуйте, LaptevVV, Вы писали:
DO>>Это всё хорошо, но речь не о собственном языке и не о паскале и его наследниках, а о С++. Вы можете написать предложения и вынести их на комитет? Я, собственно, об этом. LVV>Я — пользователь языка. У меня другие работы БОЛЕЕ приоритетны, чем писать модули в С++.
Не нужно писать модули, нужно написать требования к ним.
LVV>И разработчики, которые с модулями более 10 лет работают, сами неграмотные?
Какие разработчики работают с модулями?
LVV>Посмотреть на Модулу-2 не в состоянии?
Ну посмотрели на Модулу-2 и что? Валерий Викторович, вы вот пишите:
А модулей нормальных нет до сих пор...
Какие требования к модулям в С++? Чего вы от них хотите? Почему их отсутствие мешает? Почему их наличие хорошо? Какую проблему они решат? Судя по тому, что вы пишете ответы на эти вопросы у вас уже есть, продуманные, есть видение. Чего бы его не изложить?
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, T4r4sB, Вы писали:
TB>>Строка UTF-8 надеюсь, а то как-то скучно совсем?
IID>Утф не особо сложнее. Ну перевернуть ещё каждый символ потом, определяя границы по старшим битам.
Угу, не сложнее. Но потом всякие айфоны в ребут уходят от сообщения с 'нужным' символом
Здравствуйте, LaptevVV, Вы писали:
LVV>>>>>Они каждый следующий наворот — для себя, любимых! PM>>>>У вас тоже есть шанс сделать какой-нибудь наворот, предложение к стандарту С++ может написать каждый, см. ссылку выше LVV>>>а) я — пользователь данного языка LVV>>>б) все навороты — не для среднего программиста. А именНо для метапрограммистов... PM>>Вы не могли бы привести пример, когда в С++03 было проще, а в С++11 стало сложнее? Ну или от С++11 к С++14? PM>>Лично для себя, как простого прикладного программиста, я наоборот с каждым следующим стандартом вижу упрощение. На С++14 писать проще и выразительнее, чем на С++11, а С++17 принес много полезного в стандартную библиотеку. LVV>Не-не-не... LVV>Сложнее не стало . LVV>Но навороты — не для средних программистов. LVV>Вот описывал Алесандреску списки типов. Теперь стало проще. LVV>Но списки типов — это разве пишет средний программист? LVV>Шаблоны с переменным числом параметров — эио для прикладных? LVV>forward — это для прикладных? LVV>Семантика перемещения — это, как минимум, для миддлов. LVV>И правила перегрузки усложнились. LVV>Для прикладных — auto, лямбды, таплы, и дополнения стандартной библиотеки. LVV>Которую пишут отнюдь не рядовые программеры. LVV>Вот, например, усовершенствования позволили Ивану Чукичу писать на С++ в функциональном стиле. О чем он книжку написал. LVV>Но Иван Чукич — это разве рядовой программер?
LVV>>>>>А модулей нормальных нет до сих пор... LVV>>>>>Которые Вирт еще в Модуле сделал... И в ТурбоПаскале они были... PM>>>>Ну так напишите очередное предложение, может быть оно окажется лучше предыдущих. PM>>>>Я вот собираюсь поэкспериментировать с модулями, которые войдут в С++20 LVV>>>Опять же — НАФИГА КОТУ БАЯН. PM>>Не могу понять здесь вашу позицию, модулей в языке нет или они не нужны? Уже сейчас существует их экспериментальная реализация как минимум в 2-х компиляторах, и это вероятно будет принято в следующем стандарте. Если у вас есть идея как это сделать лучше с учётом существующих и будущих ограничений, так поделитесь ей. А то может быть все те люди, которые работают больше 10 лет над модулями зря время тратят. LVV>Да потому, что Вирт уже давно все написал. А комитет в ту сторону даже не смотрит. Более 10 лет не могут модули из Модулы-2 взять — ЭТО ПЯТЬ!
Вы правда думаете, что это такая свежая мысль "А давайте возьмем модули из Модула-2 и вкорячим их в С++" ? Некий Daveed Vandevoorde начал с этого в 2004 году: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1736.pdf
Можете погуглить сколько ревизий прошло это предложение и как оно менялось.
Насколько я помню, Модула-2 обратно не совместима с Паскалем. Т.е. Вирт не стал улучшать Паскаль, и не отягощая себя обратной совместимостью сделал Паскаль 2.0, в который добавил модули. Только вот проектов, реализовнных на Модула-2 не видно, как и вакансий.
Может быть, вы сможете привести пример не учебного, промышленно используемого языка, который пережил революцию из версии N в версию N + 1 ? Я таких не знаю, ну может быть, Питону почти удалось, но это скорее эволюция.
LVV>>>Сделали свой язык для обучения и его учим. А потом переводим в С++, чтоб народ не отставал от тенденций. PM>>Переводите кому, или где? Не очень понятно. А курсовые и дипломы ваши студенты на каких языках пишут? И после выпуска чем будут пользоваться?
... LVV>На всем этом и пишут курсовые. И дипломы. LVV>Посмотрим, как пойдет Slang IDE — мож и курсовая будет на Slang.
Спасибо за информацию! Неплохо вы придумали — начинать учить первокурсников некоему слэнгу, известному только в одном университете
Здравствуйте, Zhendos, Вы писали:
PM>>Вы не могли бы привести пример, когда в С++03 было проще, а в С++11 стало сложнее? Ну или от С++11 к С++14?
Z>Сколько синтаксических способов создать объект в C++03, а сколько в C++11?
Не помню, кажется больше 20.
Z>Сколько теперь конструкторов и операторов копирования нужно правильно реализовать Z>или объявить =default в C++03, а сколько в C++11?
Вроде бы от 0 до 6 специальных функций-членов, в зависимости от назначения класса, от того, какие в нем будут данные, как вы хотите это оптимизировать.
Z>Сколько перегрузок функций, методов, конструкторов добавилось из-за move семантики, Z>и сколько всякого bolitrate кода добавилось с std::move/std::forward ?
Может быть от 0 до N, в зависимости от назначения класса, от того, какие в нем будут данные, как вы хотите это оптимизировать.
Z>А эти прекрасные rvalue/glvalue/prvalue/lvalue/xvalue это ведь конечно Z>чудесное упрощение относительно C++03?
Если вам нужен этот новый механизм, тут уж ничего не поделать — придется разбираться как оно работает. Собственно, как и с остальными частями языка, которые вы хотите использовать. Но возможность писать в стиле С++03 никуда не делась, вы по прежнему можете иметь базовое представление о lvalue/rvalue и копировать объекты вместо перемещения.
Может быть вы бы могли бы привести пример кода, который в С++03 выглядит проще и понятнее, а в С++11 стал сложнее? Ну или от С++11 к С++14, С++17?
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, landerhigh, Вы писали:
L>>Давай так — создаем чат в зуме и ты пишешь за четыре часа решение в онлайне. CC>Экий ты упорный.
Я тебя за язык не тянул. По поводу получаса неспешного тайпанья.
L>>Ты как маленький. Подобные "задачи" — отличная возможность слить кандидата. Докопаться можно до всего. CC>Если на интервью до тебя докапываются то контора не прошла собеседование, работать там не стоит. CC>Собеседование то в обе стороны работает: они смотрят на тебя, ты смотришь на них.
Как маленький, честное слово. Звонят, обещают золотые горы и кучу ништяков. Вроде интересно. Первое собеседование, второе, третье, все в экстазе и тут тебе подсовывают такую маленькую последнюю формальность. И уже времени на собеседования угробил, а тут еще рабочий день по сути нахаляву требуют.
Когда сходу требуют многочасовой тест, посылать намного проще.
Здравствуйте, LaptevVV, Вы писали:
LVV>Да мы проще поступили. LVV>Сделали свой язык для обучения и его учим. А потом переводим в С++, чтоб народ не отставал от тенденций.
А зачем свой язык сделали вместо того, что бы взять какой-нибудь из существующих? И где можно код на нём посмотреть?
Здравствуйте, Michael7, Вы писали:
M>Кхм. Если иметь ввиду практическую применимость языка под разные задачи, то с ассемблером, по-моему, наоборот. Он не очень сложный, в сущности даже примитивный, но не универсальный.
Автор сообщения имеет в виду тот факт, что при определенном знании и опыте на ассемблере можно сделать всё, что угодно.
Вот в этот то и универсальность ассемблера.
Трудозатраты на разработку, автор сообщения выносит за скобки
Здравствуйте, AlexGin, Вы писали:
AG>Автор сообщения имеет в виду тот факт, что при определенном знании и опыте на ассемблере можно сделать всё, что угодно.
Ну дык Turing complete жеж.
На любом полном языке в итоге можно будет сделать всё что угодно если все остальные нюансы вынести за скобки.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
LVV>>Да потому, что Вирт уже давно все написал. А комитет в ту сторону даже не смотрит. Более 10 лет не могут модули из Модулы-2 взять — ЭТО ПЯТЬ! PM>Вы правда думаете, что это такая свежая мысль "А давайте возьмем модули из Модула-2 и вкорячим их в С++" ? Некий Daveed Vandevoorde начал с этого в 2004 году: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1736.pdf PM>Можете погуглить сколько ревизий прошло это предложение и как оно менялось.
Спасибо. Понятно, что обратная совместимость ну просто бич для современного С++.
Давно пора от нее отказаться. PM>Насколько я помню, Модула-2 обратно не совместима с Паскалем. Т.е. Вирт не стал улучшать Паскаль, и не отягощая себя обратной совместимостью сделал Паскаль 2.0, в который добавил модули. Только вот проектов, реализовнных на Модула-2 не видно, как и вакансий.
1. Вирт много языков сделал. И никогда не был озабочен обратной совместимостью. Это — ученый, а не бизнесмен.
У него и Оберон — паскалеподобный, но совсем другой язык.
2. Вы не там ищете. У нас в космической промышленности применяют диалекты ТОЛЬКО виртовских языков.
В силу большей надежности. PM>Может быть, вы сможете привести пример не учебного, промышленно используемого языка, который пережил революцию из версии N в версию N + 1 ? Я таких не знаю, ну может быть, Питону почти удалось, но это скорее эволюция.
Я давно с фортраном дело не имел. Вполне может быть он.
Там ядерщики некоторое время назад решили отказаться от фортрана в пользу С++. Через некоторое время физики, которым пришлось осваивать С++, попровили вернуть все в зад.
Ибо они из физиков превратились в программистов.
И вместо решения своих физических задач гораздо больше времени стали тратить на отладку программ. LVV>>>>Сделали свой язык для обучения и его учим. А потом переводим в С++, чтоб народ не отставал от тенденций. PM>Спасибо за информацию! Неплохо вы придумали — начинать учить первокурсников некоему слэнгу, известному только в одном университете
Учим НЕ языку, а ПРОГРАММИРОВАНИЮ.
Разницу — понимать надо.
Сначала должны понятия усвоить, а потом нотацию.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>Да мы проще поступили. LVV>>Сделали свой язык для обучения и его учим. А потом переводим в С++, чтоб народ не отставал от тенденций. AN>А зачем свой язык сделали вместо того, что бы взять какой-нибудь из существующих? И где можно код на нём посмотреть?
Ответ PMу посмотри.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>У него и Оберон — паскалеподобный, но совсем другой язык. LVV>2. Вы не там ищете. У нас в космической промышленности применяют диалекты ТОЛЬКО виртовских языков.
Как это нужно понимать? У нас в космической промышленности применяют диалекты виртовские языкы? Это очевидно не соответствует действительности. Из всех паскалеподобных языков у нас используют только авторские диалекты от Вирта? тоже сомнительное утверждение. Тут в первую очередь нужно бы узнать, а насколько в целом паскалеобразные языки используют. И например, если их используют, то почему бы не пользоваться Дельфи или каким-нибудь ФриПаскалем, хотя бы не для бортового оборудования, а для наземных систем.
Здравствуйте, Zhendos, Вы писали:
Z>Итого кода стало больше, то есть программа сложнее, плюс одно и тоже действие Z>можно записать двумя способами, это ли не усложнение?
Плюс гемор с расставлениями noexcept, иначе это move не заработает.
Здравствуйте, LaptevVV, Вы писали:
PM>>Спасибо за информацию! Неплохо вы придумали — начинать учить первокурсников некоему слэнгу, известному только в одном университете LVV>Учим НЕ языку, а ПРОГРАММИРОВАНИЮ. LVV>Разницу — понимать надо. LVV>Сначала должны понятия усвоить, а потом нотацию.
Конечно, при обучении программированию объяснить базовые принципы и алгоритмы важнее, чем особенности какого-либо языка. Когда я учился в институте, в первом семестре для этого использовали псевдокод, похожий на Учебный алгоритмический язык, и Паскаль.
Но при использовании любого языка, в том числе и разработанного специально для учебных целей, его нотацию учить всё равно придётся. Или придуманный язык похож на Scratch и конструкции из готовых блоков собираются?
В чём особенность языка, придуманного в Астраханском университете и почему он лучше подходит для первоначального обучения, чем другие языки? Примеры кода где можно посмотреть?
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Да потому, что Вирт уже давно все написал. А комитет в ту сторону даже не смотрит. Более 10 лет не могут модули из Модулы-2 взять — ЭТО ПЯТЬ! PM>>Вы правда думаете, что это такая свежая мысль "А давайте возьмем модули из Модула-2 и вкорячим их в С++" ? Некий Daveed Vandevoorde начал с этого в 2004 году: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1736.pdf PM>>Можете погуглить сколько ревизий прошло это предложение и как оно менялось. LVV>Спасибо. Понятно, что обратная совместимость ну просто бич для современного С++. LVV>Давно пора от нее отказаться.
Можно, и тогда это будет не С++, а какой-нибудь D. Не слежу за ним, не знаю, жив ли он ещё.
Думаю, никому не нравится наслоения костылей и новых фич в языке, но и решения, устраивающего всех пока не видно
Свежее предложение про эпохи с первой попытки не прошло, однако у автора есть ещё пара лет для продвижения.
PM>>Может быть, вы сможете привести пример не учебного, промышленно используемого языка, который пережил революцию из версии N в версию N + 1 ? Я таких не знаю, ну может быть, Питону почти удалось, но это скорее эволюция. LVV>Я давно с фортраном дело не имел. Вполне может быть он. LVV>Там ядерщики некоторое время назад решили отказаться от фортрана в пользу С++. Через некоторое время физики, которым пришлось осваивать С++, попровили вернуть все в зад. LVV>Ибо они из физиков превратились в программистов. LVV>И вместо решения своих физических задач гораздо больше времени стали тратить на отладку программ.
Ну это предсказуемо, программист на Фортране пишет фортран программы на любом языке. Да и вообще, обычно код от учёных — это ужас, с программистской точки зрения. Каждый должен заниматься своим делом. Я когда-то смотрел код ROOT, проекта который обсчитывает коллайдер в Церне, так там тоже видно, что люди учёные писали.
Здравствуйте, Zhendos, Вы писали:
Z>>>А эти прекрасные rvalue/glvalue/prvalue/lvalue/xvalue это ведь конечно Z>>>чудесное упрощение относительно C++03? PM>>Если вам нужен этот новый механизм, тут уж ничего не поделать — придется разбираться как оно работает. Собственно, как и с остальными частями языка, которые вы хотите использовать. Но возможность писать в стиле С++03 никуда не делась, вы по прежнему можете иметь базовое представление о lvalue/rvalue и копировать объекты вместо перемещения.
Z>Вообще-то эти "чудесные" возможности были и в c++03, неужели вы думаете что до C++11 все были Z>настолько тупые что копировали объекты на каждый чих и только по приходу гениев из комитета, Z>все прозрели и осознали что можно оказывается не копировать объекты?
Нет, всем приходилось использовать выходные ссылочные параметры, чтобы не возвращать вектор тяжелых объектов из функции. Или засовывать некопируемый объект в умный указатель, только чтобы передавать владение этим объектом.
PM>>Может быть вы бы могли бы привести пример кода, который в С++03 выглядит проще и понятнее, а в С++11 стал сложнее? Ну или от С++11 к С++14, С++17?
Z>Так я же привел кучу примеров. Z>И по-моему очевидно что я прав и C++ с каждым стандартом становиться сложнее, Z>а как иначе если сохраняется обратная совместимость и новые конструкции только Z>прибавляются?
Да, язык становится сложнее. Я всего лишь пытаюсь донести мысль, что новые средства позволяют писать более читаемый и выразительный код.
Z>Но если вы так настаиваете давайте конкретику. Обличим мои риторические вопросы Z>в конкретный код. Z>Возьмем код состоящий из реализации аналога std::vector, назовем его V. Z>и строчки кода "двигающей" один экзампляр V в другой.
Z>В C++03: это было реализация: V и строчка типа:
Z>
Z>a.swap(b);
Z>
Z>b потом выходит из области видимости
Z>В C++11 прибавилось:
Z>1. V(V&&), V& operator=(V&&) Z>2. Появилось две возможности на выбор: Z>
Z>a = std::move(b);
Z>
Z>или старый вариант: Z>
Z>a.swap(b);
Z>
Z>Итого кода стало больше, то есть программа сложнее, плюс одно и тоже действие Z>можно записать двумя способами, это ли не усложнение?
Это разные способы для разных целей. С введением семантики перемещения мы теперь имеем возможность перемещать некопируемые объекты, например дескрипторы файлов. Это не замена обмену. В С++03 трюк с обменом обычно использовался от бедности, для возврата из функции.
Было:
void fun(std::vector<LargeOrNonCopyableClass> &out)
{
std::vector<LargeOrNonCopyableClass> result;
//generate result
out.swap(result); // exception safe way to return the result
}
Здравствуйте, Poopy Joe, Вы писали:
PJ>Есть код простой, а есть код примитивный. Так вот шаблоны позволяют писать код простой, когда читателю достаточно понимать и оперировать абстракциями. А не утруждающие себя рассуждениями пейсатели обычно фигачат код примитивный, где читателю приходится декодировать полет их мысли в километровых спагетти-простынях.
У меня был случай. Нужно было обновить сервер, добавить немного фич, но исходники потеряли)) Протокол тоже не описан. Дали исходники клиента, тогда еще в svn. Задача описать протокол и реализовать. Фактически там было две версии клинта, да рефактринга (спагетти) и после (куча мелких абстракций). Помучался я с этим высоко-абстрактным кодом и за пару часов восстановил протокол по спагетии коду с одним гигантским свитчем и кучей ифов внутри.
Здравствуйте, prog123, Вы писали:
P>Помучался я с этим высоко-абстрактным кодом и за пару часов восстановил протокол по спагетии коду с одним гигантским свитчем и кучей ифов внутри.
Человек-дизассемблер
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
LVV>>>Да мы проще поступили. LVV>>>Сделали свой язык для обучения и его учим. А потом переводим в С++, чтоб народ не отставал от тенденций. AN>>А зачем свой язык сделали вместо того, что бы взять какой-нибудь из существующих? И где можно код на нём посмотреть? LVV>Ответ PMу посмотри.
Который?
Вроде не в одном нет примера кода на вашем языке.
Здравствуйте, уважаемый LaptevVV, Вы писали:
LVV>Я С/С++ с первого издания Кернигана-Ричи знаю...
Это по чистому C (K & R standard) — есть у меня такая кинжка — из серии must have.
По C++ писал Бьярн Страуструп — и его издания также must have (настольная книга).
LVV>И работал на нем с 1989 года. LVV>Так что я знаю, о чем говорю. LVV>Кстати, и сейчас работаю. LVV>И преподаю. LVV>С точки зрения обучения начинающих программистов — там кресты, а не плюсы.
Да ладно, уважаемый профессор, в жизни у нас у каждого свой крест
LVV>Ну, а мне лично С++ нравится. LVV>Особенно после книжки Ивана Чукича о функциональном программировании на С++.
+100500
Кстати, отличная книга, спасибо за своевременную подсказку!
Здравствуйте, Reset, Вы писали:
A>>Ищет конктерный кусок, исправляет. Задача выполнена. Всё. Не надо разбираться в паттернах, изучать архитектуру. A>>Вот, я когда освоил шаблоны С++, прочитал книжку Вандевурда, и минимизировал код, то следующему было сложно. Я вывел в компайл тайм всё, что смог. А я способный. Я думаю, что человек, который это поддерживал, многое бы отдал, чтобы это был просто спагетти код. Ему хотя бы шаблоны учить не пришлось. И разгребать было бы легче.
R>Ты неверно понимаешь термин "спагетти-код".
Похоже и правда, я под ним больше понимал копи-пастный код, который тоже не слишком структурирован.
я сегодня смотрел лекторий фивт в записи апреля, лекцию по асио
который я считаю знаю не плохо
так вот
пока я не вслушивался в лектора, а смотрел картинки — было отлично
как только я переключился на то что же он там объясняет
я перестал вообще что то понимать
представляю какого было тем кому это рассказывалось
просто есть люди которым дано преподавать и писать учебные материалы
и кому то не дано
как говорится в одной пословице: умеешь программировать — пиши программы, а не умеешь — учи программировать других
чукчин может, классный и умный кодер
но книга — вода, разница со многими другими книгами других, что вода в картинках — большой прорыв
S>Был я относительно недавно на собеседовании (на позицию embedded-программиста), где меня попросили написать аналог tar'a. С лимитом по времени 4 часа. И без Qt, пожалуйста.
S>Штош, подумал я, где наша не пропадала?
S>1 час я потратил на установку boost'a (не встал, какие-то жэсточайшие ошибки, не было времени дальше копать).
S>Еще час я потратил, чтобы узнать, как кроссплатформенно открыть файл и узнать его размер. Кажется, никак, если нет С++17 c std::filesystem.
S>Последний час я из спичек и желудей лепил хоть что-нибудь.
Знакомое задание, случаем не Enapter ? Раньше такое задание давали в SpbTV.
Здравствуйте, PM, Вы писали:
PM>Здравствуйте, Zhendos, Вы писали:
Z>>И по-моему очевидно что я прав и C++ с каждым стандартом становиться сложнее, Z>>а как иначе если сохраняется обратная совместимость и новые конструкции только Z>>прибавляются?
PM>Да, язык становится сложнее. Я всего лишь пытаюсь донести мысль, что новые средства позволяют писать более читаемый и выразительный код.
Не согласен. Более выразительный противоречит читаемости. Так как намного больше происходит
под капотом и следовательно каждую строчку намного труднее понимать.
Вот вызвали функцию:
V v;
f(v);
Раньше это не могло быть проблемой. Раз код
скомпилировался, значит все ОК, либо функцию принимала по значению,
ли по ссылке и все с вызовом хорошо. А теперь она может принимать по значению
и нам больше не нужна "v", поэтому здесь ошибка и надо было "std::move(v)".
И это общая проблема C++11/14/17 и т.д., так как сохраняется обратная совместимость,
мы получаем все большую совершенно не нужную нагрузку на программиста,
который мог бы подумать о чем-нибудь еще — типа выбора более оптимального алгоритма,
улучшения архитектуры и т.д. Вместо этого он думает:
ок, нам пришла переменная типа Color, я знаю что это enum,
и мне нужно проверить красный ли цвет, как мне это написать?
color == RED или color == Color::RED,
ведь теперь знания что тип enum не достаточно, нужно знать
это enum или enum class.
Или я объявил новый класс, теперь кроме собственно нужных функций,
типа конструктора для создания экземпляра и методов нужно подумать еще
о пяти сервисных членов класса, вместо трех. Объявлять их default/delete,
писать руками и т.п.
И так с каждой возможностью, которую вводят. Все они усложняют язык и затрудняют
его использование, если их вводить не ломая и не выкидывая предыдущие возможности.
Z>>Итого кода стало больше, то есть программа сложнее, плюс одно и тоже действие Z>>можно записать двумя способами, это ли не усложнение?
PM>Это разные способы для разных целей. С введением семантики перемещения мы теперь имеем возможность перемещать некопируемые объекты, например дескрипторы файлов. Это не замена обмену. В С++03 трюк с обменом обычно использовался от бедности, для возврата из функции.
Но он много где использовался и в том числе чтобы не вызывать лишний раз аллокацию,
и переиспользовать выделенную память. Но я привел конкретный пример,
довольно странно парировать его другим примером, а же доказывал общее утверждение,
что весь написанный в C++11 стиле код стал хуже.
Здравствуйте, _Artem_, Вы писали:
_A_>Здравствуйте, Zhendos, Вы писали:
Z>>В C++11 прибавилось:
Z>>1. V(V&&), V& operator=(V&&) Z>>2. Появилось две возможности на выбор: Z>>
Z>>a = std::move(b);
Z>>
Z>>или старый вариант: Z>>
Z>>a.swap(b);
Z>>
Z>>Итого кода стало больше, то есть программа сложнее, плюс одно и тоже действие Z>>можно записать двумя способами, это ли не усложнение?
_A_>Это нифига не эквивалентный код. Объект подвергшийся операции std::move находится в валидном но неспецифируемом состоянии. То-есть, он может быть каким угодно.
А где я писал что это эквивалентный код?
Я писал что он "делает" тоже самое в контексте что для "b" скоро будет вызван деструктор.
С точки зрения написания программы мне все равно будет ли:
вызван код освобождения памяти для a, потом он будет владеть данными b,
а потом еще будет вызван деструктор для "b" которые данных нет,
но если посмотреть дизасемблер то декструктор все равно вызовется у этого:
> находится в валидном но неспецифируемом состоянии
но все согласно стандарту насколько я помню (вызов десктрутора у
"пустого" объекта).
или сначала a будет владеть данными b и наоборот, а потом будет вызван деструктор b.
Видимый результат в обоих случаях тот же самый, а с новыми фишками C++11 даже хуже
получается из-за вызова деструктора "пустого" объекта.
Здравствуйте, ViTech, Вы писали:
VT>Здравствуйте, Zhendos, Вы писали:
Z>>Я же написал:
Z>>
Z>>a.swap(b);
Z>>
Z>>При этом b выходит из области видимости
Z>>иными словами скоро вызовется деструктор b
VT>Хорошо, напишу чуть по другому: VT>
VT>V a{std::move(b)};
VT>
VT>Разницу чувствуете?
В чему разницу я должен чуствовать,
C++11 дает возможность создать alias a для объекта b.
При том как напомнили в другой ветке еще и не бесплатно,
так как будет вызван деструктор b, после того как он опустел?
Очень ценная возможность, но лучше просто использовать имя "b" в этой функции.
Здравствуйте, уважаемый Zhendos, Вы писали:
Z>Раньше это не могло быть проблемой. Раз код Z>скомпилировался, значит все ОК, либо функцию принимала по значению, Z>ли по ссылке и все с вызовом хорошо. А теперь она может принимать по значению Z>и нам больше не нужна "v", поэтому здесь ошибка и надо было "std::move(v)".
Что же мешало сделать две перегруженные функции:
1) аргумент типа константной ссылки
2) аргумент типа rvalue
тогда: хочешь сэкономить память — бери функцию с аргументом типа rvalue
но если не хочешь — просто передай "v" (всё будет работать без ошибки).
Z>И это общая проблема C++11/14/17 и т.д., так как сохраняется обратная совместимость, Z>мы получаем все большую совершенно не нужную нагрузку на программиста, Z>который мог бы подумать о чем-нибудь еще — типа выбора более оптимального алгоритма,
Синтаксис C++11/14/17 — вспонишь за секунды, а новый алгоритм или архитектуру — будешь продумывать не один день.
Z>ок, нам пришла переменная типа Color, я знаю что это enum, Z>и мне нужно проверить красный ли цвет, как мне это написать? Z>color == RED или color == Color::RED, Z>ведь теперь знания что тип enum не достаточно, нужно знать Z>это enum или enum class.
Использую (последнюю пятилетку) enum class — нет нигде никаких проблем.
Z>Или я объявил новый класс, теперь кроме собственно нужных функций, Z>типа конструктора для создания экземпляра и методов нужно подумать еще Z>о пяти сервисных членов класса, вместо трех. Объявлять их default/delete, Z>писать руками и т.п.
Зачем эти усложнения?
Компилятор всё правильно воспримет и без этих лишних телодвижений.
Z>>>Итого кода стало больше, то есть программа сложнее, плюс одно и тоже действие Z>>>можно записать двумя способами, это ли не усложнение?
Одно и то же действие несколькими способоми — это есть даже в старом добром Си
Страшного здесь ничего нет (и быть не может).
Здравствуйте, prog123, Вы писали:
P>Помучался я с этим высоко-абстрактным кодом и за пару часов восстановил протокол по спагетии коду с одним гигантским свитчем и кучей ифов внутри.
Именно такой код всегда считал спагетти. Вот здесь
Здравствуйте, reversecode, Вы писали:
R>вообще это стадия любого "говнокодера", который пол жизни багфиксит R>а потом оборачивается, и не видит результат R>а результатом кодера должен быть софт(продукт) R>а не знания С++ на 30 из 30
Продукт будет у бизнесмена. А у обычного программиста только, если он писал что-то мелкое, а потом крупная компания это раскрутила.
Вот, предположим писал человек MS Word. Продукт, как никак. Но он же не один его писал, и большую часть времени он фиксил баги. Продукт он не создавал. Поэтому сказать, что это его продукт, он не может.
Здравствуйте, Zhendos, Вы писали:
Z>Вот вызвали функцию: Z>
Z>V v;
Z>f(v);
Z>
Z>Раньше это не могло быть проблемой. Раз код Z>скомпилировался, значит все ОК,
Что, правда?
Z>либо функцию принимала по значению, Z>ли по ссылке и все с вызовом хорошо.
А по какой ссылке: константной или нет? Что будет с v после возврата из f()?
А почему вы думаете, что f -- это функция? Может это макрос. А может это вызов конструктора типа f? А даже если f -- это функция, то какая именно и из какого пространства имен (с учетом различных вариантов перегрузок)?
Вы что, правда верите в то, что в C++98 код был простой и читабельный, что стоит только посмотреть на него и все становилось понятно?
Здравствуйте, Zhendos, Вы писали:
Z>>>И по-моему очевидно что я прав и C++ с каждым стандартом становиться сложнее, Z>>>а как иначе если сохраняется обратная совместимость и новые конструкции только Z>>>прибавляются?
PM>>Да, язык становится сложнее. Я всего лишь пытаюсь донести мысль, что новые средства позволяют писать более читаемый и выразительный код.
Z>Не согласен. Более выразительный противоречит читаемости. Так как намного больше происходит Z>под капотом и следовательно каждую строчку намного труднее понимать. Z>Вот вызвали функцию: Z>
Z>V v;
Z>f(v);
Z>
Z>Раньше это не могло быть проблемой. Раз код Z>скомпилировался, значит все ОК, либо функцию принимала по значению, Z>ли по ссылке и все с вызовом хорошо. А теперь она может принимать по значению Z>и нам больше не нужна "v", поэтому здесь ошибка и надо было "std::move(v)".
Если f() может принимать аргумент по значению и v может копироваться, не вижу в чем ошибка. Когда вам больше не нужен v, вы указываете это явно. Если вы объявите f(V&&), то также станет явно видно, что функция поглощает свой аргумент, и компилятор вам сообщит об этом. По-моему читаемости и надежности прибавилось, по сравнению со неконстантными ссылками.
Z>И это общая проблема C++11/14/17 и т.д., так как сохраняется обратная совместимость, Z>мы получаем все большую совершенно не нужную нагрузку на программиста, Z>который мог бы подумать о чем-нибудь еще — типа выбора более оптимального алгоритма, Z>улучшения архитектуры и т.д. Вместо этого он думает:
Z>ок, нам пришла переменная типа Color, я знаю что это enum, Z>и мне нужно проверить красный ли цвет, как мне это написать? Z>color == RED или color == Color::RED, Z>ведь теперь знания что тип enum не достаточно, нужно знать Z>это enum или enum class.
Тут вообще не вижу проблемы — компилятор вам сообщит, если ожидается enum class. Я бы вот хотел иметь возможность сделать `using enum class Color` в какой-то области видимости, но пока это предложение не прошло (вроде бы).
Z>Или я объявил новый класс, теперь кроме собственно нужных функций, Z>типа конструктора для создания экземпляра и методов нужно подумать еще Z>о пяти сервисных членов класса, вместо трех. Объявлять их default/delete, Z>писать руками и т.п.
Или 0 до 5, в зависимости от данных и предполагаемых сценариев использования. См. "rule of zero" и "Howard Hinnant special members diagram".
Z>И так с каждой возможностью, которую вводят. Все они усложняют язык и затрудняют Z>его использование, если их вводить не ломая и не выкидывая предыдущие возможности.
Или упрощают. Я теперь могу писать range-based loops в шаблонных функциях без шума в виде `typename contanerTemplate<MyTemplateType>::const_iterator`
Z>>>Итого кода стало больше, то есть программа сложнее, плюс одно и тоже действие Z>>>можно записать двумя способами, это ли не усложнение?
PM>>Это разные способы для разных целей. С введением семантики перемещения мы теперь имеем возможность перемещать некопируемые объекты, например дескрипторы файлов. Это не замена обмену. В С++03 трюк с обменом обычно использовался от бедности, для возврата из функции.
Z>Но он много где использовался и в том числе чтобы не вызывать лишний раз аллокацию, Z>и переиспользовать выделенную память. Но я привел конкретный пример, Z>довольно странно парировать его другим примером, а же доказывал общее утверждение, Z>что весь написанный в C++11 стиле код стал хуже.
Ясно. Я не согласен с общим утверждением, что "раньше было лучше, язык стал хуже". Мое мнение — многие вещи стало проще сделать, но из-за обратной совместимости приходится сохранять все предыдущие способы отстрелить себе ногу. Легкого решения здесь нет, языку приходится эволюционировать, накапливая рудименты. Пока С++ с этим как-то справляется, посмотрим лет через 5.
Здравствуйте, σ, Вы писали:
PM>>Вы похоже путаете правительство, которое на другой планете, с людьми из комитета. Вся информация по его работе находится в открытом доступе.
σ>Засекреченные стенограммы заседаний и мейл-листы не очень похожи на "отрытый доступ".
Действительно, теперь вроде результаты заседаний становятся доступны спустя какое-то время. Может быть, это особенности процесса разработки?
Я не очень внимательно слежу на последними новостями в развитии С++, но обычно можно без проблем узнать что нового планируется, уже одобрено, или отклонено — некоторые участники заседаний пишут об этом на reddit/cpp
Здравствуйте, Zhendos, Вы писали:
VT>>Хорошо, напишу чуть по другому: VT>>
VT>>V a{std::move(b)};
VT>>
VT>>Разницу чувствуете?
Z>В чему разницу я должен чуствовать, Z>C++11 дает возможность создать alias a для объекта b. Z>При том как напомнили в другой ветке еще и не бесплатно, Z>так как будет вызван деструктор b, после того как он опустел? Z>Очень ценная возможность, но лучше просто использовать имя "b" в этой функции.
Разницу в том, что для a.swap(b) нужно, чтобы объект а уже существовал, в то время как с помощью V a{std::move(b)} можно передать ресурсы в новый, создаваемый объект.
Здравствуйте, Dym On, Вы писали:
S>>А вообще, граждане, имеющие настолько мало самоуважения, чтобы после 17 лет опыта писать тестовые задания, должны страдать. DO>Какой на фиг КСВ? DO>
лет 17, это почти две трети моей жизни
DO>Чуваку 25, у него еще юношеский максимализм не прошел.
Т.е. он пишет на плюсах и "читает пропозалы" с 8 лет. Ок.
Здравствуйте, zou, Вы писали:
zou>По опыту, программистам "начинающего" уровня свойственно придавать важное значение
Не то что начинающего, а просто нужно признать, что, во-первых, генетически интеллектуальные возможности у всех разные. Во-вторых, не у всех были возможности получить образование — кто-то учился сам как мог, в свободное от работы время.
По этому есть кодеры — не в полной мере программисты. Их задача — закодить, но сделать это с соблюдением всех стандартов и пр. Работа оплачивается ниже, значимость ниже — но пока такие люди нужны.
Здравствуйте, Тёмчик, Вы писали:
S>>Статья вышла в топ: https://habr.com/ru/post/497114/ Так же комменты доставляют:
Тё>На сипипи давно уже никто в здравом уме не начинает проекты. Только лютый кал мамонта, который переписать на жаву дороже, так и мучаются сектанты-мазохисты, пока их вместе с продуктом не выкинут на свалку истории.
Тогда вы сильно недооцениваете количество находящихся "не в здравом уме".
Здравствуйте, kaa.python, Вы писали:
Тё>>На сипипи давно уже никто в здравом уме не начинает проекты. Только лютый кал мамонта, который переписать на жаву дороже, так и мучаются сектанты-мазохисты, пока их вместе с продуктом не выкинут на свалку истории.
KP>Давай скажем честно, у вас почти вся серьезная разработка давно ноги сделала, а та что осталась... тебя туда просто не пускают
Давай скажем честно, те проекты, где мы с тобой работали, зачинались в 1995г. Уже в 2007г новые проекты зачинались на более других языках.
Здравствуйте, Тёмчик, Вы писали:
Тё>На сипипи давно уже никто в здравом уме не начинает проекты. Только лютый кал мамонта, который переписать на жаву дороже, так и мучаются сектанты-мазохисты, пока их вместе с продуктом не выкинут на свалку истории.
Тоже на плюсах проекты начинал недавно. Соседняя команда переписывает проект с C# на C++, часть шарпистов при этом переучиваются. Работает быстрее, кода меньше — профит.
Надо сказать, что в конторе есть специалисты и проекты на многих языках, в одной проекте есть C++, С# и JS. У всех своя ниша, но плюсы тут не уступают, а, скорее, доминируют. И дело не в криворукости или пряморукости, просто быстрый код на плюсах писать легче. И зачастую кроссплатформенный: GUI со сложной визуализацией, выводом видео и других штук проще написать на Qt, местами переходя на OpenGL и что-то на шейдерах. Хоть у нас и не embedded, хотя там тоже Qt безоговорочный лидер в плане GUI. Не говорю уже про логику и вычисления.
Здравствуйте, Тёмчик, Вы писали:
Тё>На сипипи давно уже никто в здравом уме не начинает проекты. Только лютый кал мамонта, который переписать на жаву дороже, так и мучаются сектанты-мазохисты, пока их вместе с продуктом не выкинут на свалку истории.
Здравствуйте, Тёмчик, Вы писали:
Тё>Открой для себя, что css давно уже крутится на gpu в современных браузерах. и нейросетки есть на js- ускоренные на gpu, в браузере. Так что может быть у вас сильные люди в плане математики, но слабые как программисты.
Есть-то оно много где, но что толку? И на Питоне есть тоже, на котором мы сетки обучаем. Кстати, я никогда не видел ни TensorRt, ни OpenVINO через js. И как-то не нагуглилось сходу. И так совпало, что эти оба фреймворка написаны на С++, общался на конференциях с их авторами. Говорят, что только на плюсах есть все ручки к ним, на Питоне доступно не всё. Ну и кастомные слои всё равно на CUDA дописывать.
Далее, запускаем мы, например, на Jetson Xavier NX свою нейронку — там сразу для 4-х видеоканалов. Тут для скорости всего 2 варианта: либо плюсовый DeepStream, либо плюсовый же TensorRT, декодировать кадры на кастомном ffmpeg (оригинального там нет, а есть глючноватый gstreamer). Всё что на Питоне работает раза в 2 медленнее и официальная позиция Nvidia — писать на С++.
Со стороны кажется, что всё это есть и на других языках, но оно и работает медленнее, и глючит в непонятных местах.
Про визуализацию спорить не буду, потому что ты не написал, как на js в браузере писать свои шейдеры для OpenGL. У меня, кстати, был опыт работы с картой на js: на неё надо было в реальном времени накладывать кадры с коптера при движении по маршруту. Это работало ооочеееень мееедлеееено, с периодическими зависаниями и жором памяти, что на полевых ноутах типа Getac или Panasonic toughbook выливалось в фактическую неработоспособность софта. Тот же Qt на порядок быстрее.
Здравствуйте, Nuzhny, Вы писали:
Тё>>Открой для себя, что css давно уже крутится на gpu в современных браузерах. и нейросетки есть на js- ускоренные на gpu, в браузере. Так что может быть у вас сильные люди в плане математики, но слабые как программисты.
N>Есть-то оно много где, но что толку? И на Питоне есть тоже, на котором мы сетки обучаем. Кстати, я никогда не видел ни TensorRt, ни OpenVINO через js. И как-то не нагуглилось сходу. И так совпало, что эти оба фреймворка написаны на С++, общался на конференциях с их авторами. Говорят, что только на плюсах есть все ручки к ним, на Питоне доступно не всё. Ну и кастомные слои всё равно на CUDA дописывать. N>Далее, запускаем мы, например, на Jetson Xavier NX свою нейронку — там сразу для 4-х видеоканалов. Тут для скорости всего 2 варианта: либо плюсовый DeepStream, либо плюсовый же TensorRT, декодировать кадры на кастомном ffmpeg (оригинального там нет, а есть глючноватый gstreamer). Всё что на Питоне работает раза в 2 медленнее и официальная позиция Nvidia — писать на С++.
На чистом питоне делать- то ещё извращение, но если его использовать как клей, то тормозов нет. Позиция NVidia что только на C++ — ну вот и ответ. Кто виноват, что NV проталкивает только C++? Вот тебе tensorjs https://www.tensorflow.org/js.
N>Со стороны кажется, что всё это есть и на других языках, но оно и работает медленнее, и глючит в непонятных местах.
Если вы завязались на tensorrt и позиция разработчика tensorrt — педалить на C++, ну педальте на C++. Или сделайте слой и вызывайте из питона. Но с какого перепуга QT? Это ж гуя. Десктоп(!). Ребята, вы там в 1995г застряли что-ли? Веб и облака прошли мимо?
N>Про визуализацию спорить не буду, потому что ты не написал, как на js в браузере писать свои шейдеры для OpenGL. У меня, кстати, был опыт работы с картой на js: на неё надо было в реальном времени накладывать кадры с коптера при движении по маршруту. Это работало ооочеееень мееедлеееено, с периодическими зависаниями и жором памяти, что на полевых ноутах типа Getac или Panasonic toughbook выливалось в фактическую неработоспособность софта. Тот же Qt на порядок быстрее. https://webgl-shaders.com/wave-example.html
N>Так что дьявол в деталях.
Просто надрочились на C++ и гребёте, в то время как есть более продуктивные языки.
Здравствуйте, so5team, Вы писали:
Тё>>Так это всё камешки в огород сипипи Тё>>Реалтаймовые системы не на плюсах делают.
S>Артём, вы это сейчас всерьез, в здравом уме и трезвой памяти? Вот на полном серьезе утверждаете, что real-time не пишут на C++?
S>Или уже успели бухнуть после рабочего дня?
Да не, это он так, чтобы срач развести разговор поддержать
Откуда у антиподов возьмутся проекты на плюсах? Всё RnD оттуда разбежалось еще лет 15 назад.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Тёмчик, Вы писали:
Тё>>>Реалтаймовые системы не на плюсах делают.
S>>Артём, вы это сейчас всерьез, в здравом уме и трезвой памяти? Вот на полном серьезе утверждаете, что real-time не пишут на C++? Тё>Ну особо упоротые, конечно, и STL в ядро запихивают (реальный случай кстати, чел на полном серьёзе предлагал зафигачить в виндовый драйвер C++ с STL-м).
S>>Или уже успели бухнуть после рабочего дня? Тё>Что, попка пригорело?
Артём, во-первых, ваша боль по поводу C++ непонятна. Объяснять причину оной вы не хотите, да и ладно.
Но, во-вторых, вы не ответили на простой и прямой вопрос. Итак: вы это всерьез про рилтайм и C++?
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Откуда у антиподов возьмутся проекты на плюсах? Всё RnD оттуда разбежалось еще лет 15 назад.
Не путайте аутсорснутый кал мамонта в Индию и в РФ с стартапами. Стартапы здесь появляются и FAANGи частично представлены.
Сравните вот Атлассиан, который JS, Java и за всё прогрессивное, Revenue: 1.6 billion USD (July 2020)
И Касперский, который С++, антивирус на Шиндоуз, Revenue: US$ 685 million (2019)
Здравствуйте, so5team, Вы писали:
Тё>>>>Реалтаймовые системы не на плюсах делают.
S>>>Артём, вы это сейчас всерьез, в здравом уме и трезвой памяти? Вот на полном серьезе утверждаете, что real-time не пишут на C++? Тё>>Ну особо упоротые, конечно, и STL в ядро запихивают (реальный случай кстати, чел на полном серьёзе предлагал зафигачить в виндовый драйвер C++ с STL-м).
S>>>Или уже успели бухнуть после рабочего дня? Тё>>Что, попка пригорело?
S>Артём, во-первых, ваша боль по поводу C++ непонятна. Объяснять причину оной вы не хотите, да и ладно.
S>Но, во-вторых, вы не ответили на простой и прямой вопрос. Итак: вы это всерьез про рилтайм и C++?
При желании, можно и писюн сломать. Так вот, делать реалтайм на C++ с его динамическим распределением памяти, фрагментацией памяти, и непредсказуемыми исключениями, от небольшого ума.
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, Shmj, Вы писали:
S>>Статья вышла в топ: https://habr.com/ru/post/497114/ Так же комменты доставляют:
Тё>На сипипи давно уже никто в здравом уме не начинает проекты. Только лютый кал мамонта, который переписать на жаву дороже, так и мучаются сектанты-мазохисты, пока их вместе с продуктом не выкинут на свалку истории.
Эта тема в мая заглохла. Ты с чего вдруг поднять её решил?
Здравствуйте, Nuzhny, Вы писали:
N>Это же совсем не то, я же другое спрашивал. И Питон тормозит и будет тормозить. Просто мы говорим о разном: мне важна миллисекунда, а тебе и десяток или сотня не так уж. Для некоторых алгоритмов вообще счёт на сотни микросекунд и ватты энергии считаются. Типа, терять минуты полёта коптера никто не хочет, если он и так не более 40 может в воздухе держаться (а зимой и того меньще).
Ещё раз. Если питон использовать как клей- ничего там не тормозит. Алгоритмы нужно прокачивать. От того, что ты написал пузырёк на C++ а не на питоне- софт быстрым не станет.
Тё>>Просто надрочились на C++ и гребёте, в то время как есть более продуктивные языки.
N>Так выбора нет. Где есть, там на Питончике пишем и не жужжим. Твой js по ссылке — это хрень, прости за откровенность. Мы выводим десяток видео на экран, обрабатываем их шейдерами и рисуем поверх. Твой пример грузит видеокарту на 100% и выдаёт жалких 40 fps. Блин, о таких тормозах я и говорю. Не хочу писать такой галимый софт, на который будут пользователи плеваться.
Пример что я нагуглил- это шейдеры На моём 4k экране оно упирается в 60fps. Ибо шейдеры загружены в карту, прямо с веб странички. Может, у кого-то карта говно, или браузер ie?
Здравствуйте, Тёмчик, Вы писали:
Тё>Ещё раз. Если питон использовать как клей- ничего там не тормозит. Алгоритмы нужно прокачивать. От того, что ты написал пузырёк на C++ а не на питоне- софт быстрым не станет.
Нет, не так. Мы сейчас говорим не про алгоритмы, а про написание софта для решения определённых задач. Типа декодировать видео, подать кадр на вход нейросети, получить результат. Казалось бы всё просто — используй Питон как клей, а всё остальное делают библиотеки. Но внезапно окажется, что на твоём языке-клее кадр декодируется, копируется в оперативную память, потом из YUV конвертируется в RGB, потом он нормируется и раскладывается на слайсы по цветовым каналам. А можно декодировать на GPU, декодированный кадр в YUV не копировать в оперативку и не переводить в RGB, а сразу написать функцию на CUDA, которая оставаясь в пределах видеопамяти сконвертирует во входной тензор из YUV в правильный формат для нейросети. Но такое низкоуровневое API доступно исключительно из C++. Да, мы напишем не 5 строк на Питоне, а 200 строк на С++ (или даже 500 строк на С++ и 100 строк на CUDA), но наш софт будет работать быстро, без фризов, укладываться во все временные рамки и потреблять меньше памяти. И потом также окажется, что наши коптеры летают дольше и при этом ещё и выполняют больше.
Это нормальная работа для программиста, ничего особенного и без пузырьковых сортировок при этом.
N>>Так выбора нет. Где есть, там на Питончике пишем и не жужжим. Твой js по ссылке — это хрень, прости за откровенность. Мы выводим десяток видео на экран, обрабатываем их шейдерами и рисуем поверх. Твой пример грузит видеокарту на 100% и выдаёт жалких 40 fps. Блин, о таких тормозах я и говорю. Не хочу писать такой галимый софт, на который будут пользователи плеваться. Тё>Пример что я нагуглил- это шейдеры На моём 4k экране оно упирается в 60fps. Ибо шейдеры загружены в карту, прямо с веб странички. Может, у кого-то карта говно, или браузер ie?
Так я и говорю. Будет эксплуататор с дохлым ноутом в поле (а защищённые ноуты все дохлые, потому что сложно сделать нормальную вентиляцию и охлаждение) смотреть на слайд-шоу и проклинать разработчиков. Оно мне надо? Оно надо этим людям, которым и так нелегко? Никому не надо. В кресле с игровым компом под столом можно писать и на js, я не против — пиши.
Здравствуйте, LaptevVV, Вы писали:
LVV>Там ядерщики некоторое время назад решили отказаться от фортрана в пользу С++. Через некоторое время физики, которым пришлось осваивать С++, попровили вернуть все в зад.
Это они не настоящие ядерщики. Будь они настоящие ядерщики, после такого решения "через некоторое время" уже бы и не настало.
Здравствуйте, Тёмчик, Вы писали:
Тё>Ещё раз. Если питон использовать как клей- ничего там не тормозит. Алгоритмы нужно прокачивать. От того, что ты написал пузырёк на C++ а не на питоне- софт быстрым не станет.
Здравствуйте, landerhigh, Вы писали:
L>Причем в Вебе
В АУ на столько все плохо с работой? А то я смотрю, ты уехал, mik1 уехал, SkyDance уехал... в купе с откровениями Артема приходишь к мысли что там если не JS, то только лапу сосать.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Ты намеренно или по невнимательности предлагаешь использовать попсовый айпад про вместо защищенного ноута?
Нет ну если начальство сказало- защищенный ноут 800x600 на чахлом атоме и форточке, тогда конечно защищенный ноут. А реально, с точки зрения не отягощенного указанием сверху, простого юзера- ведь 13'' ipad pro или самсунг топовый, ведь предпочтительнее.
Здравствуйте, Тёмчик, Вы писали:
Тё>Почему упор на "копируется в оперативную память, потом из YUV конвертируется в RGB, потом он нормируется и раскладывается на слайсы по цветовым каналам. А можно декодировать на GPU"? Я же постоянно повторяю- тупо делать на C++, всё равно будет тормозить. Нужно избегать копирования из/в видео память, кроме как когда уже совсем никак. Это же азы программирования графики у игроделов. Вот и использовать питон, чтобы из него заряжать CUDA. Только CUDA imho сейчас не очень- заточено на NVidia. Что там из открытых стандартов сейчас актуально?
Я как раз и говорю, что с Питоном ты не сможешь избежать всех этих долгих шагов по лишним конвертациям и копированиям. Просто в библиотеках нет такого API для Питона. Ни в ffmpeg, ни в условном TensorFlow или в TensorRT. Аналогичное верно и не для Nvidia, я не настаиваю. Суть в том, что с Питоном никто не заморачивается, а делают как ты и описываешь — 5 строк и программа работает. Кого-то устраивает, им хватает. Я не завязываюсь на конкретное железо, а оптимизирую программу под всё железо, на котором оно может работать.
Тё>Я видел кучу плюсников в России, лепящих пузырёк на ровном месте, и считающих себя богами. Ведь они пишут на C++.
Ох уж эти мифические программисты! Мы сейчас говорим о принципиальных вещах. Не даром всё высокопроизводительное пишется на плюсах. Типа, тупо нет выбора. Даже в драйвере любой видеокарты есть набор алгоритмов, которые обрабатывают картинку прежде чем вывести её на экран. Что плейеры, что ютьюб работают через multimedia driver. Что он попутно делает? Убирает шумы видео, убирает шумы кодека, делает цветокоррекцию и много чего ещё. Какая мощная бы не была у тебя видеокарта, всё равно при разработке этих алгоритмов считается всё до мелочей. Твой алгоритм работает 400 микросекунд? А сколько там операций? Теоретически должен работать за 300 и потребрять столько-то Ватт энергии — переделывай. Вот до чего доходит, а потом на этих видеокартах просматривается миллионы часов видео, экономится огромное чисто энергии и ноутбуки работают чуть подольше.
И так делают не только драйверописатели, но и разработчики низкоуровневых библиотек, видео и фоторедакторов, плейеров, браузеров. Разработчики программ, которые выполняются на устройствах с батарейками, а не от сети.
N>>Так я и говорю. Будет эксплуататор с дохлым ноутом в поле (а защищённые ноуты все дохлые, потому что сложно сделать нормальную вентиляцию и охлаждение) смотреть на слайд-шоу и проклинать разработчиков. Оно мне надо? Оно надо этим людям, которым и так нелегко? Никому не надо. В кресле с игровым компом под столом можно писать и на js, я не против — пиши. Тё>А предложите вашим "эксплуататорам" воспользоваться айпадом про. И там всё плавненько в вебе полетит- вот будет облом C++ дрочерам.
Очень смешно, ха-ха. Тебе надо найти работу, где делают продукты не только для офиса. Реально.
N>Да, а ещё iPad будет намного легче и тоньше. Но без клавиатуры. Блин, им могут пользоваться суровые мужики-нефтянники, когда осматривают трубопровод где-нибудь в Сибири.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, Тёмчик, Вы писали:
Тё>>Почему упор на "копируется в оперативную память, потом из YUV конвертируется в RGB, потом он нормируется и раскладывается на слайсы по цветовым каналам. А можно декодировать на GPU"? Я же постоянно повторяю- тупо делать на C++, всё равно будет тормозить. Нужно избегать копирования из/в видео память, кроме как когда уже совсем никак. Это же азы программирования графики у игроделов. Вот и использовать питон, чтобы из него заряжать CUDA. Только CUDA imho сейчас не очень- заточено на NVidia. Что там из открытых стандартов сейчас актуально?
N>Я как раз и говорю, что с Питоном ты не сможешь избежать всех этих долгих шагов по лишним конвертациям и копированиям. Просто в библиотеках нет такого API для Питона. Ни в ffmpeg, ни в условном TensorFlow или в TensorRT.
Здравствуйте, kaa.python, Вы писали:
KP>В АУ на столько все плохо с работой? А то я смотрю, ты уехал, mik1 уехал, SkyDance уехал... в купе с откровениями Артема приходишь к мысли что там если не JS, то только лапу сосать.
Там что-то непонятное с экономикой сейчас в целом.
Здравствуйте, Тёмчик, Вы писали:
Тё>Каких и почему выбрали C++? Крыша протекла от сидения в карантине, или какие-то обьективные причины? Чем node не подошёл?
Я работаю в проекте, где железка в автомобиле получает данные и выдаёт другие данные. node не подошёл — всем.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Троль 80lvl запускает тему и смотрит, как другие колошматят друг друга виртуальными табуретками. SVZ>А ты создал тему, где все пинают тебя и ржут с комментов Надо работать над собой!
Ты до сих пор не понял? Артёмка ж тот самый "тролль" из анекдота "а я стою и кланяюсь"
Ему внимание к своей персоне надо.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, kaa.python, Вы писали:
KP>>У тебя явно был тяжёлый день. Заставили странички за украинцами рефакторить?
L>С собеседования в Амазон выгнали, наверное.
в образование вылодили вопросы с собеседования в Амазоне
народ второй день обсуждает, что не корелируеться с 40 минт которые дают на эти задачки
Здравствуйте, Nuzhny, Вы писали:
S>>а как же https://github.com/kkroening/ffmpeg-python
N>Так себе. Я, скорее, про такое говорю — tensor-stream. Чтобы питонисты могли что-то сделать надо написать код на C++ и CUDA. Тогда зачем нужен Питон?
Ну, да. Чтобы в Питоне что-то заработало, пришлось написать кучу кода на С++ и CUDA. Я же об этом и говорю, что из Питона изначально ничего не доступно. Практически только из плюсов всё и доступно по факту. И это кусочек айсберга: потом понадобится нормальная многопоточность, понадобятся более сложные нестандартные алгоритмы — всё это будет писаться на С++.
Например, трекинг, близкая мне тема. Работа с графами пишется на С++, а пример использования на Питоне. Ещё пример, более современный и сложный: С++ и Матлаб. Вся сложная и тяжёлая логика, все алгоритмы, вся низкоуровневая работа — это С++. И такие проекты пишут пачками не только одиночки. Выше был такой же Tensor-stream. Nvidia свой TensorRT и DeepStream, Интел свой OpenVINO — всё это плюсовое, а на Питончике примеры и тесты. Мы также пишем. А в продакшене выкидываются питоновские кусочки и тесты и всё на С++. Без плюсов многого в принципе не напишешь, это пока такая данность.
Одноклассники, например, пишут нижний код также на с++, а верхний на Scala.
У Фейсбука сложные алгоритмические штуки типа faiss на плюсах. У Дропбокса кодеки пишутся на плюсах (например, lepton), а что-то они пробовали на Расте (brotli).
Я могу долго перечислять. Это и есть одна из текущих ниш плюсов — сложные высокопроизводительные вещи. В моей области они такие, у кого-то это драйвера или браузеры.
Здравствуйте, Тёмчик, Вы писали:
N>>Могут, конечно. Но причёт тут DJI? Тё>DJI- лидер в производстве дронов, в томчисле профессиональные с 3/4 сменными линзами. У них софт под ipad. А гос контора обязательно под Шиндоуз делает, чтоб с клавиатурой. Тё>Похоже что ниасилили ios, как и ниасилили за пределы Qt выйти.
Вообще-то не госконтора, всё больше под Астру Линукс, но Винда тоже есть, да. Клавиатура нужна в большинстве случаев, яркий экран нужен, защищённость нужна. ПО наше работает и на планшетах, кстати, но тоже защищённых. У жены есть ipad 13 pro для рисования — очень хрупкая и нежная штука. Я не понимаю, с чем ты пытаешься спорить: есть стандарты в отрасли, есть климатические условия. Те же нефтянники по экологическим требованиям обязаны 2 раза в неделю контролировать визуальную целостность своей трубы, а также им хочется знать, что никто в неё не врезался. Вообще страна у нас большая, условия разные, времена года, температура, осадки. Айпады и dji — это хорошие гламурные штуки, продуманные и предназначенные для своей ниши. Но они многого не могут, что тут поделаешь.
Здравствуйте, Тёмчик, Вы писали:
Тё>Я видел кучу плюсников в России, лепящих пузырёк на ровном месте, и считающих себя богами. Ведь они пишут на C++.
Программисты на джаве лепят паттерн на паттерн ради "Hello world!" и считают себя богами. Ведь они пишут на джаве. И?
Здравствуйте, kaa.python, Вы писали:
KP>В АУ на столько все плохо с работой?
Смотря с какой... Но в целом — что ты хочешь от деревни размером с континент?
KP>в купе с откровениями Артема
А что Артём? Всем не дано быть супер-профи. Основа профессии — середняки разной степени вменяемости типа меня или Артёма.
Здравствуйте, Nuzhny, Вы писали:
N>Ну, да. Чтобы в Питоне что-то заработало, пришлось написать кучу кода на С++ и CUDA.
Чтобы в C++ что-то заработало, пришлось написать кучу кода на asm и VERILOG.
N> Я же об этом и говорю, что из Питона изначально ничего не доступно. Практически только из плюсов всё и доступно по факту. И это кусочек айсберга: потом понадобится нормальная многопоточность, понадобятся более сложные нестандартные алгоритмы — всё это будет писаться на С++. N>Например, трекинг, близкая мне тема. Работа с графами пишется на С++, а пример использования на Питоне. Ещё пример, более современный и сложный: С++ и Матлаб. Вся сложная и тяжёлая логика, все алгоритмы, вся низкоуровневая работа — это С++. И такие проекты пишут пачками не только одиночки. Выше был такой же Tensor-stream. Nvidia свой TensorRT и DeepStream, Интел свой OpenVINO — всё это плюсовое, а на Питончике примеры и тесты. Мы также пишем. А в продакшене выкидываются питоновские кусочки и тесты и всё на С++. Без плюсов многого в принципе не напишешь, это пока такая данность. N>Одноклассники, например, пишут нижний код также на с++, а верхний на Scala.
Ну так я что, с этим спорю? Да, узкие места расшивать на C (или C++, если оченно хочется именно плюсы). Это всё узкие ниши, много народа туда не требуется. Гугл написал tensor flow к примеру, и все её вызывают из питона.
Здравствуйте, _ABC_, Вы писали:
Тё>>Я видел кучу плюсников в России, лепящих пузырёк на ровном месте, и считающих себя богами. Ведь они пишут на C++. _AB>Программисты на джаве лепят паттерн на паттерн ради "Hello world!" и считают себя богами. Ведь они пишут на джаве. И?
Нет такого у жавистов. Скорей, много плюсников недорасло до паттернов. Как и до алгоритмов тоже. Я не говорю за всех, но изрядная часть считают себя богами просто за то, что занимается секасом с нечитабельными шаблонами в полэкрана.
Здравствуйте, Nuzhny, Вы писали:
Тё>>DJI- лидер в производстве дронов, в томчисле профессиональные с 3/4 сменными линзами. У них софт под ipad. А гос контора обязательно под Шиндоуз делает, чтоб с клавиатурой. Тё>>Похоже что ниасилили ios, как и ниасилили за пределы Qt выйти.
N>Вообще-то не госконтора, всё больше под Астру Линукс, но Винда тоже есть
Все продукты Astra Linux входят в реестр Минкомсвязи России. Их используют крупные предприятия, государственные корпорации, министерства и структуры
N>Айпады и dji — это хорошие гламурные штуки, продуманные и предназначенные для своей ниши. Но они многого не могут, что тут поделаешь.
Главное, что они не могут- не прошли сертификацию ФСБ. Фактически, ваши дроны существуют в экосистеме импортозамещения. И не надо говорить, что они лучше чем DJI- когда ваши дроны будут покупать не из-за прямого требования министерств покупать именно у вас, а не у DJI, тогда и можно будет рассуждать, что ваши дроны могут такого, что не могут DJI.
Здравствуйте, kaa.python, Вы писали:
KP>В конце 2000-х, когда мы в Инфотексе работали, он был реально хороший С++ разработчик, сильно выше среднего.
Ну, ОК.
Скрывает, значит, тщательно. Наверное, есть причины для этого, будем уважать его решение.
KP>А ты так вообще прибедняешься. Разве не тебя на позицию архитектора (или около того) в Австралию перевезли?
Меня. Только это немного в прошлом уже...
Здравствуйте, kaa.python, Вы писали:
KP>был реально хороший С++ разработчик,
Спасибо, но не перехваливай
KP> по причини сложности с поиском хорошей работы в АУ, что вынуждает корпеть над примитивом в виде JS, пишет странные вещи
Ну а почему ты считаешь JS примитивом? Кстати, я не знаю JS- мы пишем на TS довольно сложный UI, с кучей бизнес-правил. Там наворотов больше, чем было на всех прошлых моих UI- х проектах. И бэкенд время от времени делаю фичи- облака, жава, алгоритмы. Да, приходят потом в мой код добавлять фич, случается адский песец, ну что, не все могут расширять мой гениальный код. Мне только clojure не хватает в проде до полного оргазма. А C++ что- ничего сложного там нет, но, к сожалению, адекватные компании с него ушли. Остались только HFT, где никак без него, да альтернативно одаренные единичные случаи. Мне интересен результат, дизайн приложения, алгоритмы, а что это жава или C++ — пофиг. TS нравится больше кратостью.
Здравствуйте, Тёмчик, Вы писали:
Тё>Ну а почему ты считаешь JS примитивом? Кстати, я не знаю JS- мы пишем на TS довольно сложный UI, с кучей бизнес-правил. Там наворотов больше, чем было на всех прошлых моих UI- х проектах.
Всё что видел в UI — это примитив с акцентом на то, как хорошо ты знаешь ту или иную библиотеку.
Тё>И бэкенд время от времени делаю фичи- облака, жава, алгоритмы. Да, приходят потом в мой код добавлять фич, случается адский песец, ну что, не все могут расширять мой гениальный код. Мне только clojure не хватает в проде до полного оргазма.
Бэк, если это не CRUD, что по сути даже хуже чем UI из за своей однообразности, это безусловно сильно веселее. Но бэк, обычно, это ни JS ни TS.
Здравствуйте, kaa.python, Вы писали:
KP>Бэк, если это не CRUD, что по сути даже хуже чем UI из за своей однообразности, это безусловно сильно веселее.
Вот не соглашусь. Всё наскучивает. Мне хорошо, когда одно попилил, потом другое.
KP>Но бэк, обычно, это ни JS ни TS.
Как же node. Я бы с радостью заменил жаву на TS на бэкенде.
Здравствуйте, Тёмчик, Вы писали:
Тё>Вот не соглашусь. Всё наскучивает. Мне хорошо, когда одно попилил, потом другое.
Навеное, так и в правду веселее может быть. Правда на выходе 20 лет опыта которые не совсем 20, а 5 раз по 4 и все смотрят как на вечного мидла, но, не могу сказать что это плохо
Тё> Как же node. Я бы с радостью заменил жаву на TS на бэкенде.
Здравствуйте, kaa.python, Вы писали:
KP>Навеное, так и в правду веселее может быть. Правда на выходе 20 лет опыта которые не совсем 20, а 5 раз по 4 и все смотрят как на вечного мидла, но, не могу сказать что это плохо
Ну если устраиваться в контору низовым исполнителем, тогда да. Такое на аутсорсе обычно ищут, ну либо если джун. А умение самостоятельно решать проблемы в своей предметной области подразумевает умение обучаться новым инструментам, в последние годы ещё добавились требования настраивать с облачные сервисы, например.
Тё>> Как же node. Я бы с радостью заменил жаву на TS на бэкенде.
KP>На Go надо менять
Да что-то как-то про Go нелестные отзывы, в том числе от тебя... Что-то там ниасилили.
Здравствуйте, sergey2b, Вы писали:
S>в образование вылодили вопросы с собеседования в Амазоне S>народ второй день обсуждает, что не корелируеться с 40 минт которые дают на эти задачки
Нужно понимать, что собеседователи в Амазон не имеют цели нанять кого-то. Среди них тоже есть условные Артемы, которым главное — почесать ЧСВ.
Поэтому обсуждать задачи можно, но нужно понимать, что даже правильное решение может вообще не иметь ничего общего с тем, что данный конкретный собеседователь имел в виду.
N>>Айпады и dji — это хорошие гламурные штуки, продуманные и предназначенные для своей ниши. Но они многого не могут, что тут поделаешь. Тё>Главное, что они не могут- не прошли сертификацию ФСБ. Фактически, ваши дроны существуют в экосистеме импортозамещения. И не надо говорить, что они лучше чем DJI- когда ваши дроны будут покупать не из-за прямого требования министерств покупать именно у вас, а не у DJI, тогда и можно будет рассуждать, что ваши дроны могут такого, что не могут DJI.
Темка, мой сотрудник недавно свалил на должность принципала как раз в ДЖИ в шеньженьский офис. Не поверишь, у них там все на ++, без жс и пхп. А на куде/сл вообще все самописное без тф и прочего. Ниасилили (((
Здравствуйте, Nuzhny, Вы писали:
N>Тоже на плюсах проекты начинал недавно. Соседняя команда переписывает проект с C# на C++, часть шарпистов при этом переучиваются. Работает быстрее, кода меньше — профит.
Здравствуйте, AleksandrN, Вы писали:
KP>>>Да, приходят потом в мой код добавлять фич, случается адский песец, ну что, не все могут расширять мой гениальный код.
AN>А это хороший повод для сомнений в гениальности кода. Ты уверен, что твоя оценка твоего кода правильная? Что говорят про гениальность кода другие разработчики?
Если идеальный вылизанный код после добавления фичи вдруг из O(1) превращается в O(1+n^n^n) — то кто доктор такому разработчику?
Здравствуйте, denisko, Вы писали:
D>Темка, мой сотрудник недавно свалил на должность принципала как раз в ДЖИ в шеньженьский офис. Не поверишь, у них там все на ++, без жс и пхп. А на куде/сл вообще все самописное без тф и прочего. Ниасилили (((
Начал читать и понял что мне отвратно знание о проблемах этой извращенной натуры. Это не разработчик а дрочер какой-то! "Вообще писать современный код, пытаясь при этом быть идиоматичным..." — бля тебе шашечки или ехать?! Идиоматичненький ты наш! С++ — крутой язык для работы — хороший инструмент для тех, кому нужно писать быстроработающие программы. Если хочешь дрочить на свой код — иди в функциональщики — там все только и делают, что фапают. Не мешай людям работать!
Тё>Ну так я что, с этим спорю? Да, узкие места расшивать на C (или C++, если оченно хочется именно плюсы). Это всё узкие ниши, много народа туда не требуется. Гугл написал tensor flow к примеру, и все её вызывают из питона.
не все
не знаю как у вас но у нас на Python только прототипы тк его производительности не хватает
Здравствуйте, landerhigh, Вы писали:
L>Нужно понимать, что собеседователи в Амазон не имеют цели нанять кого-то. Среди них тоже есть условные Артемы, которым главное — почесать ЧСВ.
Вообще-то, сильно заметно, по самым внешним атрибутам, начиная с описания вакансии и заканчивая первым общением с кем-то оттуда, причём с любым, действительно ли ищут человека для работы, или это только шумная и бесполезная деятельность девочек HR-ок и прочих модно-молодёжных специалистов по подбору персонала. В крупных компаниях, вроде амазона, последние представлены во всей своей красе, многообразии и силе. С одной стороны они, а с другой стороны не менее модно-молодёжные, особо успешные, прочие не сидящие на месте, которые лезут в эти крупные компании оголтелыми толпами. Вот эти обе стороны там друг-друга и находят. И только работяги, разрабы и админы, с усталой усмешкой поглядывают, между делом, на клубящуюся пыль, столбом стоящую в комнатах для собеседований.
Здравствуйте, Тёмчик, Вы писали:
Тё>Если идеальный вылизанный код после добавления фичи вдруг из O(1) превращается в O(1+n^n^n) — то кто доктор такому разработчику?
Если действительно сложность O(1+n^n^n), то, проблемы, видимо в разработчике. Но ты привёл один случай. А в изначальном сообщении написано:
>>Да, приходят потом в мой код добавлять фич, случается адский песец, ну что, не все могут расширять мой гениальный код.
Т.е. — используется множественное число. Это значит, что более, чем у одного разработчика возникли проблемы с твоим кодом. Как часто у других разработчиков возникают проблемы с твоим кодом? Если часто — проблема системная. Либо у тебя код очень запутанный и в нём сложно разобраться и никаких комментариев нет. Либо подбор персонала в твоей организации плохо поставлен. Но, судя по твоим сообщениям, ты сам проводишь собеседование и те, кто через твой фильтр прошёл, знают 100500 алгоритмов сортировки и массивы и списки переворачивают как угодно.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, _ABC_, Вы писали:
KP>>>В АУ на столько все плохо с работой? _AB>>Смотря с какой... Но в целом — что ты хочешь от деревни размером с континент?
KP>Деревни разные бывают. Есть какая-нибудь Ирландия с кучей R&D, есть Сингапур где тоже куча R&D. А вот ситуация с Австралией выглядит непонятно, есть ощущение (я туда в конце 2000-х думал понаехать, к счастью не вышло) что раньше там было с R&D сильно лучше.
Ну так последние 40 лет основа экономики Австралии — перепродажа сарайчиков друг дружке за виртуальные деньги.
R&D в таком климате не очень уютно.
Здравствуйте, landerhigh, Вы писали:
L>перепродажа сарайчиков друг дружке за виртуальные деньги. L>R&D в таком климате не очень уютно.
Кремниевая Долина получается. А говоришь неуютно.
Здравствуйте, AleksandrN, Вы писали:
AN>Если действительно сложность O(1+n^n^n), то, проблемы, видимо в разработчике. Но ты привёл один случай. А в изначальном сообщении написано:
Разработчики не переживают за производительность- фича сделана, и ладно. Всплыть оно может позже, на на другой выборке либо под нагрузкой множества пользователей.
AN>у тебя код очень запутанный и в нём сложно разобраться
Ну так гениальный же. AN> и никаких комментариев нет.
Есть — где автор сам не может разобраться
AN> ты сам проводишь собеседование и те, кто через твой фильтр прошёл,
Я только задаю простые алгоритмические вопросы и даю им оценку, помимо не-технических. Коллега может спросить что-то приземлённое, например, плотно по CSS. Чел может слаб в алгоритмах, но силён в CSS- что ж, его не брать за это? Команда сильна, когда коллеги дополняют друг друга, у каждого свои сильные и слабые стороны. Решение принимается другими людьми.
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, landerhigh, Вы писали:
L>>Тёма, более того, на плюсах с шаблонами прекрасно пишутся прошивки для современных микроконтроллеров. Тё>Как у современных микроконтроллеров обстоит с C++ exceptions и heap?
Рекомендую посмотреть вот это выступление дабы понять что может современный C++ и перестать писать тот бред что ты пишешь в этой теме. Если досмотришь до конца и поймешь о чем там говорят, тебе может даже стыдно станет
Здравствуйте, Тёмчик, Вы писали:
Тё>На какой секунде там C++ exceptions и heap? То, что чувак написал примитивную игру без исключений и динамической аллокации памяти- подтверждает мой пойнт. Полноценному C++ не место в ядре, не место в контроллерах.
Здравствуйте, Тёмчик, Вы писали:
L>>Холмс научился программировать без динамической памяти и исключений. Тё>Предлагаю т.н. экспертам C++ почитать стандарт C++. Вообще, такой степени упоротости у C++ ков в моё время (до 2010г) не было.
Тёма, требовать динамической памяти на микроконтроллере с 1024 байтами памяти — особо отдельное упорство
Здравствуйте, B0FEE664, Вы писали:
BFE>Ну не все могут в C++. Это сложный язык, он не для всех. Вот кто не осилил, те и переписывает. Если вам подсунут язык, которого вы не знаете, то вы тоже перепишите. Люди не знают С++, вот и переписывают.
Да, как бы, наоборот. Все вокруг исключительно C++-ники. Один другого матёрее. Сидят в корпоративных чатах и соревнуются в пересказывании наизусть стандарта. Без шуток. В РФ вообще C++-ников как грязи. Вполне себе на уровне. Решение переписывать на другие ЯП спускают сверху архитекторы, в подавляющем большинстве случаев. Невозможно? Неизбежно.
Здравствуйте, Тёмчик, Вы писали:
SVZ>>>>А расскажи, будь любезен, чем, по-твоему, "настоящий С++" отличается от "Си с классами"?
Тё>>>Исключения, динамическая память, шаблоны, весь STL.
SVZ>>Это всего лишь инструменты. Ты можешь их использовать, но не обязан. SVZ>>Этим с++ и хорош.
Тё>Вы там определитесь- есть Стандарт C++. И тут же некоторые сиплюсплюсники бегают с костылями Тё>
Тё>Ты можешь их использовать, но не обязан.
Тё>Двойные стандарты. Именно поэтому под железки пишут на C, и только отдельные наркоманы делают доклады "смотрите, можно в микроконтроллер". Сектанты, как есть.
Мда, на все ваши высказывания в теме почему-то всплывает только цитата из классики
и вы в присутствии двух людей с университетским образованием позволяете себе с развязностью совершенно невыносимой подавать какие-то советы космического масштаба и космической же глупости
Здравствуйте, El Camino Real, Вы писали:
L>>R&D в таком климате не очень уютно. ECR>Кремниевая Долина получается. А говоришь неуютно.
В Долине довольно рапсространены варианты заработка, позволяющие разработчикам включиться в эту игру.
В Сиднеево стоха до сих пор считается хорошей зарплатой.
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, landerhigh, Вы писали:
L>>Нужно понимать, что собеседователи в Амазон не имеют цели нанять кого-то. Среди них тоже есть условные Артемы, которым главное — почесать ЧСВ.
S>Вообще-то, сильно заметно, по самым внешним атрибутам, начиная с описания вакансии и заканчивая первым общением с кем-то оттуда, причём с любым, действительно ли ищут человека для работы, или это только шумная и бесполезная деятельность девочек HR-ок и прочих модно-молодёжных специалистов по подбору персонала.
Крупные компании ищут всегда. Натуральная текучка-с и натуральный рост.
Но получается, что собеседуют вовсе не те, кому в команду требуется человек, а чаще те, кто мимокрокодил. Участвовать в найме либо заставляют, либо поощряют, либо еще как-то.
Но во многих компаниях сейчас есть список разрешенных к использованию на собеседования задач и явный запрет на использование trick questions. Задачи, предполагаемые лишь один правильный вариант решения, вообще "вне закона".
Здравствуйте, so5team, Вы писали:
Тё>>Наверите "C++" на сайте по поиску работы, и посмотрите предложения. Поддержка кала мамонта и тех раз-два и обчелся.
Ну не знаю. У меня вот такая сейчас проблема с поиском работы:
1. Мне становится скучно раз в полгода, я открываю сайт поиска работы
2. Нахожу работу, на С++(я больше ничего не умею), интересную, с ЗП в 1-2 раза больше. Её такой мало, но есть.
3. Думаю "о! прикольно! сейчас отправлю резюме!"
4. Через пять минут успокаиваюсь, прикидываю в голове, во сколько раз больше придётся работать, чтобы получать эти в 1-2 раза больше денег
5. Прихожу в себя, закрываю сайт и иду работать
S>Но вот почему вас C++ до сих пор беспокоит? Какие-то фантомные боли? Или когда вы программировали на C++, то были дороже, пользовались большим успехом у противоположного (а может и своего, по нынешним толерантным временам не поймешь) пола и здоровье позволяло этим успехом пользоваться? А сейчас уже остается только вспоминать, как трава была зеленее, вода мокрее, а хрен крепче?
Мне N лет назад казалось, что на java никто не пишет. Она мне вообще нигде никак не попадалась. И у меня примерно, как и под-автора возникало чувство, что "на яве никто ещё в здравом уме не...". Но потом я пошёл делать проект на яве, и внезапно передо мной открылся новый мир, с форумами, версиями и прочим, оказалось, что на яве пишет "весь мир", просто я этого не замечал, потому что просто не интересовался и работал а этой теме.
Здравствуйте, Тёмчик, Вы писали:
Тё>Погоди погоди. Я всё-таки работал и работаю можно сказать, на bleeding edge технологий в интересных областях. Никогда не занимался т.н. "оперднями" и "формошлёпством". Именно поэтому C++ таким архаизмом видится. Ну, ты ж не пишешь в прод на q-бейсике из школы начала 90-х? И на турбо-паскале не пишешь. Но почему-то держишься за C++. Вот ты сам писал, что гуя у вас- десктоп на Qt. А Qt- наследник MFC.
Я в универе несколько языков учил, работал тоже с несколькими. Например, от SQL тошнит. На Питоне небольшие вещи с удовольствием, но и только. С# не понравился, пару утилин на нём написал. Всякие экзотические вещи, типа R, Матлаба, J и не говорю, но они были после универа. А С++ развивается и мне нравится в какую сторону. Хотя я далеко не мастер в нём.
Тё>Нет, это ненормально. Это говорит лишь о застое в заросшей тиной распил-откатной конторе. Ибо для себя ты не потерпишь, чтобы за ради каждого чиха ставить дистрибутив на свой компьютер.
прости, но в какой именно конторе? За последние 10 лет я работал в 4-х, включая АМД и automotive в Люксофте. Да, две были российскими. Как-то ты знаешь, везде языком для продакшена был С++ и конкурентов не предвидилось. И везде были разработки вполне передовые или касающиеся таковых. Кстати, Catalyst в АМД раньше тоже был написан на C# и его... закопали! Потому что глючил и тормозил.
Тё>Я лишь вижу, что обычные конторы с вменяемым руководством ушли от C++ в 2005г. Осталось узко-специфичные HFT, железячники, и игроделы. Очень специфичные области, очевидно, накладывают тяжёлый отпечаток на работников.
О, этот список гораздо шире. Я тут уже приводил выше, что множество проектов для нейросетей начинается именно на С++. Фактически, это весь инструментарий для них. Сейчас сети становятся всё тяжелее и от С++ никуда не деться в принципе. Повторяться не буду. Intel, Nvidia, куча других контор — все они пишут и библиотеки и прикладной софт типа серверов на С++. В России вакансий много в таких больших иностранных компаниях. Например, Triton server — всё ядро на С++. Ты для интереса сходи на международную конференцию по С++, чтобы там было побольше компаний было представлено. Увидишь, как много всего написано на плюсах. Заодно можно пообщаться с разработчиками.
Тё>Да потому, что мир программирования ушёл вперёд. Зачем плестись в хвосте прогресса на уровне с дельфистами и VB6-ми, когда есть React.native например.
Эээ, ок. Fire and Motion, беги в голове прогресса.
Здравствуйте, Shmj, Вы писали:
S>Был я относительно недавно на собеседовании (на позицию embedded-программиста), где меня попросили написать аналог tar'a. С лимитом по времени 4 часа. И без Qt, пожалуйста. S>1 час я потратил на установку boost'a
Я бы его выгнал уже на этом этапе.
Embedded — там и STL-то не всегда используется, а он буст подтащить решил.
Здравствуйте, reversecode, Вы писали:
R>смотря что понимать под ембеддедом
R>то на армы и прочию чухню легко С++ заходит и с исключением и с стл итд
На армы и питон с нодой и жавой энтерпрайз заходят.
Ещё кстати камешек в огород Qt- сейчас, наверное, уже KDE научились нетормозить на 32г рамы. А во времена 0.5-1гиговых нетбуков, разница между Гномом (C + Python) и KDE (ваша прелессссть C++) в performance была колоссальной, C++-й код тупил, C+Py код летал.
Здравствуйте, kaa.python, Вы писали:
Тё>>Погоди погоди. Я всё-таки работал и работаю можно сказать, на bleeding edge технологий в интересных областях.
KP>Это ты про JS/TS что-ли?
TS, HFSM, Angular, микросервисы.
Тё>>Никогда не занимался т.н. "оперднями" и "формошлёпством".
KP>Наверное не про них, т.к. они ж и есть классическое формошлёпство
Онлайн текстовый процессор- по-твоему это тоже формошлепство?
И да, хочется большего- хочется заменить ангулар на реакт и добавить clojurescript. Может быть, когда-то удастся протащить. С реактом уже есть подвижки.
Здравствуйте, Тёмчик, Вы писали:
Тё>Большая десктопная прилага полностью в html5, феншуйные микросервисы в облаках.
А что делает-то полезного ваша "большая десктопная прилага полностью в html5"?
Тё>И можно пилить и фронт, и бек, выбирай из 50 микросервисов.
50 микросервисов? Какой ужас! Это уже не то что бы современно, вы отстали от моды. Сейчас вроде уже поняли что микросервисы это путь в никуда и на макро перешли.
Тё>А у тебя что? Пилить 1 маленький модуль (считай как 1 микросервис), это элементарно и скучно, никакого челенжа и разнообразия. Секас с костылями C++ я не считаю челленжем- у нормального плюсника всё работает.
А у меня дофига чего, причем в прорывной области, а не устаревшей микросервисной архитектуре
Здравствуйте, Тёмчик, Вы писали:
Тё>Что лично ты делаешь в прорывной области? Лично ты программируешь или обучаешь нейросетки или FSM? Какое место у C++ в программтровании FPGA например?
Я лично занимаюсь прорывными задачами в прорывной области. Детали после 2023, пока никак нельзя рассказать
Тё>Матлабщики делают рокет саенс, а сиплюсники подносят снаряды, ничем не лучше жавистов или нодщиков.
Здравствуйте, kaa.python, Вы писали:
KP>Я лично занимаюсь прорывными задачами в прорывной области. <b>Детали</b> после 2023, пока никак нельзя рассказать
Ну понятно, надуваешь щёки
KP>Ты бы лучше микросервисы на PHP писал
Для микросервисов есть node и go.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Вообще-то с++ для программирования ПЛИСов используется с незапамятных времен. Просто ты не в теме.
Кидай ссылки. У меня одногрупник в этой теме, правда оч давно не общался- так вот он ничего про C++ не говорил. У него какие-софтины были на десятки тыс $$ где оно проектировалось.
SVZ>Мы (сиплюплюсники) как раз делаем библиотеки для матлаба. Весь рокет саенс внутри. А матлаб это клей, как и питон.
Разве? А кто вам, сиплюсплюсникам, разжевывает формулы из научных работ?
Или всё сами, но тогда непонятна бомбежка отдельных представителей профессии на элементарные лёгкие вопросы на собеседовании.
Здравствуйте, Тёмчик, Вы писали:
Тё>>>А кто вам, сиплюсплюсникам, разжевывает формулы из научных работ?
S>>Э... Артёмка, неужели вы?
Тё>Я всего-лишь кодерок
А с виду "малолетний дебил" (с). С изрядно протекшей крышей. И зашкаливающим ЧСВ.
Тё>хотелось бы послушать мнение ниасиливших больше одного языка.
Версия о том, что асиливших, но выбравших C++ по объективным причинам, не приходит вам в голову почему? Врожденный дебилизм, хроническое бухалово, чрезмерное увлечение контактными единоборствами, что-то еще?
Здравствуйте, vfedosov, Вы писали:
>И шансов получить интересную задачу (со сложной алгоритмикой и т.д.) на плюсах в Германии гораздо больше, чем на джаве.
Последние пять лет с подачи межделмаша активно пилят софт для финансов на яве (пора всё-таки с cobol уходить). Вот где нагрузки, алгоритмика, ну и деньги.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>>>Вообще-то с++ для программирования ПЛИСов используется с незапамятных времен.
SVZ>Ключевое слово CatapultC.
Компилятор из C/C++ в HDL, нагуглил. Но всё-таки imho это один из, и применение там специфическое. Были попытки заменить C++ на Clojure (для генерации HDL) например- а это куда интересней.
SVZ>Вообще-то это мы делаем — и научные работы, и алгоритмы, и код. Электродинамикой занимаемся.
Круто. Не видел вживую таких программистов- научных работников 2-в-одном.
SVZ>Я за "отдельных преставителей профессии" не отвечаю. У меня на собеседованиях проблем нет.
Тут есть отметившиеся
Прошу не принимать за всех.
Я в теме описал таких стереотипичных плюсников,, ну которые с пеной у рта готовы доказывать, что C++ круче всех, при этом не понимают разницу между хешом и хипом, а динамический массив считают вектором, мучаются с Qt, ну потому, что ничего кроме C++ ниасилили, и которых бомбит на чужие высокие оценки в тесте и задачи написать tar на доске.
Здравствуйте, smeeld, Вы писали:
BFE>>Ну не все могут в C++. Это сложный язык, он не для всех. Вот кто не осилил, те и переписывает. Если вам подсунут язык, которого вы не знаете, то вы тоже перепишите. Люди не знают С++, вот и переписывают.
S>Да, как бы, наоборот. Все вокруг исключительно C++-ники. Один другого матёрее. Сидят в корпоративных чатах и соревнуются в пересказывании наизусть стандарта. Без шуток. В РФ вообще C++-ников как грязи. Вполне себе на уровне. Решение переписывать на другие ЯП спускают сверху архитекторы, в подавляющем большинстве случаев. Невозможно? Неизбежно.
Одно дело пересказывать правила стандарта, а другое дело уметь читать код.
Многие смогут прочитать и понять, например, это?:
Здравствуйте, Умака Кумакаки, Вы писали:
BFE>>Многие смогут прочитать и понять, например, это?: УК>какой именно фрагмент кода вызвал непонимание?
Не знаю. Это вот тут спрашивают.
УК>тайпдеф на обработчик события?
А зачем там передавать указатель на кнопку?
УК>Тривиальная реализация publish/subscribe?
Где там publish?
УК>Или каррирование частичное применение? Код вообще прозрачный, я в детстве такой писал после пары лет изучения крестов. Учитывая то, что это C++98, на C++17 всё будет выглядеть гораздо лаконичней.
Прозрачный? Это с void* код прозрачный? И что же скрывается за void*?
Здравствуйте, B0FEE664, Вы писали:
BFE>Прозрачный? Это с void* код прозрачный? И что же скрывается за void*?
Да что угодно. Ты как-будто на C не писал. И в этом его мощь. Если автор не знает, то там скрывается, то ему даже на Go писать нельзя (а то получит ошибку конвертации interface{]-а)
Здравствуйте, B0FEE664, Вы писали:
УК>>тайпдеф на обработчик события? BFE>А зачем там передавать указатель на кнопку?
чтобы в обработчике событий знать, от кого пришёл ивент
УК>>Тривиальная реализация publish/subscribe? BFE>Где там publish?
функция NotifyAll это publish, AddOnButtonPress — subscribe, RemoveOnButtonPress — unsubscribe
УК>>Или каррирование частичное применение? Код вообще прозрачный, я в детстве такой писал после пары лет изучения крестов. Учитывая то, что это C++98, на C++17 всё будет выглядеть гораздо лаконичней.
BFE>Прозрачный? Это с void* код прозрачный? И что же скрывается за void*?
любой пользовательский контекст. Если честно, твои вопросы меня озадачивают, ты вообще сколько кода читал/писал за свою жизнь?
Здравствуйте, landerhigh, Вы писали:
L>Инженер должен уметь применять готовые решения, а не городить велосипед на каждый чих, разве нет?
Инженер должен находить оптимальные решения а не "сводить задачу к предыдущей", дозабивая едва воткнутый гвоздь по шляпку.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, landerhigh, Вы писали:
L>>Инженер должен уметь применять готовые решения, а не городить велосипед на каждый чих, разве нет? CC>Инженер должен находить оптимальные решения а не "сводить задачу к предыдущей", дозабивая едва воткнутый гвоздь по шляпку.
те использовать http://libarchive.org/ или ZipArchive на собеседовании считалось бы норм
мне примерно в 93 давали на соебседование написать zip and unzip как я понял они хотели посмотреть не уменее использовать чужие библиотеки
Здравствуйте, Lexey, Вы писали:
L>Это не говнокод. Это всего лишь код, написанный до появления более современных стандартов C++.
Тё>>http://reactivex.io/RxCpp/.
L>И каким это тут боком? Из пушки по воробьям стрелять будем?
Здравствуйте, sergey2b, Вы писали:
S>мне примерно в 93 давали на соебседование написать zip and unzip как я понял они хотели посмотреть не уменее использовать чужие библиотеки
Zip /unzip всё-таки достаточно сложный алгоритм, чтобы ожидать его понимания сразу за 10 минут кандидатом (разобраться с LZ*). Но tar/untar- это ж почитать описание формата заголовка, и всё. Склеить входные файлы и прилепить заголовок.
Physically, an archive consists of a series of file entries terminated by an end-of-archive entry, which consists of two 512 blocks of zero bytes. A file entry usually describes one of the files in the archive (an archive member), and consists of a file header and the contents of the file. File headers contain file names and statistics, checksum information which tar uses to detect file corruption, and information about file types.
У людей нет выбора.
Ребенком пришлось забирать с пасьбы овец дядькиных.
Выяснилось, что они совершенно не соображают куда идти, и только когда все стадо бежит
только тогда наблюдается какой-то вектор.
А так да, выбрал бы лиспы(C# не сильно лучше плюсов).
Здравствуйте, кубик, Вы писали:
К>Привет, К>Прочел что чел программировал 17 лет что составляет 2/3 его жизни и что он устал. Он еще статьи какие то читает по С++ (во странный...) К>Дальше я читать поленился. К>Я так думаю что С++ тут не причем, может человек влюбился, авитаминоз, может просто он не видит результатьов своего труда...
Да, вы видимо правы. Проблема не в инструменте, а в аутпуте твоих усилий при использовании. Под output'ом я имею ввиду — признание начальства как минимум, как максимум видеть миллионы счастливых юзеров.
Я писал такой же пост 10 лет назад, он висит как раз под этим из ТС. Писал потому что сломал голову, пока писал какой-то примитивный сканер вирусов. Год писал. До этого еще 10 лет вбухал в изучение.
С тех пор ушел на C# и был доволен. Хотя истинное удовольствие испытал относительно недавно, когда мое приложение "взлетело" и я вижу сколько людей им пользуются каждый день. Аминь.
Здравствуйте, CreatorCray, Вы писали:
S>>По мне, так сложным можно назвать, например, такое CC>За такое надо бы тапком.
Да ладно. Такое обычно живет в библиотеках и используется для решения очень специфических задач. Вряд ли в прикладном коде такое встречается в дикой природе.
А для библиотеки, да еще с оглядкой на старые стандарты C++, вполне себе ничего.
S>Сходу не понятно, какой смысл здесь использовать std::list, а не std::vector.
Удаление из середины. Незнание как сделать для вектора эффективно или нежелание заморачиваться. Дупликаты при засовывании тоже не отслеживаются наверное от лени.
Здравствуйте, smeeld, Вы писали:
S>Если размеры vector-а — миллионы, и это тяжёлые объекты, которые даже мувятся рядом операций копирования, то сколько будет шуршать такой сдвиг?
удаление из вектора для данного кейса (когда порядок элементов не важен) это O(1) операция, т.е. не зависит от размера вектора
Здравствуйте, smeeld, Вы писали:
S>Хорошее в мире IT не приживается. Всюду C++ и прочие голанги и бидоны вместо лиспа, докеры вместо solaris zone, линуксы вместе благородных юниксов и BSD.
В одной крупной финансовой компании есть современная система в продакшене. Написана на Scheme.
Не может оно быть мейнстримом. Академическая лаконичность разбивается о суровые реалии.
Здравствуйте, Тёмчик, Вы писали:
Тё> клона Maven которому 20 лет,
Мавен — это не тот ли кусок говна, из-за которого каждое утро вместо того, чтобы просто собрать проект, ты вынужден ждать, когда из-за одной строчки изменений у тебя все новые зависимости скачаются, чтобы потом тебе заявить, что половина методов в библиотеке, о существовании которой ты до сих пор не подозревал, теперь deprecated?
Тё>и кривая тормозная попытка клона ко-рутин с Питона, которым тоже 20 лет, ощущение, что попал на машине времени в диал-апные времена.
Здравствуйте, smeeld, Вы писали:
S>или при закидывании в массив сохранять индекс, и при удалении сдвигать все эелементы с изменением их индексов
вот в этом кейсе (когда известен индекс) и при условии что порядок элементов не важен, удаление это O(1), надеюсь, хоть немного наморщив мозг, ты найдёшь решение без сдвига элементов
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, Умака Кумакаки, Вы писали:
УК>>удаление из вектора для данного кейса (когда порядок элементов не важен) это O(1) операция, т.е. не зависит от размера вектора
S>Что ты заливаешь? Удаление из list это O(1), так как там всего лишь перекинуть prev-ы и next-ы. Для удаления из массива нужно или искать его в массиве, причём линейным брутфорсом, а не бинарным поиском, так как не массив неупорядочен, или при закидывании в массив сохранять индекс, и при удалении сдвигать все эелементы с изменением их индексов.
С листе его также искать надо, а собственно удаление найденного элемннта из вектора действительно O(1). Ничего сдвигать не надо.
Здравствуйте, Умака Кумакаки, Вы писали:
УК>>>тайпдеф на обработчик события? BFE>>А зачем там передавать указатель на кнопку? УК>чтобы в обработчике событий знать, от кого пришёл ивент
Зачем? К тому же, если эти данные нужны, то их можно положить в то, что скрывается за void*.
УК>>>Тривиальная реализация publish/subscribe? BFE>>Где там publish? УК>функция NotifyAll это publish, AddOnButtonPress — subscribe, RemoveOnButtonPress — unsubscribe
NotifyAll это publish? У меня о publish функциональности несколько другое представление. publish — это то, что можно перечислить внешними методами в неком сторедже. Ну да не важно.
УК>>>Или каррирование частичное применение? Код вообще прозрачный, я в детстве такой писал после пары лет изучения крестов. Учитывая то, что это C++98, на C++17 всё будет выглядеть гораздо лаконичней. BFE>>Прозрачный? Это с void* код прозрачный? И что же скрывается за void*? УК>любой пользовательский контекст.
Вообще-то void* — это нечто прямо противоположное к прозрачному, это полностью скрытые данные или интерфейсы о которых ничего не известно.
УК>Если честно, твои вопросы меня озадачивают, ты вообще сколько кода читал/писал за свою жизнь?
Много. Сотни мегабайтов, наверное.
А вот вы пишите, что это тривиальная реализация. Тогда может объясните, зачем там динамический список обработчиков? Ведь такой список обработчиков имеет смысл только при динамическом изменении этого списка, так как иначе можно просто задать один статический обработчик в котором последовательно и явно в коде написать вызовы всех тех кто хочет быть подписан на эти вызовы. Т.е. один callback в котором просто вписаны вызовы всех других. Если же нужен именно динамический список, тогда может быть вы можете указать на задачу, где у кнопки в рантайме меняется список обработчиков у одной и той же кнопки, причём так, что список этих обработчиков не может быть составлен заранее?
Здравствуйте, andyp, Вы писали:
S>>Как раз для подписчиков порядок может быть очень важен.
A>Из интерфейса класса это никак не следует.
Имя AddOnButtonPress, конечно, не такое выразительное, как push_back, но вполне себе говорит о добавлении.
A>Клиент никакой порядок себе обеспечить не может
Не может обеспечить себе нужный порядок вызова AddOnButtonPress?
Здравствуйте, smeeld, Вы писали:
BFE>>Прозрачный? Это с void* код прозрачный? И что же скрывается за void*? S>Да что угодно. Ты как-будто на C не писал. И в этом его мощь. Если автор не знает, то там скрывается, то ему даже на Go писать нельзя (а то получит ошибку конвертации interface{]-а)
Вот именно. Значит чтобы понять, что там лежит придётся весь код "прошерстить". Если на С void* понятно, то на C++ void* — неуважение к читателю.
Здравствуйте, andyp, Вы писали:
A>Здравствуйте, smeeld, Вы писали:
S>>Скинь ссыль, где написано, что порядок там неважен?
A>На интерфейс класса глянь — я там гарантий некоего порядка выполнения хендлеров не вижу.
А интерфейс класса может служить гарантией чего-то из внутренней его кухни?
Здравствуйте, so5team, Вы писали:
BFE>>Многие смогут прочитать и понять, например, это?: S>Сходу не понятно, какой смысл здесь использовать std::list, а не std::vector.
Да? Т.е. зачем может понадобится добавлять динамически (!) несколько обработчиков на одну кнопку вам понятно? Расскажите, зачем?
Здравствуйте, so5team, Вы писали:
S>Имя AddOnButtonPress, конечно, не такое выразительное, как push_back, но вполне себе говорит о добавлении.
Может, оно не такое выразительное как push_front
A>>Клиент никакой порядок себе обеспечить не может S>Не может обеспечить себе нужный порядок вызова AddOnButtonPress?
Не может обеспечить порядок вызова callbacks из контейнера.
Здравствуйте, smeeld, Вы писали:
S>А интерфейс класса может служить гарантией чего-то из внутренней его кухни?
Да. Например, если бы например пользователю было доступно
add_to_front(...) и/или add_to_back(...)
то можно было бы предположить какие-то потуги на соблюдение порядка вызова подсунутых callbacks.
А то что есть сейчас, когда есть только добавлялка и убиралка, именно что никаких гарантий не дает. Наличие внутри коллекции — это вообще деталь реализации.
Здравствуйте, andyp, Вы писали:
S>>Имя AddOnButtonPress, конечно, не такое выразительное, как push_back, но вполне себе говорит о добавлении.
A>Может, оно не такое выразительное как push_front
В жизни, конечно, всякое бывает. Но из того, что мне доводилось видеть, Add обозначает именно добавление в конец.
A>>>Клиент никакой порядок себе обеспечить не может S>>Не может обеспечить себе нужный порядок вызова AddOnButtonPress?
A>Не может обеспечить порядок вызова callbacks из контейнера.
Если добавление идет в конец, callback-и вызываются последовательно, а при удалении хронологический порядок callback-ов сохраняется, то все в порядке.
И да, сам факт вызова callback-ов именно в порядке добавления в интерфейсе вряд ли можно выразить, но это может быть описано в документации.
Здравствуйте, smeeld, Вы писали:
S>По мне, так сложным можно назвать, например, такое
Метапрограммирование, да ещё с макросами, в библиотеке, да ещё в boost — это, конечно, сложный код, который хорошо иллюстрирует мой тезис. Очевидно авторы boost'овских библиотек многое понимают в стандарте C++, но умеют ли они писать на C++? Зависит от автора. Есть такие, чей код сразу можно выкидывать. Вот недавний пример.
Здравствуйте, Умака Кумакаки, Вы писали:
BFE>>Зачем? К тому же, если эти данные нужны, то их можно положить в то, что скрывается за void*. УК>Затем, что во многих ситуациях я хочу оперировать с данными контрола в коллбеке ивента,
Для этого есть void*
УК>например сделать кнопку неактивной,
Вы собираетесь делать кнопку неактивной в callback в момент её нажатия? Вы понимаете, к чему это скорее всего приведёт?
УК> получить текст из едитбокса,
Зачем для этого указатель на кнопку?
УК> отписаться от события итд итп.
Т.е. вы собираетесь вызвать Button::RemoveOnButtonPress() метод внутри callback'а? Я вас правильно понимаю? Вы хорошо подумали?
УК> Положить можно в void, только зачем заставлять пользователя библиотеки реализовывать стандартную для любой UI библиотеки машинерию?
Заставлять не надо и это не стандартная схема.
BFE>>Вообще-то void* — это нечто прямо противоположное к прозрачному, это полностью скрытые данные или интерфейсы о которых ничего не известно. УК>ты следи за контекстом, прозрачный относилось к коду. И использование void* как пользовательского контекста это вообще практика со времён зарождения си и коллбеков.
Вот именно, что C, а не C++. В С++ всё иначе должно быть.
УК>>>Если честно, твои вопросы меня озадачивают, ты вообще сколько кода читал/писал за свою жизнь? BFE>>Много. Сотни мегабайтов, наверное. УК>А что не гигабайтов? Ты похоже далёк от разработки совсем. Судя по всему, что тебя удивляют стандартные UI паттерны, которые есть в любой UI библиотеке, начиная от MFC и заканчивая HTML DOM с его addEventListener, вероятно ты не настоящий сварщик.
Меня эти "стандартные" UI паттерны не удивляют, мне от них плакать хочется.
BFE>>А вот вы пишите, что это тривиальная реализация. Тогда может объясните, зачем там динамический список обработчиков? Ведь такой список обработчиков имеет смысл только при динамическом изменении этого списка, так как иначе можно просто задать один статический обработчик в котором последовательно и явно в коде написать вызовы всех тех кто хочет быть подписан на эти вызовы. Т.е. один callback в котором просто вписаны вызовы всех других. Если же нужен именно динамический список, тогда может быть вы можете указать на задачу, где у кнопки в рантайме меняется список обработчиков у одной и той же кнопки, причём так, что список этих обработчиков не может быть составлен заранее?
УК>Ты прикалываешься? Это же очевидно UI библиотека, у неё не может быть статических обработчиков, так как они задаются пользователем библиотеки (в рантайме). Боже, какой же ты дремучий.
Нет, вы не обзывайтесь, а давайте объясните зачем там список и почему нельзя обойтись одним callback'ом. Особенно мне интересно, что, по вашему мнению, будет при вызове метода RemoveOnButtonPress изнутри callback'а (или как вы там собираетесь отписаться от события)?
Здравствуйте, Умака Кумакаки, Вы писали:
УК>извини, но я уже сделал вывод что ты просто тупой и не в коня корм, не хочу на тебя тратить время, попробуй сам написать UI библиотеку на C++, может быть что-то прояснится.
Жаль, очень жаль, что на мои простые вопросы нет никаких конструктивных ответов.
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Зачем? К тому же, если эти данные нужны, то их можно положить в то, что скрывается за void*. УК>>Затем, что во многих ситуациях я хочу оперировать с данными контрола в коллбеке ивента, BFE>Для этого есть void*
void* для этого хреново подходит, ибо один и тот же обработчик может обрабатывать несколько кнопок. Нет, можно, конечно, при подписке передавать разные контексты, но потом их придется разруливать внутри обработчика, что явно не упростит его код. Данные об источнике (кнопке) и контексте обработчика, действительно, удобнее передавать раздельно.
УК>>например сделать кнопку неактивной, BFE>Вы собираетесь делать кнопку неактивной в callback в момент её нажатия? Вы понимаете, к чему это скорее всего приведёт?
Вполне вероятно, что ни к чему плохому. Возможный сценарий: нажали кнопку Abort, в обработчике мы ее деактивируем и запускаем диалог с прогрессом отката.
УК>> отписаться от события итд итп. BFE>Т.е. вы собираетесь вызвать Button::RemoveOnButtonPress() метод внутри callback'а? Я вас правильно понимаю? Вы хорошо подумали?
Для кнопок это несколько странный сценарий, но, гипотетически возможный. Например, нужно в обработчике дождаться нажатия нескольких кнопок (в любом порядке). Получили одно нажатие, отписались, ждем остальных. Если же забыть про кнопки, то это вполне типичный сценарий ожидания результатов нескольких операций.
УК>> Положить можно в void, только зачем заставлять пользователя библиотеки реализовывать стандартную для любой UI библиотеки машинерию? BFE>Заставлять не надо и это не стандартная схема.
Схема вполне стандартная.
BFE>>>Вообще-то void* — это нечто прямо противоположное к прозрачному, это полностью скрытые данные или интерфейсы о которых ничего не известно.
Ничего неизвестно на стороне, генерирующей события. Но, на ней и не нужно ничего знать про внутреннее устройство того, что лежит под void*.
BFE>Вот именно, что C, а не C++. В С++ всё иначе должно быть.
В случае UI соглашусь. Но, подобные схемы не только для него используются. И, иногда, абстракции типа std::function или интерфейса с виртуальным методом в качестве колбэка могут быть слишком дороги по сравнению с обычной функцией, принимающей void*.
Здравствуйте, smeeld, Вы писали:
>>Т.к. в list-е каждый элемент -- это динамически созданный объект, удаление которого всяко дороже, чем сдвиг нескольких соседей в vector-е.
S>Если размеры vector-а — миллионы, и это тяжёлые объекты, которые даже мувятся рядом операций копирования, то сколько будет шуршать такой сдвиг?
Да эти некоторые представители профессии уже неоднократно проявили себя. Про устройство цикличного списка и возможность возвращать обьект Subscription с методом unsubscribe и внутри ссылкой на node, они не слыхали. Они ж не "стреляют из пушки по воробьям". И весьма вероятно, что хеш от хипа не отличают, но зато мастурбируют на меташаблоны буста.
Здравствуйте, Тёмчик, Вы писали:
>>>Т.к. в list-е каждый элемент -- это динамически созданный объект, удаление которого всяко дороже, чем сдвиг нескольких соседей в vector-е.
S>>Если размеры vector-а — миллионы, и это тяжёлые объекты, которые даже мувятся рядом операций копирования, то сколько будет шуршать такой сдвиг?
Тё>Про устройство цикличного списка и возможность возвращать обьект Subscription с методом unsubscribe и внутри ссылкой на node, они не слыхали. Они ж не "стреляют из пушки по воробьям".
Тёмчик, а какое это все имеет отношение к обсуждению уместности применения std::list вместо std::vector?
Тё>И весьма вероятно, что хеш от хипа не отличают, но зато мастурбируют на меташаблоны буста.
Зачем нам шаблоны какого-то Boost-а, если у нас своих полно?
Здравствуйте, so5team, Вы писали:
S>Да ладно. Такое обычно живет в библиотеках и используется для решения очень специфических задач.
Ну разишо.
В любом случае такая трёхэтажность может быть оправдана только если у более простого кода практический выхлоп получается хуже. Т.е. код будет медленнее или более ресурсоёмкий.
Код пишется и оформляется для людей, машине всё равно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Тёмчик, Вы писали:
Тё>Блин, так это ж говнокод, что там обсуждать какой сорт говна лучше- через список или массив. Посмотри на реализацию событийной модели здорового человека- может что-нибудь новое для себя узнаешь.
Молодец. Ты уже всех убедил, что всё говнокод, кроме того, что ты написал, а ты — гений. Так просвети всех, пошли всех на гитхаб, дабы узрели твой код гениальный и осознали серость и убогость свою.
Здравствуйте, AleksandrN, Вы писали:
AN> Так просвети всех, пошли всех на гитхаб, дабы узрели твой код гениальный и осознали серость и убогость свою.
Не-не-не, не всяк, кто узреет код Темки сможет выжить, неподготовленного джуна, его сияющий код может вообще испепелить. Я бы не рискнул вот ссылки просить
Здравствуйте, Тёмчик, Вы писали:
Тё>Блин, так это ж говнокод, что там обсуждать какой сорт говна лучше- через список или массив. Посмотри на реализацию событийной модели здорового человека- может что-нибудь новое для себя узнаешь.
Тема, ты только что заявил, что ты простейший колбек не сможешь реализовать без "библиотеки событийной модели".
Здравствуйте, Тёмчик, Вы писали:
Тё>Сложность удаления O(1). Сложность добавления в конец либо в начало (по вкусу) O(1).
Я не знаю что у вас там в JS, но в языках близких к железу О-нотация не работает на маленьких объемах данных из за промахов по кэшу. О чем, собственно, тут и говорят. Вспоминай базу
Здравствуйте, Тёмчик, Вы писали:
S>>Гораздо более серьезно, чем когда вы заявляете, что C++ не используется для рилтайма. Тё>Я заявлял, что в ядре не место C++.
Артёмка, сколько production kernel кода ты написал?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Lexey, Вы писали:
S>>Сказал как отрезал.
L>Это для него характерно. Раньше он свою упоротость демонстрировал, в основном, в автомобильной тематике. Теперь и до плюсов добрался.
Да он вроде по всем темам такой, от языков программирования до фотоаппаратов с автомобилями. А к плюсам, скорее, вернулся
Здравствуйте, Lexey, Вы писали:
BFE>>>>Зачем? К тому же, если эти данные нужны, то их можно положить в то, что скрывается за void*. УК>>>Затем, что во многих ситуациях я хочу оперировать с данными контрола в коллбеке ивента, BFE>>Для этого есть void* L>void* для этого хреново подходит, ибо один и тот же обработчик может обрабатывать несколько кнопок. Нет, можно, конечно, при подписке передавать разные контексты, но потом их придется разруливать внутри обработчика, что явно не упростит его код. Данные об источнике (кнопке) и контексте обработчика, действительно, удобнее передавать раздельно.
Если один и тот же обработчик обрабатывает события от разных кнопок, то ему не важно, от какой конкретно кнопки пришёл вызов. Если же вызовы различаются, то нет смысла делать один обработчик, чтобы потов внутри различать кнопки. Но даже если вам нужно что-то экзотическое, то вам ничего не мешает под void* положить пару указателей Botton*, OtherData* и дальше работать точно так же.
УК>>>например сделать кнопку неактивной, BFE>>Вы собираетесь делать кнопку неактивной в callback в момент её нажатия? Вы понимаете, к чему это скорее всего приведёт? L>Вполне вероятно, что ни к чему плохому. Возможный сценарий: нажали кнопку Abort, в обработчике мы ее деактивируем и запускаем диалог с прогрессом отката.
Но все другие обработчики, добавленные после вызванного, получат вызов для неактивной кнопки, а это нарушение предусловий вызова.
УК>>> отписаться от события итд итп. BFE>>Т.е. вы собираетесь вызвать Button::RemoveOnButtonPress() метод внутри callback'а? Я вас правильно понимаю? Вы хорошо подумали? L>Для кнопок это несколько странный сценарий, но, гипотетически возможный. Например, нужно в обработчике дождаться нажатия нескольких кнопок (в любом порядке). Получили одно нажатие, отписались, ждем остальных. Если же забыть про кнопки, то это вполне типичный сценарий ожидания результатов нескольких операций.
Только вот при вызове Button::RemoveOnButtonPress() внутри callback'а скорее всего получится segmentation fault или другое UB: ведь в момент вызова callback'а внутри прохода std::for_each будет удалён объект на который указывает текущий итератор.
УК>>> Положить можно в void, только зачем заставлять пользователя библиотеки реализовывать стандартную для любой UI библиотеки машинерию? BFE>>Заставлять не надо и это не стандартная схема. L>Схема вполне стандартная.
Обычно нужен один обработчик на одну кнопку, а если нужно больше, то внутри обработчика уже можно организовать так, как хотите.
BFE>>>>Вообще-то void* — это нечто прямо противоположное к прозрачному, это полностью скрытые данные или интерфейсы о которых ничего не известно. L>Ничего неизвестно на стороне, генерирующей события. Но, на ней и не нужно ничего знать про внутреннее устройство того, что лежит под void*.
Согласен, иногда непрозрачность == изолированность полезна, но в том-то и дело, что это именно непрозрачность.
BFE>>Вот именно, что C, а не C++. В С++ всё иначе должно быть. L>В случае UI соглашусь. Но, подобные схемы не только для него используются. И, иногда, абстракции типа std::function или интерфейса с виртуальным методом в качестве колбэка могут быть слишком дороги по сравнению с обычной функцией, принимающей void*.
В данном случае ни о какой скорости речи не идёт.
Как удобно: когда по делу сказать нечего, то нужно наговорить собеседнику кучу гадостей.
Вот реально не понимаю, как паттерн Visitor поможет при работе с C API. Ладно бы еще какой-нибудь Facade был упомянут, ну или Bridge хотя бы, но Visitor... Просветите старика, плиз.
По поводу накладных расходов все было уже расписано ранее, перечитайте. По поводу "мутно", если вам не понятно, то речь шла про понятность политки владения сущностями в вашем подходе. В C++ сборщика мусора нет. Возвращать голые владеющие указатели так себе способ.
PS.
> Готов ответить за звиздёж в любое время.
Видели:
>> Реалтаймовые системы не на плюсах делают.
Здравствуйте, so5team, Вы писали:
S>По поводу "мутно", если вам не понятно, то речь шла про понятность политки владения сущностями в вашем подходе. В C++ сборщика мусора нет. Возвращать голые владеющие указатели так себе способ.
Похоже, для того, чтобы разрешить должным образом проблемы владения (т.е. чтобы было безразлично, что именно удаляется первым -- тот, кто делает подписки или же сам SubscriptionStorage) нужно использовать что-то вроде:
template<class T>
class SubscriptionStorage {
public:
struct Subscription {
virtual ~Subscription() = default;
};
using SubscriptionHandle = std::unique_ptr<Subscription>;
[[nodiscard]]
SubscriptionHandle subscribe(T && value);
... // Конструктор и прочий фарш не показаны.private:
struct Link {
virtual ~Link() = default;
Link * prev_;
Link * next_;
};
struct Internals : public std::enable_shared_from_this<Internals> {
Link sentinel_;
};
using InternalsShptr = std::shared_ptr<Internals>;
struct OneSubscription : public Link, public Subscription {
InternalsShptr internals_;
T value_;
OneSubscription(InternalsShptr internals, T && value)
: internals_{std::move(internals)}, value_{std::move(value)}
{}
~OneSubscription() override {
... // Вычеркивание себя из списка.
}
};
InternalsShptr internals_;
...
};
template<typename T>
SubscriptionStorage<T>::SubscriptionHandle SubscriptionStorage<T>::subscribe(T && value) {
auto result = std::make_shared<Subscription>(internals, std::move(value));
... // Провязывание новой подписки в список.return result;
}
Вот в этом случае, КМК, не будет проблем с временами жизни. Пока живет хотя бы одна подписка, остается живым объект SubscriptionStorage::Internals. Следовательно, деструкторы Subscription могут спокойно вычеркивать себя из списка подписок даже если сам объект SubscriptionStorage прекратил свое существование. С другой стороны, если все объекты Subscription разрушаются до того, как умрет SubscriptionStorage, то вообще никаких проблем: ссылка на SubscriptionStorage::Internals останется только у SubscriptionStorage и этот Internals умрет сразу вслед за SubscriptionStorage.
Для уничтожения подписки достаточно просто "потерять" SubscriptionHandle. Или явно вызвать для него reset.
С другой строны, если SubscriptionHandle нигде не сохранить, то подписка исчезнет сразу же после создания.
Ну и в рамках C++98, где не было возможности создавать Movable+NonCopyable классы, пришлось бы, скорее всего, делать SubscriptionHandle в виде аналога shared_ptr.
Еще в этом подходе коряво то, что при движении по списку подписок нужно будет делать либо dynamic_cast от Link-а к OneSubscription, либо вообще, если RTTI под запретом, пользоваться reinterpret_cast-ом (вроде бы static_cast здесь не прокатит). В общем-то, опасности в reinterpret_cast-е здесь не видно, но сам по себе код с такими кастами попахивает.
Здравствуйте, B0FEE664, Вы писали:
BFE>Если один и тот же обработчик обрабатывает события от разных кнопок, то ему не важно, от какой конкретно кнопки пришёл вызов.
Это еще почему? Ну и, замени кнопки на textbox'ы, например, и картина точно изменится.
BFE>Если же вызовы различаются, то нет смысла делать один обработчик, чтобы потов внутри различать кнопки.
Есть. DRY называет. Если код обработчиков практически идентичен, то зачем плодить лишние сущности?
BFE>Но даже если вам нужно что-то экзотическое, то вам ничего не мешает под void* положить пару указателей Botton*, OtherData* и дальше работать точно так же.
Я про такую возможность говорил, только это потенциальное усложнение логики каждого обработчика. Не думаю, что оно тут оправдано.
BFE>Но все другие обработчики, добавленные после вызванного, получат вызов для неактивной кнопки, а это нарушение предусловий вызова.
Это вопрос того, какие гарантии предоставляет автор механизма событий. И он совсем обязан гарантировать, что между нажатием на кнопку и вызовом обработчика состояние кнопки не может измениться.
BFE>Только вот при вызове Button::RemoveOnButtonPress() внутри callback'а скорее всего получится segmentation fault или другое UB: ведь в момент вызова callback'а внутри прохода std::for_each будет удалён объект на который указывает текущий итератор.
Это легко обходится через копирование колбэков во временный контейнер и вызов for_each поверх него. Это довольно стандартное решение для ситуаций, когда возможны описки из колбэков.
BFE>Обычно нужен один обработчик на одну кнопку, а если нужно больше, то внутри обработчика уже можно организовать так, как хотите.
Тем не менее, в тех же винформах в .NET там обычный event, на который можно вешать сколько угодно обработчиков. Так явно проще, чем писать кастомные обработчики, раскидывающие события по своим вторичным подписчикам.
BFE>В данном случае ни о какой скорости речи не идёт.
Здравствуйте, so5team, Вы писали:
S>Вот в этом случае, КМК, не будет проблем с временами жизни. Пока живет хотя бы одна подписка, остается живым объект SubscriptionStorage::Internals. Следовательно, деструкторы Subscription могут спокойно вычеркивать себя из списка подписок даже если сам объект SubscriptionStorage прекратил свое существование. С другой стороны, если все объекты Subscription разрушаются до того, как умрет SubscriptionStorage, то вообще никаких проблем: ссылка на SubscriptionStorage::Internals останется только у SubscriptionStorage и этот Internals умрет сразу вслед за SubscriptionStorage.
Да просто используй std::unique_ptr с кастомным Deleter.
На самом деле, этот геморрой с хранением Subscription и последующим удалением не нужен при использовании Observable из ReactiveX: там есть оператор takeUntil. Везде в во все цепочки подписок вставить takeUntil(onDestroy$). onDestroy$ — это Subject, который один раз вызывает onDestroy$.next(); onDestroy$.close(), и все подписки магичеким образом само-разрушаются.
S>Для уничтожения подписки достаточно просто "потерять" SubscriptionHandle. Или явно вызвать для него reset.
S>С другой строны, если SubscriptionHandle нигде не сохранить, то подписка исчезнет сразу же после создания.
Вы явно не работали с событийной моделью, или варитесь в каком-то собственном мирке. Что в общем неудивительно, учитывая, какую мизерную долю рынка сейчас занимает C++. Посмотрите по сторонам- долинные корпорации давно всё выложили, только используй.
Здравствуйте, Тёмчик, Вы писали:
S>>Вот реально не понимаю, как паттерн Visitor поможет при работе с C API. Ладно бы еще какой-нибудь Facade был упомянут, ну или Bridge хотя бы, но Visitor... Просветите старика, плиз. Тё>Дано: одно или несколько сторонних API. Нужно: сделать бесшовную интеграцию. Передаём visitor на нужное API. Это широко используемая практика в обработке данных от пачки разных API разных версий.
При нажатии на кнопку Ok нужно вызывать somelib_data_on_ready и передать в него указатель, полученный ранее при вызове somelib_data_destroy.
Каким образом здесь применим Visitor?
S>>По поводу накладных расходов все было уже расписано ранее, перечитайте. По поводу "мутно", если вам не понятно, то речь шла про понятность политки владения сущностями в вашем подходе. В C++ сборщика мусора нет. Возвращать голые владеющие указатели так себе способ. Тё>Можете сделать умный указатель для subscription.
Этого будет мало.
Тё>Да, C++ это боль.
У вас, похоже, это была боль. Даже нет, у вас это была БОЛЬ. Причем такая, что отзывается до сих пор.
>>>> Реалтаймовые системы не на плюсах делают.
S>>Ответили за звиздеж, да. Тё>Не на плюсах.
Вот опять звиздеж. Делают. В том числе и на современных. В том числе и с использованием кусков из STL. Ничего не мешает в рилтайм-коде использовать std::find, std::accumulate, std::array и подобный код. Да даже аллоцирующие контейнеры вроде vector, map, set можно применять, если они наполняются в момент инициализации приложения.
Если где-то до сих пор в рилтайме ограничиваются C++98, то, скорее всего, из-за отсутствия сертифицированных компиляторов с поддержкой более новых стандартов.
Тё>Вот вы влезли в тему событийной модели, которой я сейчас плотно занимаюсь (использую RxJs).
Да это очевидно, что сейчас у вас с RxJs конфетно-букетный период.
Здравствуйте, Lexey, Вы писали:
L>Что касается структур данных, то тут можно вспомнить классическое "правило" 80/20: >80% кейсов покрываются именно векторами, хеш-мапами и упорядоченными мапами.
Здравствуйте, Nuzhny, Вы писали:
L>>В закромах буста обнаружился flat_map и flat_set. Вот прям что надо было. N>Оно в С++20, к сожалению, они не попали.
Ну, я не бустофоб, так что проблема так себе.
Вот чему я удивился, так тому, что корутины, которые вошли в двадцатку — stackless.
Здравствуйте, landerhigh, Вы писали:
SVZ>>Делается легко и непринуждённо.
+1
L>Но раз велосипед уже изобретен в бусте, то почему бы его и не использовать?
Потому, что бинарный поиск нужно знать, чтоб от зубов отскакивало. Даже в STL есть lower/upper bound, и оно работает даже без всяких векторов.
Здравствуйте, so5team, Вы писали:
Тё>>sentinel иницировать в конструкторе: Тё>>sentinel.next = sentinel.prev = sentinel.
S>За такие инициализации в конструкторе в C++ со времен 1990-х по рукам бъют. Но откуда вам знать-то.
Хм, это почему же? Где ещё такую инициализацию делать, как не в конструкторе списка?
Здравствуйте, netch80, Вы писали:
Тё>>>sentinel иницировать в конструкторе: Тё>>>sentinel.next = sentinel.prev = sentinel.
S>>За такие инициализации в конструкторе в C++ со времен 1990-х по рукам бъют. Но откуда вам знать-то.
N>Хм, это почему же? Где ещё такую инициализацию делать, как не в конструкторе списка?
В списке инициализации конструктора, а не в теле конструктора. Т.е.
Здравствуйте, netch80, Вы писали:
N>А вы нечитатель, после того, как слово "sentinel node" промелькнуло в этой подветке минимум пять раз. Тут про*б ваш, а не его.
100% мой. По ссылке Тёмчика не ходил, а в самой ссылке обратил внимание только на финальную часть, которая про linked-list-implementation.
Здравствуйте, netch80, Вы писали:
N>Ну в данном случае откровенно без разницы.
Это отличный индикатор уровня владения инструментом. Такие вещи должны быть доведены до автоматизма, как и расстановка const-ов и nodiscard в должных местах.
Здравствуйте, so5team, Вы писали:
N>>Ну в данном случае откровенно без разницы.
S>Это отличный индикатор уровня владения инструментом. Такие вещи должны быть доведены до автоматизма, как и расстановка const-ов и nodiscard в должных местах.
Безотносительно уровня владения инструментом, утечки памяти в связи с исключением в конструкторе, там быть не может. Вы ведь помните, из-за чего все эти прыжки со скакалкой в C++, правда?
Здравствуйте, Тёмчик, Вы писали:
S>>Это отличный индикатор уровня владения инструментом. Такие вещи должны быть доведены до автоматизма, как и расстановка const-ов и nodiscard в должных местах.
Тё>Безотносительно уровня владения инструментом,
В данном конкретном вашем случае нет "безотносительно". Вы откровенно не владеете инструментом, о возможностях и перспективах которых здесь делаете столь громкие заявления.
Тё>утечки памяти в связи с исключением в конструкторе, там быть не может. Вы ведь помните, из-за чего все эти прыжки со скакалкой в C++, правда?
Продолжаете расписываться в непонимании C++? Верной дорогой.
Списки инициализации важны не только для обеспечения exception safety (как и exception safety важна не только для предотвращения утечек памяти). Но и для того, чтобы в теле конструктора не задействовать случайно неинициализированные должным образом поля объекта. Что запросто может произойти по мере эволюции кодовой базы. Поэтому тот, кто не использует в C++ списки инициализации, тот, скорее всего, просто еще не осознал, что "уставы пишутся кровью". Вот как вы.
Возможно, имей вы опыт развития продукта в течении долгого времени, то не несли бы такой откровенной херни. Но ведь вы же как попрыгунья-стрекоза: "интересно делать новые проекты, изучать новые технолигии, (старые) алгоритмы, и т.д."
S>Списки инициализации важны не только для обеспечения exception safety (как и exception safety важна не только для предотвращения утечек памяти). Но и для того, чтобы в теле конструктора не задействовать случайно неинициализированные должным образом поля объекта. Что запросто может произойти по мере эволюции кодовой базы. Поэтому тот, кто не использует в C++ списки инициализации, тот, скорее всего, просто еще не осознал, что "уставы пишутся кровью".
В С++ считается хорошем стилем все поля класса инициализировать через списки инициализации? Добавил поле — автоматически добавил : m_value(a_value) во все конструкторы? Просто присваивания в теле конструктора считаются более error prone?
Здравствуйте, so5team, Вы писали:
S>В данном конкретном вашем случае нет "безотносительно". Вы откровенно не владеете инструментом, о возможностях и перспективах которых здесь делаете столь громкие заявления.
Тё>>утечки памяти в связи с исключением в конструкторе, там быть не может. Вы ведь помните, из-за чего все эти прыжки со скакалкой в C++, правда?
S>Продолжаете расписываться в непонимании C++? Верной дорогой.
S>Списки инициализации важны не только для обеспечения exception safety (как и exception safety важна не только для предотвращения утечек памяти). Но и для того, чтобы в теле конструктора не задействовать случайно неинициализированные должным образом поля объекта. Что запросто может произойти по мере эволюции кодовой базы. Поэтому тот, кто не использует в C++ списки инициализации, тот, скорее всего, просто еще не осознал, что "уставы пишутся кровью". Вот как вы.
Не вижу в том коде возможности "задействовать случайно неинициализированные должным образом поля объекта". У вас профессиональная деформация, наверное. Учите лучше алгоритмы, ну там, хоть строку чтоб могли развернуть, это всё.
S>Возможно, имей вы опыт развития продукта в течении долгого времени, то не несли бы такой откровенной херни. Но ведь вы же как попрыгунья-стрекоза: "интересно делать новые проекты, изучать новые технолигии, (старые) алгоритмы, и т.д."
Предпочитаю брать самую сложную фичу "если не я, то кто", и выполнять её. Потом можно оставить состимам на суппорт.
Здравствуйте, kaa.python, Вы писали:
S>> Но ведь вы же как попрыгунья-стрекоза: "интересно делать новые проекты, изучать новые технолигии, (старые) алгоритмы, и т.д."
KP>А вот тут обидно было (вспоминая порядку языков с которыми работал последние 10 лет )
Так ведь некоторые за год умудряются вобрать в себя больше, чем иные за три. Так что тут все индивидуально.
Здравствуйте, so5team, Вы писали:
S>Так ведь некоторые за год умудряются вобрать в себя больше, чем иные за три. Так что тут все индивидуально.
Самокритично.
Здравствуйте, Тёмчик, Вы писали:
Тё>У вас профессиональная деформация, наверное. Учите лучше алгоритмы, ну там, хоть строку чтоб могли развернуть, это всё.
Тёмчик, а у вас высшее образование вообще есть? Не обязательно даже профильное.
Отличие выпускника ВУЗа от выпускника школы состоит в том, что на вопрос "Что такое X?" выпускник ВУЗа совершенно искренне может ответить "Я не знаю что это, но знаю, где об этом узнать".
Вы же ведете себя именно как школьник, который надрачивает на какие-то абстрактные "знания".
Алгоритмов и структур данных с разными их вариациями полным полно. Обладая опытом и способностью учиться я могу себе позволить знать только маленькую их толику. А остальное добирать в тот момент, когда мне это нужно, после чего благополучно забыть.
А вот вам, как профессиональному ходоку по собеседованиями в поисках более лучшей компании и новой "green field" знание алгоритмов представляется какой-то неоспоримой ценностью.
Тё>Предпочитаю брать самую сложную фичу "если не я, то кто", и выполнять её.
Осталось только как-то доказать, что такое в принципе имеет место быть.
Тё>Потом можно оставить состимам на суппорт.
Ну мы-то в порядок приведем и работать заставим. Благо опыт есть.
Здравствуйте, so5team, Вы писали:
Тё>>У вас профессиональная деформация, наверное. Учите лучше алгоритмы, ну там, хоть строку чтоб могли развернуть, это всё.
S>Тёмчик, а у вас высшее образование вообще есть? Не обязательно даже профильное.
Есть, но более железячное — схемотехника, ассемблер, теормех.
S>Отличие выпускника ВУЗа от выпускника школы состоит в том, что на вопрос "Что такое X?" выпускник ВУЗа совершенно искренне может ответить "Я не знаю что это, но знаю, где об этом узнать".
Это вы на собеседовании такое говорите? Ну так такое только в аутсорсных краях прокатывает- где нужно набрать некое количество тушек.
S>Вы же ведете себя именно как школьник, который надрачивает на какие-то абстрактные "знания".
На знания никогда не поздно надрачивать.
S> я могу себе позволить знать только маленькую их толику
Оно по вам заметно. Из 100% IQ 99% залито в хождение по граблям C++. Причём, вы, похоже, даже и не понимаете причины, а исполняете, как ритуал.
S>А вот вам, как профессиональному ходоку по собеседованиями в поисках более лучшей компании и новой "green field" знание алгоритмов представляется какой-то неоспоримой ценностью.
Я слишком ленив, чтобы просто так ходить по собеседованиям
Тё>>Предпочитаю брать самую сложную фичу "если не я, то кто", и выполнять её.
S>Осталось только как-то доказать, что такое в принципе имеет место быть.
Мне это говорят руководители. Может быть, это хитрый план.
Тё>>Потом можно оставить состимам на суппорт.
S>Ну мы-то в порядок приведем и работать заставим. Благо опыт есть.
Вот в этом не уверен, ибо бывали ситуации, когда упрямые вроде вас коллеги кидалить махать шашкой в их собственном понимании прекрасного (заставь дурака богу молиться), и превращали прекрасный рабочий код в поломанное вонючее говно.
Здравствуйте, Тёмчик, Вы писали:
S>>Тёмчик, а у вас высшее образование вообще есть? Не обязательно даже профильное. Тё>Есть, но более железячное — схемотехника, ассемблер, теормех.
Очень странно.
S>>Отличие выпускника ВУЗа от выпускника школы состоит в том, что на вопрос "Что такое X?" выпускник ВУЗа совершенно искренне может ответить "Я не знаю что это, но знаю, где об этом узнать". Тё>Это вы на собеседовании такое говорите?
У меня было всего одно собеседование много-много лет назад. И там никому не нужно было обсуждать знания алгоритмов и другие виды пенисометрии.
Тё>Ну так такое только в аутсорсных краях прокатывает- где нужно набрать некое количество тушек.
РБ, конечно, царство победившего аутсорса, но я на аутсорсинговую компанию проработал всего что-то около полугода (много-много лет назад). Весь остальной профессиональный опыт -- это продуктовая разработка. В том числе и сейчас заказная разработка -- это только часть нашей работы.
S>>Вы же ведете себя именно как школьник, который надрачивает на какие-то абстрактные "знания". Тё>На знания никогда не поздно надрачивать.
Ну, если мозги больше занять нечем, то радибоха.
S>>Ну мы-то в порядок приведем и работать заставим. Благо опыт есть. Тё>Вот в этом не уверен
Да сколько угодно. К нам обращаются за поддержкой старого кода, мы приводим его в чувства. До сих пор успешно.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, so5team, Вы писали:
S>>Так ведь некоторые за год умудряются вобрать в себя больше, чем иные за три. Так что тут все индивидуально.
KP>Но вообще ты однозначно прав, не возможно писать на куче языков и знать эту кучу хорошо, в лучшем случае не очень плохо. Меня периодически глючит и я то один то другой язык забываю, особенно знание C++ страдает. Разве что Go не забывается, т.к. там забывать как-бы и нечего
Да ладно. Чего там в той же джаве-то знать?
Там нужно библиотеки знать и уметь их готовить.
Здравствуйте, landerhigh, Вы писали:
Тё>>Есть unordered_map и можно по нему итерировать.
L>Тема, ты так и не понял, почему для "можно итерировать" вектор предпочтительнее. L>
Да знаю, сейчас будут страшные слова "cache locality", которые ты не сможешь подтвердить результатами профайлера, например.
Личико не разбей
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, landerhigh, Вы писали:
L>>Да ладно. Чего там в той же джаве-то знать? L>>Там нужно библиотеки знать и уметь их готовить.
KP>Может у меня память херовая, конечно, или я просто программист так себе (что уже ближе к истине, как мне кажется), но я реально быстро забываю языки. Навык правильно писать на C++ без постоянной практики теряется очень быстро. Даже Python легко забывается, что уж тут
Питон заслуживает того, чтобы его постоянно забывать. Уже за само блокирование отступами и прочие приколы, смысл которых лишь в том, чтобы "не как у всех".
Вот когда пишешь проект сразу на нескольких языках и начинаешь их путать — это
Здравствуйте, landerhigh, Вы писали:
L>Да ладно. Чего там в той же джаве-то знать? L>Там нужно библиотеки знать и уметь их готовить.
Ну, не только. Для многопоточки надо бы еще понимать модель памяти (в плюсы, кстати, ее завезли позже, чем в яву).
Как дженерики устроены тоже желательно понимать (много матов в их сторону после .NETовских).
Здравствуйте, Тёмчик, Вы писали:
Тё>Есть unordered_map и можно по нему итерировать.
Ну, расскажи, как ты будешь искать отсортированный диапазон в unordered_map'е и итерироваться по нему.
Тё>Кстати, это сравнительно поздняя "фича", но лучше поздно, чем никогда.
Что "поздняя фича"? unordered_map? В бусте его аналоги уже были года с 2003-го, примерно. В стандарте, да, в 11-м появился.
Здравствуйте, Lexey, Вы писали:
Тё>>Есть unordered_map и можно по нему итерировать.
L>Ну, расскажи, как ты будешь искать отсортированный диапазон в unordered_map'е и итерироваться по нему.
Такого требования не было. Было "часто итерировать" и "иногда обращаться по ключу". Что никак не намекает на сортировку и поиск диапазона.
Тё>>Кстати, это сравнительно поздняя "фича", но лучше поздно, чем никогда.
L>Что "поздняя фича"? unordered_map? В бусте его аналоги уже были года с 2003-го, примерно. В стандарте, да, в 11-м появился.
Да, в стандарте. В бусте был hash_map и функторы, графы, — из того, что я использовал, но не только. landerhigh же про hash в 2020г не знает .
Здравствуйте, Тёмчик, Вы писали:
L>>Ну, расскажи, как ты будешь искать отсортированный диапазон в unordered_map'е и итерироваться по нему. Тё>Такого требования не было. Было "часто итерировать" и "иногда обращаться по ключу". Что никак не намекает на сортировку и поиск диапазона.
Какие тебе еще нужны требования, если изначально было сказано, что искалась замена map'у? Если ты себя позиционируешь как знаток алгоритмов, то должен, вроде, понимать, что map'ы используют там, где нужен поиск нижней/верхней границы в отсортированных данных и итерирование по диапазонам этих данных.
Или ты реально думаешь, что никто кроме тебя не догадался бы использовать какой-нибудь аналог unordered_map, если бы можно было обойтись без сортировки?
Здравствуйте, Тёмчик, Вы писали:
L>>Какие тебе еще нужны требования, если изначально было сказано, что искалась замена map'у? Тё>Так это от убогости инструментария.
Коллега, полностью согласен. Если комп не для игрулек. Мой комп 2013г скромный i7, памяти под завязку 32г. Сейчас ещё пока хватает его для моей разработки. Одна пустая виртуалка win10 крутится, но и ей я выделил 8г, чтоб могла прилагу нашу в IE загрузить. А если бы я в 2013г пожадничал памяти- сейчас бы сложно было такую найти, чтоб нарастить. Пришлось бы комп менять.
KP>Коллега, полностью согласен. Если комп не для игрулек. Мой комп 2013г скромный i7, памяти под завязку 32г. Сейчас ещё пока хватает его для моей разработки. Одна пустая виртуалка win10 крутится, но и ей я выделил 8г, чтоб могла прилагу нашу в IE загрузить. А если бы я в 2013г пожадничал памяти- сейчас бы сложно было такую найти, чтоб нарастить. Пришлось бы комп менять.
Виртуалка Win10 на 4Г тормозит
Оно и так IE11 тормозное, если ещё и памяти жмотить- совсем печаль.
давно уехал, то те кто остались теперь веб-странички с минимальным требованием в 8 Гигов памяти пишут. Блин, не думал что АйТи в АУ на столько загнило. Может быть пора вспоминать, что константа в сложности алгоритма в реальном мире может перечеркнуть все выгоды, и, о ужас для памяти сложность тоже применима, а промахи по кэшу имею значение!
давно уехал, то те кто остались теперь веб-странички с минимальным требованием в 8 Гигов памяти пишут. Блин, не думал что АйТи в АУ на столько загнило. Может быть пора вспоминать, что константа в сложности алгоритма в реальном мире может перечеркнуть все выгоды, и, о ужас для памяти сложность тоже применима, а промахи по кэшу имею значение!
Какие промахи по кэшу, спустись на землю! Когда религиозные фанатики не могут хеш от хипа отличить
Пойми, что амортизированная сложность C константа у V8 сравнима с Oracle JVM, а у той- с C++. Ибо обращение к свойствам JS обьекта в V8 происходит по смещению в памяти, там вставлен кусочек оптимизорованного C++-го кода. Специалистами Google оптимизированного, а не хайлендером, неспособным вызвать lower/upper bound ибо за 20 лет в индустрии, ниасилившего бинарный поиск.
KP>О дивный JS мир
Я не утверждал, что TS-ники в целом лучше знают алгоритмы. Я лишь утверждал, что C++ ники в целом не лучше других, и код их в целом не быстрее того же JS кода.
По IE11 не нужно судить о производительности JS- это боль.
Хотя нет, не так. Жависты в среднем знают алгоритмы и многопоточку значительно лучше плюсников. Вот теперь можешь тушить коллектор.
Здравствуйте, Lexey, Вы писали:
L>>>Ну, расскажи, как ты будешь искать отсортированный диапазон в unordered_map'е и итерироваться по нему. Тё>>Такого требования не было. Было "часто итерировать" и "иногда обращаться по ключу". Что никак не намекает на сортировку и поиск диапазона.
L>Какие тебе еще нужны требования, если изначально было сказано, что искалась замена map'у? Если ты себя позиционируешь как знаток алгоритмов, то должен, вроде, понимать, что map'ы используют там, где нужен поиск нижней/верхней границы в отсортированных данных и итерирование по диапазонам этих данных.
До введения unordered_map, было нормально использовать map в этой роли. На самом деле и сейчас нормально в целой массе случаев.
Здравствуйте, Lexey, Вы писали:
N>>До введения unordered_map, было нормально использовать map в этой роли.
L>Лет 15 назад, разве что. Не думаю, что речь идет про настолько старый код.
C++ 2011 не "Лет 15 назад," вышел,плюс ещё лет 5 индустрия догоняла.
N>>На самом деле и сейчас нормально в целой массе случаев.
L>Это ты Теме расскажи.
Тема и так твердит про убогость инструмента C++ и дремучесть отдельных представителей профессии.
Здравствуйте, Тёмчик, Вы писали:
Тё>Что я не бегаю с безумными глазами и не твержу "С++ всех быстрее"?
Покажите C++ников в этой теме, которые бы твердили "C++ всех быстрее". С ссылками и цитатами.
Тё>Квалификацию этих людей можно проверить на интервью.
Квалификация на интервью не проверяется. Происходит это уже после интервью, на испытательном сроке, и требует гораздо больше времени, чем даже многоэтапные интервью.
Тё>Пока что у меня большие сомнения в квалификации не знающих алгоритмы плюсодрочеров.
Тёмчик, еще раз: у некоторых из тех, кого вы называете "не знающими алгоритмы плюсодрочерами" в OpenSource десятки тысяч строк код. Работающего, отлаженного и задокументированного. Хотите удостоверится в своих сомнениях? Нет проблем: идете, смотрите и показываете публике откровенные косяки в коде. За любой такой найденный косяк вам только спасибо скажут.
Если уж пытаетесь кого-то осудить, то делайте это предметно. А то получается, что вам "Рабинович напел" (с)
Здравствуйте, Lexey, Вы писали:
N>>До введения unordered_map, было нормально использовать map в этой роли. L>Лет 15 назад, разве что. Не думаю, что речь идет про настолько старый код.
Тем, кому не подходило дёргать хэшмапу из boost — только с реальным вхождением C++11 в массы, а это считай началось с 2013, а местами и сейчас не выполняется.
N>>На самом деле и сейчас нормально в целой массе случаев. L>Это ты Теме расскажи.
Я плохо слежу за столь специфическим языком треда, но вроде он что-то похожее как раз и говорит?
Здравствуйте, Тёмчик, Вы писали:
Тё>Почему единственная реализация на NodeJS- правая?
Потому что ты вообще нихера не читаешь и просто пишешь что в голову пришло Ладно, может там кто-то тебе еще что-то и будет пытаться объяснить, а я пасс, удачи с JS
Здравствуйте, netch80, Вы писали:
Тё>>Я не разбираюсь в нововведениях C++ 11
N>Учитывая, что C++11 это первая версия, про которую можно реально сказать, что это C++, а не C-с-классами, такая позиция, мягко говоря, удивляет. N>(Нет, я не сторонник всё абстрагировать до предела — обычно наоборот, это я как раз пишу на C-с-классами до тех пор, пока реально не начинается от этого явная неэффективность. Но вот хотя бы move-семантика, emplace*... — это то, что абсолютно неизбежно при желании писать хоть как-то оптимально.)
Коллега, у вас цифра 80 это г.р. или год олимпиады?
В моё время C-с-классами называли код без исключений и шаблонов.
Здравствуйте, Тёмчик, Вы писали:
M>>То-то JS фреймворки каждый год новые
Тё>Не слежу за всеми. Основные гиганты это Angular (Google) и React (Facebook).
Фейсбук уже давно написал свой транспилятор своей пехапешечки в плюсики
С JS/TS проблема тут только одна — нету компилеров в плюсики. Хотя, я вроде слышал, что уже что-то появилось
Ты бы это — ну не смог — так не смог, зачем позорится-то?
Здравствуйте, so5team, Вы писали:
Тё>>Вы из тупого сплита сделали проблему века.
S>Скорее вы просто не в курсе. На обычных собеседованиях о таком не спрашивают.
Это не отменяёт тупого сплита, который вы переусложнили.
Здравствуйте, Тёмчик, Вы писали:
Тё>>>>>Вы из тупого сплита сделали проблему века.
S>>>>Скорее вы просто не в курсе. На обычных собеседованиях о таком не спрашивают.
Тё>>>Это не отменяёт тупого сплита, который вы переусложнили.
S>>Чтобы делать выводы о "переусложнили" или "недоусложнили" следует быть в теме. А вы не.
Тё>Я немного интересовался темой парсеров.
Из того, что вы чем-то и когда-то интересовались вовсе не следует наличия у вас a) знаний и b) хотя бы примерного понимания предмета. Что в разговорах с вами выяснялось уже неоднократно.
Тё>Этой штукой я анализировал исходники C++ в репозитории одной секьюрной компании Тё>https://www.boost.org/doc/libs/1_75_0/libs/spirit/doc/html/index.html
Если бы вы прочитали статью, ссылку на которую я дал, то нашли бы объяснение причин, по которым ни Boost.Spirit, ни PEGTL не подошли.
Тё>Вы даже строку не развернёте.
Не заметно.
Тё>Текст в статье подтвердил моё первоначальное предположение- вы тупой сплит строки переусложнили в кромешный шаблонный ад.
Дело в том, что в HTTP десятки заголовков и многие из них используют конструкцию #rule или *rule. Писать для каждого из таких заголовков тупой сплит строки нерационально. Рационально сделать повторно используемую обобщенную функцию, которую можно будет использовать снова, снова, снова, снова и снова. Что, собственно, и было сделано.
ИМХО, одно из самых основополагающих качеств нормального программиста -- это способность видеть повторяющиеся паттерны и умение оформлять эти паттерны в повторно используемые классы/процедуры/функции/шаблоны/генерики (под паттернами здесь понимаются не "паттерны проектировния" от банды четырех, паттерны проектирования -- всего лишь продолжение этой же тему, но на более высоком уровне).
Ну а тот, кто этого не умеет, тот затем и производит тупую копипасту и делает КА с десятками состояний
.
Тё>Понимаете разницу, я сделал когда-то анализатор сорцов C++ из доступных средств, и забыл.
Вам повезло, вы могли использовать готовые доступные средства. А мне пришлось делать свои (причины изложены в статье). Для чего взял и разобрался с PEG парсингом. Так что уж с обращением строки (в каком бы виде она не представлялась) справлюсь, если вдруг потребуется делать это.
Тё>А вы сделали простой сплиттер http header. Такое делается троечником на лабораторке за 30 минут.
Так реализация #rule из HTTP-ного RFC делается немногим сложнее, зато затем переиспользуется произвольное количество раз. В чем вы здесь увидели хоть какую-то проблему решительно непонятно.
Может быть все дело в том, что вам мозгов хватает лишь для того, чтобы вот такие портянки
Здравствуйте, Тёмчик, Вы писали:
Тё>>>Текст в статье подтвердил моё первоначальное предположение- вы тупой сплит строки переусложнили в кромешный шаблонный ад.
S>>Писать для каждого из таких заголовков тупой сплит строки нерационально.
Тё>Если бы вы открыли букварь учебник Ахо, вы бы не изобретали это убожище.
Вот сейчас не понятно: вы предлагаете под каждый HTTP-заголовок строить свой парсер или же вы PEG называете убожеством?
Тё>Токенизатор генерит поток токенов, из которого лексический анализатор строит AST.
Здравствуйте, Тёмчик, Вы писали:
N>>Учитывая, что C++11 это первая версия, про которую можно реально сказать, что это C++, а не C-с-классами, такая позиция, мягко говоря, удивляет. N>>(Нет, я не сторонник всё абстрагировать до предела — обычно наоборот, это я как раз пишу на C-с-классами до тех пор, пока реально не начинается от этого явная неэффективность. Но вот хотя бы move-семантика, emplace*... — это то, что абсолютно неизбежно при желании писать хоть как-то оптимально.)
Тё>Коллега, у вас цифра 80 это г.р. или год олимпиады?
Это количество колонок в перфокарте. (Я серьёзно.)
Тё>В моё время C-с-классами называли код без исключений и шаблонов.
Ну примерно. Хотя исключения я таки туда включаю, в умеренном количестве.
.
