M>>Ни одна методология не заставит человек вспомнить всё и покрыть все возможные варианты тестами. Кроме самых простых случаев.
M>Поэтому существуют специальные организации занимающиеся проверкой работы программистов.
M>А вы думаете в таких областях как ядерная энергетика, космитечкая техника, гражданское авиастроение, железные дороги и т.п. сторонние организации работу програмистов не проверяют?
M>Всего пару дней спустя вся эта пыль в глаза... оказалась лишь пылью в глаза. Потому что великие и могучие сторонние организации, которые проверяют, чтобы программисты покрыли все варианты тестами... проверяют 100% покрытие кода тестами. M>Лолъ.
А в чём противоречие? Проверяют 100% покрытие кода тестами, все возможные варианты ветвления кода (но не все сценарии).
Здравствуйте, alex_public, Вы писали:
BFE>>Но откуда у вас указатель, если все объекты либо глобальные/статические, либо лежат на стеке? (разумеется рекурсивные вызовы без ограничения глубины на стеке запрещены)
_>Эммм, про оператор взятия адреса ты не в курсе? )))
В курсе.
_>И да, в коде на МК у меня виртуальных функций нет. Но это не потому, что мне как-то мешается отсутствие динамического выделения памяти, а исключительно потому, что они просто не были нужны.
Здравствуйте, Marty, Вы писали:
M>Ну, к слову, такое можно вполне провернуть и на шаблонах без виртуальности. Правда, тогда всё, что пользуется интерфейсом writer'а переезжает в хидер, и код раздувается.
Ну тут дело не только в раздувании. У меня, конечно, голова скорее крутится вокруг ядерных вещей, а не прикладного кода. Если сделать на шаблонах, а не на виртуальности, то конкретную реализацию не получится, например, выселить в динамически загружаемый драйвер/плагин. С точки зрения чистого и незамутненного computer science это, может, и все равно, а с практической точки зрения совсем не все равно.
BFE>А в чём противоречие? Проверяют 100% покрытие кода тестами, все возможные варианты ветвления кода (но не все сценарии).
Опять же могу только повторить: ЛОЛъ
M>2. Потому что проверяют не только полтора варианта, которые вспомнил/придумал программист, а огромное количество вариантов, включая те, о которых программист забыл.
Вообще-то, программист не должен вспомнинать/придумывать, а должен действовать по известным методологиям.
M>Ни одна методология не заставит человек вспомнить всё и покрыть все возможные варианты тестами. Кроме самых простых случаев.
Поэтому существуют специальные организации занимающиеся проверкой работы программистов.
Сколько пафоса и гонору. А на практике что? Ах да, «мы же не говорим про все варианты, ты что, только про 100% покрытие кода тестами, но не все сценарии». А как пел, как пел.
Здравствуйте, Pzz, Вы писали:
Pzz>Потому что у меня есть, например, объект, в который можно писать. И есть, например, другой объект, который умеет писать в объект, в который можно писать. И мне сразу становится все равно, куда писать, в файл на диске, в сетевой сокет или в буфер в памяти.
Всё это хорошо, только вот на практике, ещё на этапе составления спецификации известно что, куда и с какой скорость писать, поэтому такая потребность в абстрагировании оказывается излишней.
Здравствуйте, so5team, Вы писали:
S>И после этого вы еще будете говорить про замусоревание, присущее шаблонам? Ахринеть.
Да, буду. Потому что дополнительный код, который напишу я, будет, конечно, скучным и нудным, но абсольтно понятным и прозрачным. В отличии от.
S>В конфиге и должно было быть значение в секундах (или минутах). А вот когда это значение использовалось чтобы взвести таймер, например, тогда оно и преобразовывалось в миллисекунды.
Так надо было вообще везде, по всему проекту, хранить его в миллисекундах. Если при этом в конфигурационном файле используются иные единицы, то при вводе-выводе в файл и преобразовывать. В конце концов вы к этому и пришли, насколько я понял.
S>А я пытаюсь вести разговор строго в рамках C++ против C без привлечения других примеров. Но т.к. вы про C++ не знаете, то все время вас тянет поговорить про Go.
Здравствуйте, Pzz, Вы писали:
Pzz>Насчет быстро и эффективно, это не простой вопрос. Чтобы вставить объект в середину вектора объектов, простым советским memmove не обойдешься, придется конструкторы дергать. В новомодном C++ для этого, наверное, уже придумали какой-то навороченный синтаксис, состоящий из необычного сочетания обычных знаков препинания , но слабо могу себе представить, чтобы простой программист в своей прикладной программе им воспользовался.
Кстати, любопытный пример. Только вот на самом деле в обратную сторону... Т.е. описанной "сложности" у C++ естественно нет — это просто фантазии. И реальной проблемой подобного кода может стать только существование где-то сохранённых указателей на элементы вектора, т.к. после сдвига они станут невалидными. Причём эта проблема для обоих обсуждаемых языков! Только вот в C++ этот вопрос очень чётко описан в документации к STL. Т.е. там однозначно сказано где и когда можно пользоваться такими указателями, а где нельзя. А что у нас в случае C? Ну в лучшем случае ты опишешь это во внутренней документации проекта, хотя скорее это будет просто комментарий где-то в исходника, а возможно и ничего не будет — догадывайтесь сами, можно ли хранить указатели на элементы этого вектора или нет.
Здравствуйте, Mamut, Вы писали:
M>Сколько пафоса и гонору. А на практике что? Ах да, «мы же не говорим про все варианты, ты что, только про 100% покрытие кода тестами, но не все сценарии». А как пел, как пел.
На практике это только один из пунктов проверки.
Помимо этого проводится ещё много каких проверок, в том числе проверка соответствия тестов требованиям, проверка корректности тестов, проверка самого кода, проверка соответствия hardware и software, интеграционное тестирование. И всё это стоит дорого и проводится сторонней организацией.
В случае критических компонентов обязательно написание тестирования в реальном времени, когда постоянно проверяется корректность работы приложения, отдельно проверяется корректность работы hardware. И т.д. и т.п..
Здравствуйте, Denis Ivlev, Вы писали:
S>>Или можно с другой стороны зайти: а чего добились вы? DI>Дорос до архитектора, в заказчиках известные крупнные компании, интересная работа, много выступаю на конференциях, можно сказал сделал себе из имени бренд, материально все в шоколаде: квартира в Москве в престижном районе, дача, машина из салона каждые 3 года.
Эх, прямо реально завидую... Хотелось бы и мне быть таким же. Тогда бы почти на старте жизни уже чувствовал себя состоявшимся и все эти годы жил бы расслабленным и самодовольным. А вместо этого, я и сейчас, спустя много лет и свершений, до сих пор не чувствую что состоялся.
Здравствуйте, B0FEE664, Вы писали:
BFE>Вообще-то принято считать, что виртуальный метод переопределяет поведение, а определяется поведение методом объекта.
Остается надеятся, что вы хотя бы сами поняли, что имели в виду.
BFE>Где именно?
В вопросах run-time полиморфизма.
BFE>Тот же самый код можно переписать вообще без объектов, как вы понимаете.
Нет, я не понимаю, как можно рассуждать о C++ отказываясь от кода, написанного в стиле C++.
BFE>Я тут не стремился показать это, а только то, что виртуальность без динамической аллокации большого смысла не имеет.
У вас не получилось. Ожидаемо. Потому что вы так и не смогли ответить на вопрос о том, каким боком соотносятся виртуальные функции и динамическая аллокация.
BFE>Скажите мне, что именно я не знаю.
ООП, как минимум. Хотя бы в рамках классического "инкапсуляция, наследование, полиморфизм".
Здравствуйте, B0FEE664, Вы писали:
BFE>Что ж. Ещё один аргумент против исключений. BFE>Т.е. получается С++ без исключений, без контейнеров, без умных указателей. И это следствие только одного требования.
И? Это вполне себе хороший C++. Мне вполне нравится для МК. Собственно практически всё, что ты сейчас перечислил — это как раз "тема" 90-ых. Но при этом ты по сути не затронул ни одной из новинок языка — того, куда он развивается последние десятилетия.
Здравствуйте, B0FEE664, Вы писали:
_>>>>И как это противоречит автоматическому выводу типов? ))) BFE>>>Вот так нельзя: BFE>>>
BFE>>>auto i = fun();
BFE>>>
_>>И почему же? ) BFE>Я могу только предполагать. Думаю это из-за того, что нужно точно знать когда произойдёт переполнение.
Я не про это. Почему требование на указание точных размеров типов (а не плавающих типа int, хотя они плавают только в зависимости от компилятора/процессора, ну да ладно), должно запрещать подобный код?
Здравствуйте, Pzz, Вы писали:
S>>И после этого вы еще будете говорить про замусоревание, присущее шаблонам? Ахринеть.
Pzz>Да, буду. Потому что дополнительный код, который напишу я, будет, конечно, скучным и нудным, но абсольтно понятным и прозрачным. В отличии от.
В отличии от унылого кода, который вам придется написать на чистом Си, причем для каждого типа, в C++ вам придется написать всего лишь что-то вроде:
struct distance_tag {};
using distance = strong_typedef<int, distance_tag>;
struct weight_tag {};
using weight = strong_typedef<int, weight_tag>;
И при этом вы получите возможность писать просто d1+d2 вместо вызова функций с длинными именами. И не забываем, что в чистом Си даже пространств имен нет.
Pzz>В конце концов вы к этому и пришли, насколько я понял.
Вы представляете, в C++ можно в одном месте хранить std::chrono::seconds, в другом std::chrono::milliseconds, в третьем std::chrono::minutes и все это без проблем передавать туда, где ожидается duration.
Здравствуйте, B0FEE664, Вы писали:
_>>И да, в коде на МК у меня виртуальных функций нет. Но это не потому, что мне как-то мешается отсутствие динамического выделения памяти, а исключительно потому, что они просто не были нужны. BFE>Ну вот, хоть кто-то понимает...
Более того, сам по себе динамический полиморфизм нужен в достаточно редких случаях. Однако, т.к. в 90-ых другого подхода по сути и не было, тогда с помощью него решались абсолютно все задачи полиморфизма. И соответственно все библиотеки родом из тех времён (типа той же Qt и т.п.) до сих пор несут этот печальный отголосок прошлого. Хотя сейчас 90% таких задач можно удобно решить с помощью шаблонного параметра и лямбды. Однако к сожалению библиотек такого масштаба написанных на современном C++ не существует, поэтому приходится использовать что есть...
Здравствуйте, alex_public, Вы писали:
M>>>>Смотреть в отладке на регистры _>>>Так регистры же все отображены в память, и соответственно банальный gdb без проблем подтягивает их значения (можно хоть в командной строке смотреть), и далее любая IDE показывает их в стандартном интерфейсе отладчика (отслеживания переменных). Что там ещё может быть нужно? ) M>>Удобство пользования этим
_>Так я и спрашиваю, в чём проявляется это самое удобство.
Что-та уже лень становится. Ты пробовал отлаживаться в кейле и в эклипсе, например?
_>Я уже молчу про то, что при использование библиотек от данного МК (типа HAL или LL), эти самые регистры не просто отображены в память, а ещё и находятся в соответствующих удобных объектных структурах, которые уж точно лучше подходят для контроля за периферией.
M>>Ну, к слову, такое можно вполне провернуть и на шаблонах без виртуальности. Правда, тогда всё, что пользуется интерфейсом writer'а переезжает в хидер, и код раздувается.
Pzz>Ну тут дело не только в раздувании. У меня, конечно, голова скорее крутится вокруг ядерных вещей, а не прикладного кода. Если сделать на шаблонах, а не на виртуальности, то конкретную реализацию не получится, например, выселить в динамически загружаемый драйвер/плагин. С точки зрения чистого и незамутненного computer science это, может, и все равно, а с практической точки зрения совсем не все равно.
Ну, а у меня голова крутится и вокруг размера кода. Потому, что когда у тебя на всё про всё 192Кб (и это еще в жирных камушках), то приходится
Здравствуйте, alex_public, Вы писали:
_> Хотя сейчас 90% таких задач можно удобно решить с помощью шаблонного параметра и лямбды.
Получив в подарок раздутое время компиляции необходимость держать метод в заголовке, что в сочетании с первым делает процесс разработки очень приятным. Поправил, запустил компиляцию, пошел читать рсдн.
Здравствуйте, B0FEE664, Вы писали:
Pzz>>Потому что у меня есть, например, объект, в который можно писать. И есть, например, другой объект, который умеет писать в объект, в который можно писать. И мне сразу становится все равно, куда писать, в файл на диске, в сетевой сокет или в буфер в памяти.
BFE>Всё это хорошо, только вот на практике, ещё на этапе составления спецификации известно что, куда и с какой скорость писать, поэтому такая потребность в абстрагировании оказывается излишней.
И? Надо писать и COM-порт и на флешку.
А еще я хочу, чтобы тот же код работал в утилите на компе, и там уже, куда писать, определяется в рантайме
