Здравствуйте, alex_public, Вы писали:
M>>armcc в составе кейла поддерживает только одинадцатый стандарт
_>Keil? Кому сейчас нужно это недоразумение, сделанное в те времена, когда мир программирования электроники жил совершенно отдельно от мира "взрослого" программирования? Сейчас для работы с МК без проблем доступны полноценные мощные IDE (QtCreator, VisualStudio и т.д.), а не эти убогие пережитки 90-ых.
Креатор — гавно сам по себе, что студия как-то умеет — недавно узнал, еще не попробовал. Но вообще работа с периферией в кейле лучше других на порядок
Здравствуйте, alex_public, Вы писали:
_>Ну тут всё же надо однозначно отметить, что у C++ (а так же у Rust, D и им подобным) цена такой обёртки нулевая. Т.е. нет никаких накладных расходов (проверка — это не накладные расходы, т.к. она будет в любом случае на любых языка, только просто написана руками) от того факта, что используется специальный тип, а не int. А вот скажем на языках типа Java такую автоматическую проверку просто невозможно сделать без накладных расходов, поэтому там или всё руками или очень медленно.
Если в языке невозможно сделать какую-то автоматическую проверку, значит придется жить без автоматической проверки. Это доставляет некоторое неудобство, но совершенно не смертельно.
Самый плохой вариант — это язык типа яваскрипта, в котором можно хоть складывать строки с числами, и ни к каким ошибкам, ни статическим, ни в рантайме это не приводит.
Здравствуйте, Pzz, Вы писали:
_>>И вот тут ты можешь открыть для себя семантику перемещения. ) Pzz>Я понимаю про семантику перемещений. Синтаксис, разумеется, не знаю, но стоящие за ней идеи понимаю хорошо.
Pzz>И вот представь себе, я проектирую сложную структуру данных (структуру не как struct, а структуру, представляющую сложную хрень. Ну, например, географическую карту, или промежуточное представление программы между синтаксическим анализом и кодогенерацией, с чем работает оптимизатор), и мало того, что моя структура данных сама по себе сложна, я еще должен думать про семантику перемещений. Знаешь, извини, моя голова в этом месте будет занята связами в графе, а не владением памятью.
Повторюсь ещё раз: я вполне понимаю такую аргументацию скажем от программиста на Java и Python. Да, они потеряют на этом в эффективности кода, но это может быть вполне допустимо условиями задачи. Но от программистов на C и ему подобных языков, подобная аргументация не может работать. Потому что программисту на C точно так же требуется продумывать время жизни каждого объекта.
Pzz>>>Я понимаю, что всякие там умные указатели в C++ отчасти автоматизируют управление памятью. Но она не становится от этого концептуально проще. _>>Вообще говоря становится. Pzz>Вообще говоря, нет. Можно, конечно, делать вид, что присваивание/передача строк по значению работает так же, как присваивание/передача целых чисел по значению. Там же семантика перемещений, ага, лишних аллокаций на куче почти и не видно. Только когда их вдруг становится видно, то получается хуже даже, чем в языке, в котором все руками — потому что в чем дело умному понятно (а дураку и это не понятно, ему же всю жизнь внушали, что внутренний мир объекта его не касается), а что делать не очень-то понятно, внутрь объекта особенно-то и не пускают.
Вообще не понял о чём ты тут.
_>>Т.е. грубо говоря можно явно выделить 3 основных вида управления памятью: Pzz>Давай сойдемся на том, что мы оба квалифицированные люди, и очевидные вещи понимаем одинаково хорошо
Ну вообще то я как раз написал, что я не понимаю, по какой причине (кроме незнания естественно), можно выбирать вариант с ручным управлением памятью. Может ты подскажешь? Т.е. ты конечно же уже написал, что типа "простота — это хорошо", но дело в том, что это самую простоту ты так и не продемонстрировал ни на одном примере конкретного кода. По моему опыту, код на C++ внешне обычно выглядит даже проще аналогов на C.
Здравствуйте, Marty, Вы писали:
_>>Keil? Кому сейчас нужно это недоразумение, сделанное в те времена, когда мир программирования электроники жил совершенно отдельно от мира "взрослого" программирования? Сейчас для работы с МК без проблем доступны полноценные мощные IDE (QtCreator, VisualStudio и т.д.), а не эти убогие пережитки 90-ых. M>Креатор — гавно сам по себе, что студия как-то умеет — недавно узнал, еще не попробовал. Но вообще работа с периферией в кейле лучше других на порядок
Вообще то QtCreator с подключённым анализатором кода на базе clang, работает на голову лучше VisualStudio. )))
Здравствуйте, Denis Ivlev, Вы писали:
DI>Посмейся, для адекватных людей я сказал достаточно — пишите, кому интересно.
Если не ошибаюсь, то вот докладчики, которые были на Highload++ и в 2018, и в 2019-ом:
Иван Панченко (Postgress Professional)
Андрей Бородин (Яндекс) Пётр Зайцев (Percona)
Вадим Подольный (Физприбор)
Николай Самохвалов (PostgreSQL.support)
Александр Кукушкин (Zalando SE)
Владислав Шпилевой (Tarantool)
Александр Крижановский (Tempesta Technologies) Алексей Миловидов (Yandex)
Артем Просветов (CleverDATA) Олег Бартунов (Postgres Professional)
Евгений Кузовлев (EcommPay IT)
Владимир Колобаев (Avito)
Александр Сибиряков (Scrapinghub)
Из этого списка вычеркнуты те, кто вряд ли занимались бы такой фигнёй, как унылый троллинг RSDN-овцев.
Так же вряд ли это Андрей Бородин, т.к. он из Яндекса, а "Denis Ivlev" говорил, что Яндекс у него в прошлом.
Мой главный фафорит -- это Вадим Подольный из Физприбора, который на Highload++ рассказывает про высоконагруженную распределенную систему управления АЭС. Но он вроде всю жизнь в атомной энергетике, про Яндекс упоминания нет.
Архитектор систем распределенной обработки больших объемов данных, высоконагруженных систем. Автор фреймворка для масштабного обхода веба Frontera. Работал 5 лет в Яндексе, в отделе качества поиска. Занимался разработкой социального поиска, вопрос-ответного и улучшением сниппетов. Затем провел 2 года в антивирусе Avast!, построил автоматическое разрешение ложных срабатываний. Интересуется проблемами обработки данных в больших объемах и информационного поиска.
Здравствуйте, alex_public, Вы писали:
_>Повторюсь ещё раз: я вполне понимаю такую аргументацию скажем от программиста на Java и Python. Да, они потеряют на этом в эффективности кода, но это может быть вполне допустимо условиями задачи. Но от программистов на C и ему подобных языков, подобная аргументация не может работать. Потому что программисту на C точно так же требуется продумывать время жизни каждого объекта.
Это, на самом деле, отзвук прозвучавшей здесь в другой нитке обсуждения мысли, что C++ — язык, пригодный для работы со сложными абстрактными данными. Не пригодный, как и C не пригодный.
_>Вообще не понял о чём ты тут.
О том, что абстракции C++ подтекают. Слишком большая разница между тем высокоуровневым интерфейсом, которые народ обычно пытается выразить, и низкоуровневыми кишками под капотом.
_>Ну вообще то я как раз написал, что я не понимаю, по какой причине (кроме незнания естественно), можно выбирать вариант с ручным управлением памятью. Может ты подскажешь? Т.е. ты конечно же уже написал, что типа "простота — это хорошо", но дело в том, что это самую простоту ты так и не продемонстрировал ни на одном примере конкретного кода. По моему опыту, код на C++ внешне обычно выглядит даже проще аналогов на C.
Я не выбираю ручное управление памятью, это ложная дилема. Я выбираю язык, который я способен понять, и при этом в голове останется достаточно места для той задачи, которую я решаю. Если за такой выбор языка приходится платить какими-то удобствами, ОК, я обойдусь без этих удобств.
Здравствуйте, Marty, Вы писали:
_>>Вообще то QtCreator с подключённым анализатором кода на базе clang, работает на голову лучше VisualStudio. ))) M>Чем лучше?
Ну для начала он способен распарсить любой C++ код, а не только "hello world" (включая и такой, который не может даже CLion, не говоря уже о VisualStudio, типа каких-нибудь жирных шаблонов из Boost'а). И далее он (в смысле libclang) строит полноценное AST со всеми свойствами, а не некую эмпирическую хрень. Так что в итоге это позволяет IDE выдавать гораздо более полезные подсказки, реализовывать более эффективное автодополнение, навигацию, рефакторинг.
_>>А что ещё за "работа с периферией"? ) M>ADC/DAC/I2C/SPI/UART/CAN/TIM/DMA etc
Я в курсе что такое периферия. Мне не понятен термин "работы" с ней, в контексте IDE.
_>>>А что ещё за "работа с периферией"? ) M>>ADC/DAC/I2C/SPI/UART/CAN/TIM/DMA etc
_>Я в курсе что такое периферия. Мне не понятен термин "работы" с ней, в контексте IDE.
Здравствуйте, kaa.python, Вы писали:
B>> Поэтому имхо знание языка является определяющим, а не предметная область. Но, насколько это соответствует истине, покажет практика.
KP>Так не работает и с положением вещейна рынке это слабо коррелирует. Язык может быть совершенно любым, просто подходящим, в рамках предметной области на которой ты специализируешься.
Я здесь не про язык вообще, а конкретно про С++. Он сложнее чем большинство предметных областей. Если человек знает С++, он осилит почти что угодно. Поэтому знание С++ является определяющим, на мой взгляд.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, Sharov, Вы писали:
B>>А вот С++, со всеми подводностями, учить долго, и не факт что человек вообще сможет научится. Поэтому имхо знание языка является определяющим, а не предметная область. Но, насколько это соответствует истине, покажет практика.
S>Вы всерьез полагаете, что в сложной предметной области стоит использовать язык, который еще сложнее? С тз. временных затрат на обучение. По-моему это неправильно.
Так язык-то уже выучен. Языков программирования гораздо меньше, чем предметных областей.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, AlexGin, Вы писали:
B>>Если пишется софт для медоборудования, вряд ли много найдется кандидатов, что уже писали софт для этого оборудования. Все равно медоборудованию придется учить, и это не так долго (условно, полгода-год).
AG>В этом контексте мне непонятно, о каком сроке полгода-год ты сообщил выше? AG>Это сроки разработки первой версии ПО? AG>Когда можно будет на практике проверить, что программист усвоил (а что — нет), проверив его софт?
Я пожалуй не очень удачный пример привел, т.к. сам такой софт не разрабатывал. Предполагаю, что предметная область такого софта будет складываться из следующего:
— работа непосредственно с оборудованием (драйвера, обмен через порт и т.п.)
— принятые стандарты безопасности (как тестировать, как реагировать на сбои оборудования и т.п.)
— стандарты медицинской отчетности и конфиденциальности данных
Вот на все это имхо и надо полгода-год.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, Ip Man, Вы писали:
B>> Поэтому имхо знание языка является определяющим, а не предметная область.
IM>Когда-нибудь ты поймешь, что был неправ. Что все в точности наоборот. Попомни мое слово.
Скажем так — к этому всё и идет. Но всё-таки постепенно. Раньше, зная С++, ты мог закодить хоть сервер, хоть криптографию, да что угодно (я 20 лет назад вполне написал клиент-сервер систему на TCP/IP сразу после выпуска из ВУЗа). А сейчас, чтобы закодить тот же сервер, надо хорошо шарить в многопоточности, масштабируемости и прочих high load решениях. Но их имхо пока еще можно освоить, как мне кажется, за год-другой. Но дальше будет хуже, да.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
В данной теме вы общаетесь с Евгением Охотниковым, компания "СтифСтрим". Мы развиваем такие продукты, как SObjectizer, RESTinio и json_dto, оказываем техподдержку пользователям этих продуктов, даем консультации и выполняем разработку под заказ.
Как и для чего наши клиенты используют результаты нашей работы не ваше дело.
Здравствуйте, sergey2b, Вы писали:
S>это вы фото имеете ввиду
Да нет проблем — подарю настоящий.
Или же, в порывах мазахизма, заставляющего писать на ЯП совершенно неприспособленном для данного класса задач, пошли дальше...
И теперь, вместо мебели, стали практиковать сон на фото-бумаге
Здравствуйте, Denis Ivlev, Вы писали:
S>>Так с кем встречаться-то? С вымышленным Денисом Ивлиевым? DI>Игра с голубем в шахматы становится весьма скучной.
Наконец то ты это заметил, голубь ты наш.
S>>Анонимный нонейм может что-то предложить? Рассмешили. DI>Посмейся, для адекватных людей я сказал достаточно — пишите, кому интересно.
Никому не интересно
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
