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

Pzz>Чтобы вставить объект в середину вектора объектов, простым советским memmove не обойдешься, придется конструкторы дергать. В новомодном C++ для этого, наверное, уже придумали какой-то навороченный синтаксис, состоящий из необычного сочетания обычных знаков препинания , но слабо могу себе представить, чтобы простой программист в своей прикладной программе им воспользовался.

Ух жесть, я даже не думал что степень твоего непонимания простирается настолько глубоко!

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

N>Работая в АМД приходилось использовать Perforce, который жутко не удобен.
Кстати P4 ещё не самый плохой вариант, а некоторых его тулов (Timelapse) мне очень сейчас в гите не хватает.

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

M>>>Ну, ващет 1) сетевых сервисов не так и много,
НС>>Много.
M>Немного

Любой слушающий порт сервис, тысячи их


M>>> и их таки вылизывают
НС>>Т.е. линух не так плох?
M>При чем тут линукс, если всё тоже самое запускается на фряхе, или на любой другой системе?

Т.е. на линуксе оно, не смотря на вылизанность, уязвимо?


M>>>2) по настоящему защищенные сервера обычно делают на фряхе и её производных
НС>>Не надо выдумывать.
M>Я не выдумываю

Выдумываешь. Подавляющее большинство сетевых сервисов сейчас на линухе. Даже в Ажуре линуха уже больше винды и доля растет.


M>>> 3) локально таки на порядки больше векторов для атаки, чем через сетевые сервисы
НС>>Только это не особо кому интересно, взлом по стеи намного важнее.
M>С чего бы?

С того что пользы с десктопа, к которому есть несетевой доступ — не особо много.

M>>>4) таки сервера атакуют и хакают
НС>>И там есть какие то особые проблемы именно у линукса?
M>Может, те же, что у винды на десктопе?

Десктоп в контексте взлома мало интересен.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Marty, Вы писали:

M>>>>Ну, ващет 1) сетевых сервисов не так и много,
НС>>>Много.
M>>Немного

НС>Любой слушающий порт сервис, тысячи их

И? Можно первую тысячусотню хотя бы?



M>>>> и их таки вылизывают
НС>>>Т.е. линух не так плох?
M>>При чем тут линукс, если всё тоже самое запускается на фряхе, или на любой другой системе?

НС>Т.е. на линуксе оно, не смотря на вылизанность, уязвимо?

Думаю, да, в местах стыковки с системой.



M>>>>2) по настоящему защищенные сервера обычно делают на фряхе и её производных
НС>>>Не надо выдумывать.
M>>Я не выдумываю

НС>Выдумываешь. Подавляющее большинство сетевых сервисов сейчас на линухе. Даже в Ажуре линуха уже больше винды и доля растет.

Да, потому что линукс на волне хайпа последнее время неплохо растет. Как это противоречит моему высказыванию —


M>>>> 3) локально таки на порядки больше векторов для атаки, чем через сетевые сервисы
НС>>>Только это не особо кому интересно, взлом по стеи намного важнее.
M>>С чего бы?

НС>С того что пользы с десктопа, к которому есть несетевой доступ — не особо много.

Ботофермы на серверах уже разводят?


M>>>>4) таки сервера атакуют и хакают
НС>>>И там есть какие то особые проблемы именно у линукса?
M>>Может, те же, что у винды на десктопе?

НС>Десктоп в контексте взлома мало интересен.

Ну, то есть ты не понял, что я имел в виду, но надо же что-то ляпнуть, да?
Ну и то, что ты ляпнул, не соответствует действительности

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

Pzz>Тут и есть полэкрана кода. Там 12 строк, в стандартном экране их 24.

Стандартном ?
Простите, но VT-100 выпустили в 1978 году.

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

BFE>Если у вас есть указатель на базовый класс, то вызов виртуального метода оправдан.
BFE>Но откуда у вас указатель, если все объекты либо глобальные/статические, либо лежат на стеке? (разумеется рекурсивные вызовы без ограничения глубины на стеке запрещены)

Фабрика вернула указатель на статически сконструированный объект

После чего объект используется исключительно через свой интерфейс — помещается в список истории, активируется, обрабатывает пользовательский ввод. Смена фокуса по видимым объектам, рассчет размеров и т.д.

Навигация "вглубь", создание дочерних обьектов — через фабрику, по id. Вместо разрешения создавать всем всё, да еще и в куче. Заодно сразу строгий контроль расхода ОЗУ, никакой фрагментации кучи, плюс обьекты сохраняют своё промежуточное состояние, без необходимости его сериализовать и восстанавливать, как в случае с созданием "начисто".

Лично применял такой подход в UI для микроконтроллеров.

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

Pzz>Чтобы вставить объект в середину вектора объектов, простым советским memmove не обойдешься, придется конструкторы дергать.

