Здравствуйте, Shmj, Вы писали:
S>Были времена, когда ООП стало модным и начали пихать во все щели, причем не по делу. Потом маятник качнулся в обратную сторону и начали убеждать что оно нафиг не нужно. Сейчас все более-менее устаканилось и стало ясно что ООП. весьма удобный и полезный инструмент, лишать себя которого нет смысла — т.е. язык без ООП даже рассматривать не стоит.
Если язык без ООП даже рассматривать не стоит, значит, снова пихать его во все щели?
Интересно, как мне удалось обходиться без ООП, когда я JNI делал?
Здравствуйте, Shmj, Вы писали:
S>Во все щели пихать что угодно — это плохая практика, хотя и популярная. Пихать шаблоны во всех щели или лямбды — так же плохо, как и пихать ООП.
Здравствуйте, Privalov, Вы писали:
P>В предыдущем сообщении было: P>
P>язык без ООП даже рассматривать не стоит
P>Это разве не означает "пихать во все щели"?
Нет. Если в языке есть ООП но ваша текущая задача его не требует — то не используйте. Вторая задача потребует ООП и вы будете писать на привычном вам языке.
S>Нет. Если в языке есть ООП но ваша текущая задача его не требует — то не используйте. Вторая задача потребует ООП и вы будете писать на привычном вам языке.
А если в языке нет ООП и текущая задача его не требует, рассматривать?
Здравствуйте, Privalov, Вы писали:
S>>Нет. Если в языке есть ООП но ваша текущая задача его не требует — то не используйте. Вторая задача потребует ООП и вы будете писать на привычном вам языке.
P>А если в языке нет ООП и текущая задача его не требует, рассматривать?
Здравствуйте, пффф, Вы писали:
П>Батхерт от собственных реализаций "тех же векторов/списков" происходит от того, что ничего нового, кроме кучи багов, эти реализации не добавляют обычно.
До сих пор контейнеры STL не имеют метода contains().
Здравствуйте, FR, Вы писали:
ЕМ>>В первую очередь — возможность указать компилятору "тут я замыслил делать вот так, и бей меня по рукам, если я где-то попробую сделать иначе".
FR>С такими мыслями надо сразу на раст переходить
В Rust, насколько я знаю, эта концепция используется весьма последовательно. А в C++ до сих пор борются (и еще долго будут бороться) два подхода: "этого нужно избегать любой ценой" и "если кажется, что программист решил отстрелить себе яйца, то недопустимо мешать ему сделать это с комфортом и без напряга".
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, so5team, Вы писали:
S>>Очередная демонстрация незнания предмета. Без хорошего знания особенностей C++ сделать свой аналог std::vector будет не просто.
S>А свой аналог List на C# — легко сделать? Для частного случае, для себя, чтобы иметь ограниченное количество вариантов использования — не проблема. А вот чтобы это работало для других людей и миллионы людей с сотнями тысяч вариантов использования остались довольны — уже задача не такая уж простая
На C# несравнимо легче, на порядки легче. Хотя я с товарищем so5team предпочитаю не пересекаться, но вот здесь с ним соглашусь.
А так получается, что ты не читал ни талмуд Страуструпа (пример с simple vector), ни книгу Александреску и Саттера "Стандарты программирования" (про уровни безопасности). А исключения — это такая сложная штука. И мне, кстати, интересно, как в Аде с этим борются. Там исключения появились раньше, и преподносились они как супер-фича.
Вообще, так как я — неисправимый фанат ФП, то мне, конечно, нравится Rust. И один из моментов, почему нравится, это то, что из исключений там есть только паника. Сложность представляет собой код unsafe, где по-хорошему нужно думать о том, как будет вести себя блок unsafe во время паники, о чем многие забывают... В коде safe вроде как все должно отработать четко — так и задумывалось. А так, это такое облегчение, что в Rust почти нет исключений. Сразу гора с плеч. Но Rust все равно далек от идеала. У него и своих проблем хватает, которые я затронул выше. Увы, идеала никакого нет. Н-да, и не будет!
Здравствуйте, dsorokin, Вы писали:
D>На C# несравнимо легче, на порядки легче. Хотя я с товарищем so5team предпочитаю не пересекаться, но вот здесь с ним соглашусь.
Так а вы смотрели исходники стандартного List<T> в C#? Не так то все и просто
D>А так получается, что ты не читал ни талмуд Страуструпа (пример с simple vector), ни книгу Александреску и Саттера "Стандарты программирования" (про уровни безопасности). А исключения — это такая сложная штука. И мне, кстати, интересно, как в Аде с этим борются. Там исключения появились раньше, и преподносились они как супер-фича.
И так ясно что реализация vector из стандартной библиотеки — для большинства людей не посильна. Вот, для примера, что выдал GPT в качестве примера по моим наводкам:
Здравствуйте, Shmj, Вы писали:
S>Сможете ли вы сходу найти ошибки?
Сходу, не вчитываясь, у вас конструктор копирования+операторы копирования и методы resize/pushBack не exception safe, в resize запросто произойдет переполнение _capacity, а еще ваш SimpleVector не будет работать с T у которого нет дефолтного конструктора.
Здравствуйте, Артём, Вы писали:
Аё>Если не могут написать с нуля на расте, тогда зачем мучают 5 точку? Вон в MS когда-то хотели всю OS на пончике запилить, но что-то пошло не так. На жаве попытки были "чистой безопасной OS".
в каждой sim карте сотового оператора и в каждой банковской карте с чипом (контактной или nfc) внутри работает jvm со своей безопасной ос.
это, примерно, от 30 до 50 миллиардов устройств в промышленной эксплуатации.
Здравствуйте, sergii.p, Вы писали:
SP>что новые фичи (типа умных указателей) языку безопасности не прибавляют, так как всё равно остаются способы отстрелить себе ногу.
Еще из очевидного: ваш resize не обрабатывает ситуацию, когда вектор оказался пустым в результате перемещения. У вас _capacity будет 0, вы ноль умножите на два и получите ноль. Вот пример такого сценария:
Здравствуйте, so5team, Вы писали:
S>Еще из очевидного: ваш resize не обрабатывает ситуацию, когда вектор оказался пустым в результате перемещения. У вас _capacity будет 0, вы ноль умножите на два и получите ноль. Вот пример такого сценария: S>
Здравствуйте, Shmj, Вы писали:
S>>Еще из очевидного: ваш resize не обрабатывает ситуацию, когда вектор оказался пустым в результате перемещения. У вас _capacity будет 0, вы ноль умножите на два и получите ноль. Вот пример такого сценария: S>>
Здравствуйте, пффф, Вы писали:
П>Наверное, всё можно было бы сделать в несколько раз проще. И скорее всего, ООП там тоже был, только свой, костыльный, как у vsb
Основной проект был на Java. В принципе, ООП, только наследования реализации было слишком до хрена и часто не по делу.
Коллега делал какую-то утилиту или дополнение, уже не помню. И что-то ему понадобилось от Винды. А Java сама не могла. Коллега спросил меня, я был немного в курсе, ну и сделал JNI. Десятки строк на голых Сях, ничего особенного. Лепить классы, заворачивать их в функции было бы слишком.
В принципе я на Сях ничего такого больше нескольких сотен строк не делал. И, как правило, это были дополнения к чему-то. К Фортрану или Жаве. Плюс пара-тройка небольших утилит.
Здравствуйте, so5team, Вы писали:
S>Тупизма и непонимания с вашей стороны. Что и получилось. S>ЗЫ. Уж точно не тихой порчи хипа здесь нужно ожидать.
Ну перейти на личности легче всего. А конкретно — после std::move(first) вы опять пытаетесь использовать first. В Rust вам бы на уровне компиляции выдало ошибку, в C++ ошибку на уровне компиляции не выдаст, но все знают что так делать нельзя.