orly?

вот ведь обидно

а почему так? чем это обусловлено?

На момент компиляции компилятор ничего не знает о параметризации темплейта

А вот в конкретном месте, где будет определён Шаблонный параметр - компилятор сможет подставить параметр и скомпилять класс.

хорошо, я не могу даже нормально объявить конструктор. чего он хочет? неважно даже, в одном файле или нет

или прям в классе реализовывать?

Нет, можно не в классе

Какая сигнатура конструктора в реализации вне класса? Скорее всего с этим проблема

вот класс

Вот код класса: template <typename T> class Matrix { private: int rows, cols; T *data; public: Matrix(int _rows, int _cols); ~Matrix(); };

сигнатура такая же, точь-в-точь, копипаста

объявляю Matrix::Matrix(int _rows, int _cols){}

А темлейт куда делся?)

ошибка: In file included from test.cpp:2:0: ./matrixlib.h:15:1: ошибка: некорректное использование имени шаблона «Matrix» без списка аргументов Matrix::Matrix(int _rows, int _cols){} ^~~~~~

Ну, явно же ругается

вот с темплейтом

я лично не вижу проблем

Заюзай реализацию прямо в классе, сейчас нет возможности проверить

а ларчик просто открывался

Таки как он открылся? )

Во второй секции, кстати, надо было кроме теоретических вопросов написать shared_ptr

а что в этом сложного? В простейшем варианте - структура в памяти с двумя счётчиками и указателем на данные. По обнулению первого счётчика данные удаляются, по обнулению обоих - удаляется структура.

Таки как он открылся? )

наверняка как-нибудь так: template <typename T> class Matrix { private: int rows, cols; T *data; public: Matrix(int _rows, int _cols): rows ( _rows ) , cols ( _cols ) { data = new T[rows * cols ]; } ~Matrix() { delete[] data; } };

Таки как он открылся? )

template <class T> Matrix<T>::Matrix(int _rows, int _cols): rows(_rows), cols(_cols){ data = new T[rows*cols]; }

Забыл <T> после Matrix

Новый вопрос: есть ли способ разрушить объект на момент создания? То есть, в рантайме вызывается конструктор, который проверяет корректность входных данных, и если встречается ошибка, нужно порушить объект. Из ит риал?

Или только аварийная остановка программы?

Или это вообще bad style?

throw

Новый вопрос: есть ли способ разрушить объект на момент создания? То есть, в рантайме вызывается конструктор, который проверяет корректность входных данных, и если встречается ошибка, нужно порушить объект. Из ит риал?

Ну если объект разрушится то ты его не сможешь дальше использовать, что логично А это приведет к сегфолту

Ну если объект разрушится то ты его не сможешь дальше использовать, что логично А это приведет к сегфолту

Да хорошо бы, только надо не засрать память

Кстати, почему парятся людие о засранной памяти, delete, итд, если система отлавливает эти ситуации и при завершении программы попросту помещает страницы в список свободных?

Кстати, почему парятся людие о засранной памяти, delete, итд, если система отлавливает эти ситуации и при завершении программы попросту помещает страницы в список свободных?

А если у тебя сервак который работает по несколько месяцев

Кстати, почему парятся людие о засранной памяти, delete, итд, если система отлавливает эти ситуации и при завершении программы попросту помещает страницы в список свободных?

😆

Кстати, почему парятся людие о засранной памяти, delete, итд, если система отлавливает эти ситуации и при завершении программы попросту помещает страницы в список свободных?

То, что тебе этот кусок памяти будет недоступен

Блядь. Это супапро

А если у тебя сервак который работает по несколько месяцев

Ось, тем паче серверная, должна быть к этому готова. Если прога постоянно что-то создаёт и забывает стирать, засирая всю память, включается статистический сборщик мусора, не?

Блядь. Это супапро

Я всё понимаю, но я задаю вопрос более широкий, чем "зачем new delete". Это уже из области моего любимого osdev;)

Ось, тем паче серверная, должна быть к этому готова. Если прога постоянно что-то создаёт и забывает стирать, засирая всю память, включается статистический сборщик мусора, не?

А как она узнает, что твой быдлокод не будет использовать этот кусок памяти? Никак

А как она узнает, что твой быдлокод не будет использовать этот кусок памяти? Никак

Так ведь статистика обращений к страницам. Как узнаёт сборщик джавы? Отсутствие ссылок на объект, например.

А как она узнает, что твой быдлокод не будет использовать этот кусок памяти? Никак

В любом случае прога покрэшится: либо ОСь откажет в выдаче памяти в куче, либо попросту обратится в вычищенный кусок. Если полагать, что прог много и все хотят памяти, лучше обеспечить работоспособность всех, ценой убийства одной. Об остальном пусть парится разраб.

Следовательно, выгоднее статистически затирать страницы.

Я просто попутно проектирую mm своей микро-ОСи и задумался об эдаких механизмах