То ли дело в чистом си! Нужна копия сокета при accept — выделим память и алга в нее memcpy. В результате CVE-2017-8890, чудесная дырочка, через которую буханки трескались как орешки. С success rate выше 98% (сорян, но выиграть две гонки с 100% рейтом это уже фантастика).

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

M>Контейнеры и смарт указатели — да, их нет

Необязательно. Существуют контейнеры, которые работают в строго выделенной им области памяти.

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

Pzz>>Чтобы вставить объект в середину вектора объектов, простым советским memmove не обойдешься, придется конструкторы дергать. В новомодном C++ для этого, наверное, уже придумали какой-то навороченный синтаксис, состоящий из необычного сочетания обычных знаков препинания , но слабо могу себе представить, чтобы простой программист в своей прикладной программе им воспользовался.

CC>Ух жесть, я даже не думал что степень твоего непонимания простирается настолько глубоко!

Это он про insert?

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

M>>Контейнеры и смарт указатели — да, их нет

IID>Необязательно. Существуют контейнеры, которые работают в строго выделенной им области памяти.


Стандартные? 03/11?

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

Pzz>>>Чтобы вставить объект в середину вектора объектов, простым советским memmove не обойдешься, придется конструкторы дергать. В новомодном C++ для этого, наверное, уже придумали какой-то навороченный синтаксис, состоящий из необычного сочетания обычных знаков препинания , но слабо могу себе представить, чтобы простой программист в своей прикладной программе им воспользовался.

CC>>Ух жесть, я даже не думал что степень твоего непонимания простирается настолько глубоко!

N>Это он про insert?

Похоже на то

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

_>> Хотя сейчас 90% таких задач можно удобно решить с помощью шаблонного параметра и лямбды.
N>Получив в подарок раздутое время компиляции необходимость держать метод в заголовке, что в сочетании с первым делает процесс разработки очень приятным. Поправил, запустил компиляцию, пошел читать рсдн.

Может просто стоит иметь компьютер подходящий для разработчика (как минимум с топовым SSD)?

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

_>>Более того, сам по себе динамический полиморфизм нужен в достаточно редких случаях. ... Хотя сейчас 90% таких задач можно удобно решить с помощью шаблонного параметра и лямбды.
lpd>Очень любопытно, чем шаблоны в данном случае лучше? Типа быстрее и поэтому эти шаблоны везде нужно городить вместо обычного полиморфизма?

Что значит "обычного"? Мне кажется очевидно, что динамический полиморфизм не должен быть обычным. Хотя бы потому, что задачи, в которых выбор исполняемого кода определяется только в рантайме является явно не большинством случаев. А "обычным" динамический полиморфизм стал в 90-ые во времена моды на эту тему (тогда думали что вообще всё будет решаться через ООП с наследованием и т.п.), да и другие средства были не особо развитыми.

Если же говорить о конкретных технических моментах, то тут есть целый ряд нюансов. Во-первых статический полиморфизм гарантирует корректность кода, т.к. всё проверяется компилятором на стадии сборки и не может случиться ситуация с неверно переданным указателем. Во-вторых естественно вопрос производительности. Статический полиморфизм очевидно на порядки эффективнее, т.к. вызов не просто идёт напрямую (а не косвенно, как в случае виртуальной функции), но и практически гарантированно инлайнится.

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

M>Не подкинешь ссылок на настройку студии для эмбеда?

Там можно конечно руками (через openocd и ещё кучу мелочей), но это весьма не тривиально и долго. А можно просто поставить этот https://visualgdb.com продукт (кстати, делают ребята с нашего форума), но он не бесплатный.

M>Нужно мне состояние GPIO порта посмотреть — иду в peripherals, выбираю нужный порт, оно на отдельной вкладочке появляется, регистры там расписаны, с пояснениями, где надо отдельные биты/группы бит выделены, в реалтайме меняются, в реалтаеме же можно новое значение задать. Красота.

Мне кажется, что для каких-то серьёзных применений (а не мигания светодиодами) в реалтайме не подходит ни обычный отладчик, ни подобная штука. Просто из-за скорости изменения. А подходит только что-то типа STMStudio, в которой строится график значения, который можно сравнивать с параллельным ему графиком другой переменной — по сути такой софтверный осциллограф.

M>А, еще хз, может и есть в остальных средах — но в кейле через SWD без каких-либо шевелений принтфами пользоваться, и оно попадает в кейловское окошко (забыл, как оно точно зовется)

Советую глянуть на такую штуку, как jlink (его кстати можно прошить даже в обычный st-link с Али). Там очень много вкусностей. И в том числе идёт RTT.

M>Ну а так да — в 96 году в инсте изучали 51 контроллеры , писали в кейле — я когда сюда пришел — смотрю — а кейл-то совсем не изменился

Вот вот. )

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

_>Может просто стоит иметь компьютер подходящий для разработчика (как минимум с топовым SSD)?

Почему ты думаешь, что у меня неподходящий?
Местные фанаты С++ похоже на самом деле ничего сложнее laba2 не писали.

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

