Deepseek примерно так же делает: Отличное замечание! Этот код действительно не скомпилируется. Давайте рассмотрим критически важный момент: for_each() потребляет итератор и здесь необходимо использовать map()
Словно это я ему этот г*нокод подсунул, а не он мне
Я заметил, что когда изучаешь новый язык программирования до уровня хотя бы свободно можешь без подсказок и идиоматически решать задачи на leetcode во всех остальных языках программирования у меня тоже меняется мышление, так после Си я стал безбожно орудовать адресной арифметикой и кастами, после C++ пихать дженерики и аналоги stl, после Rust понеслась функциональщина, move-семантика, в голове строгий контроль по RAII, уже не думаешь, а и так сойдёт, думаешь что делать если что-то пойдет не так, при этом старый стиль не куда не девается, просто смотришь на него под другим углом
Но есть и минусы, когда шпаришь на одном языке, потом нужно время переключиться на другой, подводит синтаксис, всё мешается в кучу до уровня автоматизма
Как то меня спросили про виды полиморфизма, я сказал, ох ребята... вам какого отсыпать)))
Помню с блеском прошел техническую часть, потом через пару дней мне по скайпу позвонила такая мадам, я сначала думал обсудим какие-то вопросы устройства на работу, а там началось "почему вы считаете что принесёте пользу нашему коллективу", "какие качества выделяют вас как профессионала", "кем вы видите себя через 5 лет", и прочее, я конечно их послал, у меня и без таких клоунов полно оферов
Если вы не знаете что тестировать значит либо не поняли задачу, либо вам её плохо поставили, стоит остановиться и подумать над задачей лучше, если задача звучала как сделай как-нибудь, то и делай как нибудь, получишь соответственно, TDD занимается вопросами как надо писать код, как не надо изучает психиатрия
А мне имея за плечами больше 10 систем автоматики и учпу типа резки кристаллов, литографии и электроэрозионной обработки, как-то на собеседовании дедок заявил что это всё мелочи вот у нас датчики пожарной сигнализации, неужели не интересно заняться серьезным проектом...
Я там просто промолчал и больше трубку от них не брал, не то чтобы мало предлагали, он вообще так и не понял чем я занимаюсь и что их сигнализация для меня проект на коленках, где ничего нового не будет
Берешь любого C/C++ выше среднего и через пару месяцев он Rust разработчик, причем настолько, что смотреть на код на С++ будет с недоумением, я проверял на практике
Осциллограф, логический анализатор и два лабораторных БП, больше ничего лично мне не требуется, ну ИК стол ещё как-то подарили, макеты домой привозят, как-то делал автоматику для ванн, эти клоуны мне всю ванну в сборе привезли... Зато ускорило разработку, каждый день жена пилила когда уже бандуру заберут
Совет из TDD: Начинайте писать тест ДО того как создали метод, убеждаемся что тест не проходит и только потом создаём метод который проходит тест, рефакторим, убеждаемся что проходит, думаем а какой функционал ещё нужен? добавляем новый тест, убеждаемся что он не проходит, меняем или добавляем новый метод, чтобы он его проходил, рефакторим и смотрим чтобы уже два теста проходили, и так накручиваем
Такой способ даёт 100% покрытие и 100% предсказуемость, а так же крепкий сон, исключает драмы в стиле почему когда я парсил json у меня дропнулась таблица в бд
если ты не знаешь чего тестировать - скорее всего либо тебе не ясна задача, либо тебе дали задание в стиле "сделай как нибудь" , значит и делай как нибудь, но я так не делаю, потому что потом всё будешь переписывать, руководствуюсь другим принципом - стараюсь делать хорошо, хренова всегда получится, когда ты пишешь тест ты четко понимаешь что ты хочешь на выходе при таком входе, а значит и проще объяснить железяке, поэтому относиться ко времени на тесты нужно как на проектирование, а не само программирование
Но упарываться в юнит-тесты тоже не нужно, если как минимум три исключения:
1) не нужно тестировать приватные методы, не нужно ничего открывать во вне, только интерфейс, который задуман, покрытие обеспечивается косвенными методами
2) не нужно пихать в тесты бизнес логику, её нужно тестировать, а не сувать в тест, иначе тест станет хрупким и бесполезным
3) не нужно загрязнять тестами release код, продукт ничего не должен знать о тестах, иметь какие-то скрытые параметры и методы только для прохождения теста
1) что такое классическое ООП? Автор концепции ООП сказал что C++/Java это вообще не то что он имел в виду и пошёл пилить Smalltalk
2) дедлоки это архитектурная проблема, а не проблема языка, и на чистых функциях хаскеля вы можете добиться дедлока, что показано и через машину Тьюринга и через исчисление Чёрча
3) Еесли мы говорим про обычный компьютер, то 1000 потоков это антипаттерн, у вас на переключение задач в ОС уйдет больше времени, чем на саму задачу, плюс под каждый поток по 2 метра отрезать? Не жирно, есть корутины, есть лёгкие потоки...
Вообще хочется конкретного кода, в чём там у вас проблема
А зачем тогда эта избыточность? Вот что могло пойти не так если $ печатать как и все остальные символы?)))
Это тебе нейронка насобачила? Нет никакого смысла делать отдельную ветку для $
Deepseek примерно так же делает: Отличное замечание! Этот код действительно не скомпилируется. Давайте рассмотрим критически важный момент: for_each() потребляет итератор и здесь необходимо использовать map()
Словно это я ему этот г*нокод подсунул, а не он мне
Я заметил, что когда изучаешь новый язык программирования до уровня хотя бы свободно можешь без подсказок и идиоматически решать задачи на leetcode во всех остальных языках программирования у меня тоже меняется мышление, так после Си я стал безбожно орудовать адресной арифметикой и кастами, после C++ пихать дженерики и аналоги stl, после Rust понеслась функциональщина, move-семантика, в голове строгий контроль по RAII, уже не думаешь, а и так сойдёт, думаешь что делать если что-то пойдет не так, при этом старый стиль не куда не девается, просто смотришь на него под другим углом
Но есть и минусы, когда шпаришь на одном языке, потом нужно время переключиться на другой, подводит синтаксис, всё мешается в кучу до уровня автоматизма
Как то меня спросили про виды полиморфизма, я сказал, ох ребята... вам какого отсыпать)))
Помню с блеском прошел техническую часть, потом через пару дней мне по скайпу позвонила такая мадам, я сначала думал обсудим какие-то вопросы устройства на работу, а там началось "почему вы считаете что принесёте пользу нашему коллективу", "какие качества выделяют вас как профессионала", "кем вы видите себя через 5 лет", и прочее, я конечно их послал, у меня и без таких клоунов полно оферов
Но всё же они исходники открыли и сменили лицензию
https://arstechnica.com/information-technology/2023/01/pioneering-apple-lisa-goes-open-source-thanks-to-computer-history-museum/
Из статьи совершенно непонятно почему указатель Rc не реализует трейт Send
Довелось раз послушать этого Константина, его безграмотность и упертость впечатлила, нашли тоже кого советовать
Если вы не знаете что тестировать значит либо не поняли задачу, либо вам её плохо поставили, стоит остановиться и подумать над задачей лучше, если задача звучала как сделай как-нибудь, то и делай как нибудь, получишь соответственно, TDD занимается вопросами как надо писать код, как не надо изучает психиатрия
Любители потыкать в кнопку?
На Ваш взгляд это как должно выглядеть? Мы обновили .net, везде в коде срочно меняем все вхождения count на any или что?
В том что это не нормально если у вас в зависимости от версии .net какая-то операция х-н пойми сколько может занять времени
А если я делаю одну задачу в полгода?) Например сейчас виенна выпрямитель на stm32g4, покажите кто делает такие 10 штук в день?
А мне имея за плечами больше 10 систем автоматики и учпу типа резки кристаллов, литографии и электроэрозионной обработки, как-то на собеседовании дедок заявил что это всё мелочи вот у нас датчики пожарной сигнализации, неужели не интересно заняться серьезным проектом...
Я там просто промолчал и больше трубку от них не брал, не то чтобы мало предлагали, он вообще так и не понял чем я занимаюсь и что их сигнализация для меня проект на коленках, где ничего нового не будет
Сами себе проблем нашли и сами с ними борятся...
В C++ , empty() работает за O(1), всегда, на всех коллекциях
В Rust is_empty(), на атомарных операциях, работает всегда за O(1) на всех коллекциях
Берешь любого C/C++ выше среднего и через пару месяцев он Rust разработчик, причем настолько, что смотреть на код на С++ будет с недоумением, я проверял на практике
Осциллограф, логический анализатор и два лабораторных БП, больше ничего лично мне не требуется, ну ИК стол ещё как-то подарили, макеты домой привозят, как-то делал автоматику для ванн, эти клоуны мне всю ванну в сборе привезли... Зато ускорило разработку, каждый день жена пилила когда уже бандуру заберут
А кто не жалуется должны посмотреть на fpc, там за 14 секунд весь lazarus собирается, а не одна библиотека
Уже как-то формулировал свой взгляд...
Совет из TDD: Начинайте писать тест ДО того как создали метод, убеждаемся что тест не проходит и только потом создаём метод который проходит тест, рефакторим, убеждаемся что проходит, думаем а какой функционал ещё нужен? добавляем новый тест, убеждаемся что он не проходит, меняем или добавляем новый метод, чтобы он его проходил, рефакторим и смотрим чтобы уже два теста проходили, и так накручиваем
Такой способ даёт 100% покрытие и 100% предсказуемость, а так же крепкий сон, исключает драмы в стиле почему когда я парсил json у меня дропнулась таблица в бд
если ты не знаешь чего тестировать - скорее всего либо тебе не ясна задача, либо тебе дали задание в стиле "сделай как нибудь" , значит и делай как нибудь, но я так не делаю, потому что потом всё будешь переписывать, руководствуюсь другим принципом - стараюсь делать хорошо, хренова всегда получится, когда ты пишешь тест ты четко понимаешь что ты хочешь на выходе при таком входе, а значит и проще объяснить железяке, поэтому относиться ко времени на тесты нужно как на проектирование, а не само программирование
Но упарываться в юнит-тесты тоже не нужно, если как минимум три исключения:
1) не нужно тестировать приватные методы, не нужно ничего открывать во вне, только интерфейс, который задуман, покрытие обеспечивается косвенными методами
2) не нужно пихать в тесты бизнес логику, её нужно тестировать, а не сувать в тест, иначе тест станет хрупким и бесполезным
3) не нужно загрязнять тестами release код, продукт ничего не должен знать о тестах, иметь какие-то скрытые параметры и методы только для прохождения теста
Я даже маленько опешил от такого наезда...
1) что такое классическое ООП? Автор концепции ООП сказал что C++/Java это вообще не то что он имел в виду и пошёл пилить Smalltalk
2) дедлоки это архитектурная проблема, а не проблема языка, и на чистых функциях хаскеля вы можете добиться дедлока, что показано и через машину Тьюринга и через исчисление Чёрча
3) Еесли мы говорим про обычный компьютер, то 1000 потоков это антипаттерн, у вас на переключение задач в ОС уйдет больше времени, чем на саму задачу, плюс под каждый поток по 2 метра отрезать? Не жирно, есть корутины, есть лёгкие потоки...
Вообще хочется конкретного кода, в чём там у вас проблема