В любом случае прога покрэшится: либо ОСь откажет в выдаче памяти в куче, либо попросту обратится в вычищенный кусок. Если полагать, что прог много и все хотят памяти, лучше обеспечить работоспособность всех, ценой убийства одной. Об остальном пусть парится разраб.

Вот ты как осдев знаешь, что сишная программа умеет только маллок и фри, а ос ей просто мапит кусок памяти в виртуальное адресное пространство. Если у тебя внезапно выделенный кусок памяти через маллок станет невалидным без вызова фри, то это значит, что у тебя произошло то, что нарушает семантику этих функций

Так ведь статистика обращений к страницам. Как узнаёт сборщик джавы? Отсутствие ссылок на объект, например.

И как это соотносится с си и плюсами? Может ты в память константную строку загнал, и что случится если её удалить?

Ты можешь сделать свое апи в твоей микрооси, которое включит этот сборщик мусора, но при разработке софта надо будет учитывать этот факт

И как это соотносится с си и плюсами? Может ты в память константную строку загнал, и что случится если её удалить?

Тогда к этой строке будут обращаться.

Кстати, почему парятся людие о засранной памяти, delete, итд, если система отлавливает эти ситуации и при завершении программы попросту помещает страницы в список свободных?

не хочешь париться о засранной памяти - не используй си и плюсы, используй яву, питон или шарп, где есть сборщик. А есть ещё эмбедед направление, там не только о засранной памяти парятся, там даже о выделении памяти в процессе работы парятся, ибо в идеале и этого не должно быть.

Тогда к этой строке будут обращаться.

раз в день, когда приходит отчёт от железки, например?

Да, есть резон

В твоих речах

Вот ты как осдев знаешь, что сишная программа умеет только маллок и фри, а ос ей просто мапит кусок памяти в виртуальное адресное пространство. Если у тебя внезапно выделенный кусок памяти через маллок станет невалидным без вызова фри, то это значит, что у тебя произошло то, что нарушает семантику этих функций

И произойти это может только по вине ос. Сама прога (в идеальном случае) не портит свою память, другие процессы защищены (i386+).

раз в день, когда приходит отчёт от железки, например?

Вотпример. По статистике эта строчка будет вызываться редко, и ее в утиль отправит ос

https://youtu.be/JfmTagWcqoE

не хочешь париться о засранной памяти - не используй си и плюсы, используй яву, питон или шарп, где есть сборщик. А есть ещё эмбедед направление, там не только о засранной памяти парятся, там даже о выделении памяти в процессе работы парятся, ибо в идеале и этого не должно быть.

Тут Саттер рассказывает про "сборщик" на плюсах

Тут Саттер рассказывает про "сборщик" на плюсах

там же всё на умных указателях, посчёте ссылок и без сборщика мусора как такового, вроде. Если я выступление не путаю.

Ну да, но смысл то тот же - удаление объектов когда они уже не используются

А ты хочешь, чтобы тебе рантайм ссылки считал, а не на уровне языка?

Только сборщик возвращает память как я понимаю, а тут деструкторы вызываются

смысл любого gc тот же

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

более точно управление временем жизни, меньше вопросов по освобождению памяти и всё такое.

это как бы не сборщик в том понимании, какое есть в яве или шарпе, это именно управление временем жизни объекта.

но не такое управление жизнью объекта, как в расте!

не знаком с растом, не могу сравнить :)

https://doc.rust-lang.org/beta/book/lifetimes.html

(может показаться, что пунктуации в языке немного больше, чем нужно, да, это так)

https://doc.rust-lang.org/beta/book/lifetimes.html

или я не понял синтаксиса, или там речь идёт только о статике, которая и может быть вычислена на этапе компиляции (так в плюсах можно то же самое), а не о динамике

Нет. Раст просто умеет на этапе компиляции понимать больше, чем c++. То, что в С++ упадет в рантайме (давайте передадим овнершип unique_ptr куда-нибудь и потом вызовем еще раз), в расте не скомпилируется

Нет. Раст просто умеет на этапе компиляции понимать больше, чем c++. То, что в С++ упадет в рантайме (давайте передадим овнершип unique_ptr куда-нибудь и потом вызовем еще раз), в расте не скомпилируется

auto pint1 = std::make_unique< int > (); auto pint2 = std::move( pint1 ); if ( pint1 ) *pint1 = 10; if ( pint2 ) *pint2 = 42; да, рантайм, но накладных расходов не больше чем с сырыми указателями, и да, если правильно писать не упадёт.

через лет 5 раст будет норм

Если правильно писать, то и с сырыми не упадет, вопрос в количестве способов выстрелить в ногу

Если правильно писать, то и с сырыми не упадет, вопрос в количестве способов выстрелить в ногу

в расте это невозможно в принципе?

Выстрелить в ногу? Возможно конечно

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

Раст пока что для энтузиастов

Информацию фильтровать же надо, ну. Если учить все то можно слегка поехать

Питон учить практичнее

Да и проще