M>>Не подкинешь ссылок на настройку студии для эмбеда?

_>Там можно конечно руками (через openocd и ещё кучу мелочей), но это весьма не тривиально и долго.

Ясно


_>А можно просто поставить этот https://visualgdb.com продукт (кстати, делают ребята с нашего форума), но он не бесплатный.

Это видел, что-то не поперло


M>>Нужно мне состояние GPIO порта посмотреть — иду в peripherals, выбираю нужный порт, оно на отдельной вкладочке появляется, регистры там расписаны, с пояснениями, где надо отдельные биты/группы бит выделены, в реалтайме меняются, в реалтаеме же можно новое значение задать. Красота.

_>Мне кажется, что для каких-то серьёзных применений (а не мигания светодиодами) в реалтайме не подходит ни обычный отладчик, ни подобная штука.

Ну, у нас все устройства работают в режиме мастер-слейв, на роботе может быть до десятка-другого разных плат, которые являются мастерами для одних и слейвами для других. На верщине — главный мастер, комп или какой-то человечий пульт. Очень удобно задавать всякие управляющие параметры в кейле без прерывания. Иногда прерывать нельзя вообще — управляемый объект тупо погореть может.


_>Просто из-за скорости изменения. А подходит только что-то типа STMStudio, в которой строится график значения, который можно сравнивать с параллельным ему графиком другой переменной — по сути такой софтверный осциллограф.

А, так для этого есть FreeMaster


M>>А, еще хз, может и есть в остальных средах — но в кейле через SWD без каких-либо шевелений принтфами пользоваться, и оно попадает в кейловское окошко (забыл, как оно точно зовется)

_>Советую глянуть на такую штуку, как jlink (его кстати можно прошить даже в обычный st-link с Али). Там очень много вкусностей. И в том числе идёт RTT.

А в чем его плюс по сравнению с ST-Link'ом?

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

_>Эх, прямо реально завидую... Хотелось бы и мне быть таким же. Тогда бы почти на старте жизни уже чувствовал себя состоявшимся и все эти годы жил бы расслабленным и самодовольным. А вместо этого, я и сейчас, спустя много лет и свершений, до сих пор не чувствую что состоялся.

Вот что плюсы с людьми делают — жил бы да радовался, а он все превозмогает

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

_>Если же говорить о конкретных технических моментах, то тут есть целый ряд нюансов. Во-первых статический полиморфизм гарантирует корректность кода, т.к. всё проверяется компилятором на стадии сборки и не может случиться ситуация с неверно переданным указателем.
Странно звучат "все проверяется", и "гарантирует корректность кода", т.к. в реальных программах основную сложность составляют проблемы вовсе не те, что пытаются решать создатели современного С++ своими дополнительными проверками корректности типов или raii, либо этих мер все равно недостаточно. Получается, что этот современный С++ только запутывает реализации и без того сложных алгоритмов на ровном месте.
Кому-то лес из скобочек нравится, кому-то нет, поэтому С++ перестал быть универсальным языком.

_>Во-вторых естественно вопрос производительности. Статический полиморфизм очевидно на порядки эффективнее, т.к. вызов не просто идёт напрямую (а не косвенно, как в случае виртуальной функции), но и практически гарантированно инлайнится.
Ну это уже совсем экономия на спичках. В отдельных критических участках кода может такой выигрыш в скорости и имел бы смысл, но и в таких случаях обычно нужны simd-инструкции, а не шаблоны. А оптимизация каждой функции только вредит проекту усложнением кода. Использовать везде шаблоны это все равно как раньше писали все полностью на ассемблере ради некой скорости.

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

_>>Во-вторых естественно вопрос производительности. Статический полиморфизм очевидно на порядки эффективнее, т.к. вызов не просто идёт напрямую (а не косвенно, как в случае виртуальной функции), но и практически гарантированно инлайнится.
lpd>Ну это уже совсем экономия на спичках. В отдельных критических участках кода может такой выигрыш в скорости и имел бы смысл, но и в таких случаях обычно нужны simd-инструкции, а не шаблоны. А оптимизация каждой функции только вредит проекту усложнением кода. Использовать везде шаблоны это все равно как раньше писали все полностью на ассемблере ради некой скорости.

Это очевидно неверно, шаблоны действуют строго противоположно аналогии с ассемблером. Они наоборот: перекладывают максимум работы по оптимизации из рантайма на компилятор. И SIMD-инструкции при этом никто не отменял: функции специализируются и их внутренность реализуется на интрисиках. Собственно Intel MKL внутри так и выглядел, когда я его видел несколько лет назад.

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

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

lpd>>Использовать везде шаблоны это все равно как раньше писали все полностью на ассемблере ради некой скорости.

N>Это очевидно неверно, шаблоны действуют строго противоположно аналогии с ассемблером. Они наоборот: перекладывают максимум работы по оптимизации из рантайма на компилятор.

Смысл все равно в усложнении всего кода программы ради эфемерного общего ускорения.