освобождение памяти

Как думаешь почему?

Потому что думают так, а кто написал c++, этот, а ну этого только будем знать, другие лучше не напишут. Так у страуструпа наверное справочник.

Это как? Можно примеры? Мне кажется, что ты просто не разобрался с ними.

Нет, код не для тебя. Но я там без динамической памяти использовал, типа контейнера стека.

Во-первых, переписывать что-то написанное на с++ на си - это верх идиотизма. Серьезно.

С чего ты взял?

Может меня (как и других) стоит слушать потому что я у меня многолетний опыт работы программистом?

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

Окей, вопрос такой, что такое ядро системы? А конкретно линукс, что в него входит? Проверим твои знания=)

Щас попробую. Ядро это программа, которая работает с аппаратурой.

А конкретно линукс, что в него входит?

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

Так у страуструпа наверное справочник.

У него учебник, по которому можно язык изучить очень хорошо.

Потому что думают так, а кто написал c++, этот, а ну этого только будем знать, другие лучше не напишут.

Если б книга б была хорошей, о ней все бы слышали.

Нет, код не для тебя. Но я там без динамической памяти использовал, типа контейнера стека.

Ты приведи пример который воспроизводит проблему. Мол создал контейнер, туда что-то запихнул - не работает. Ты не хочешь раскрывать код - ладно. Но представить пример проблемы с контейнером - это не означает раскрытие твоей задумки, твоей архитектуры или твоих алгоритмов. Это просто проблема с контейнером. Если ты даже не умеешь вопросы задавать... мне тебя жалко...

С чего ты взял?

Потому что это задача, которая по сути не несет никакого смысла. Никаких профитов, а только потраченное время.

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

Я тебе посоветовал:

1) да, книгу, ибо твой код УЖАСЕН. И то что ты говоришь ужасно до ужаса, на лицо полное непонимание основ. Я не могу тебе рассказать основы. Если я укажу на ошибку в коде, то ты ничего не поймешь. У тебя фундаментальные проблемы. И именно на это я указываю. Именно ЭТО я советую улучшить

2) Я советую не заниматься фигней вроде переписывания с с++ на си. Если обратное (си -> c++) еще имеет какой-то смысл (и то тоже не всегда), то уж это точно лишено смысла. Хотя нет, есть одна причина, когда это может быть надо. Например разработка под аппаратную платформу где нет компилятора плюсов. Но это явно не твой случай=)

3) Я советую использовать в продукте готовые контейнеры. Ибо они будут на 99.9% лучше твоих костылей.

4) Я спросил с тебя пример проблемы с stl, чтобы указать на твои ошибки и посоветовать тебе как правильно их использовать. Но ты уперся.

Чувак, одумайся. Иначе будешь заниматься html версткой (даже не пхп) в будущем.

Это все ядро, подучи матчасть. Модули - часть ядра. Серьезно. И драйверы - его часть.

Страуструп - создатель с++

Манипуляция, а вернее полное враньё. Никакой струструп С++ не создавал - он сваял кое как рабочие си с классами. И то, это был не язык.

Это типичная проблема для болтунов - отсутствие хоть какого-то желания отличать жопу от пальца. И наверное создателем майбаха является какой-нибудь пионер из 18века?

Всё что страуструп «родил» - является убогим дерьмом даже сейчас, спустя тысячу лет - те же стримы.

у него очень граматная книга описывающая концепцию языка

Никакие концепции там не описаны. Там 80% книги это мануалы «как написать очередной хевлорд», стримы и прочая херня. Никаких концепций там и близко нет.

его подводные камни и способы првильно использовать язык.

Таким там даже и не пахнет. А подводные камни это наверное что-то уровня «не забудь поставить бряк после тела кейса» и прочая ахинея.

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

Это все ядро, подучи матчасть. Модули - часть ядра. Серьезно. И драйверы - его часть.

Зачем ты это пишешь? Я же тебе уже написал что входит в ядро, зачем повторять? Ты хочешь быть услышанным чтоли?

Почему тебе нравиться все готовое? Зачем использовать какую то либу с контейнерами для си, о которой я не слышал, которую ты мне упоминаешь, если я за несколько секунд могу написать такую структуру, да и как вообще на си контейнеры использовать без шаблонов, для своей структуры свое придется писать. Да и шаблоны, ты знал что раньше шаблоны писались как макросы, да они и щас макросы, только синтаксис немного изменился. Вот, я напишу например структуру

struct f 
{
  ...
  struct f *next;

У него учебник, по которому можно язык изучить очень хорошо.

Ну в рамках представлений дошколят о языке - да.

Ибо они будут на 99.9% лучше твоих костылей.

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

Ну ты же только из-за ядра можешь назвать линукс линуксом

WHAT? Мой парсер упал с сегфолтом, предварительно сожрав стек.

ядро и есть линукс

Скорее наоборот, но да, в частном случае (например, в большинстве дистрибутивов) ядро — именно linux.

Да и начни уже читать что нибудь подходящее, где я правильней излагаю

Перефразирую: прочитай что-нибудь, что соответствует моим представлениям о том, как оно работает и что правильно. Воздержусь.

В предыдущих томах нашей книги

То есть он конкретизировал, что подразумевается под данным термином в его книгах. Не больше

очему тебе нравиться все готовое? Зачем использовать какую то либу с контейнерами для си, о которой я не слышал, которую ты мне упоминаешь, если я за несколько секунд могу написать такую структуру, да и как вообще на си контейнеры использовать без шаблонов, для своей структуры свое придется писать. Да и шаблоны, ты знал что раньше шаблоны писались как макросы, да они и щас макросы, только синтаксис немного изменился. Вот, я напишу например структуру

Потому, что всё это работает только тогда, когда ты не нулёвый ламерок.

struct list *d;
struct list *pt;
for ( int h = 0; h < height; h++ )
{
  for ( int w = 0; w < width; w++ )
  {
     pt = &total_list [ h ] [ w ];
     while ( pt )
     {
        d = pt;
        pt = pt->next;
        free ( d );
     }
  }
}

Это вот эта параша альтернатива? Сходу поверил.

Ты пытаешься писать лозунги из совершенно иного мира, находясь в мире дошколят. Это глупости и потом, после подобного, на меня и льются тонны дерьма.

Я же тебе уже написал что входит в ядро, зачем повторять?

Потому что ты НЕ прав. Совсем.

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

Как все запущенно.

Ты даже не пыташься понять в чем проблема...

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

Ты напишешь фигню. Которая не умеет нормально работать с памятью, не имеет вменяемых интерфейсов.

Ну в рамках представлений дошколят о языке - да.

А у ОПа наверное уровень другой?

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

Вот тут я не понял твоей мысли. Ты согласен, что костыли писать не надо? Или таки ты считаешь, что он правильно все делает? Я из этого предложения твоей позиции по вопросу не понял.

Да это старый код. Это тоже самое, если ты посмотришь первый код линуса торвальдса, когда он линукс писал.

Щас код освобождения такой, так как сделал двумерный массив одномерным.

struct list *d;
struct list *pt;
for ( int h = 0; h < height; h++ )
{
  for ( int w = 0; w < width; w++ )
  {
     pt = &total_list [ h * ww + w ];
     pt = pt->next;
     while ( pt )
     {
        d = pt;
        pt = pt->next;
        free ( d );
     }
  }
  free ( total_list );
}

struct list *d;
struct list *pt;
int total = width * height;
for ( int i = 0; i < total; i++ )
{

  {
     pt = &total_list [ i ];
     pt = pt->next;
     while ( pt )
     {
        d = pt;
        pt = pt->next;
        free ( d );
     }
  }
  free ( total_list );
}

Потому, что всё это работает только тогда, когда ты не нулёвый ламерок.

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

Это тоже самое, если ты посмотришь первый код линуса торвальдса, когда он линукс писал.

Чувак, ты сделал мой день=)))

Ты напишешь фигню. Которая не умеет нормально работать с памятью, не имеет вменяемых интерфейсов.

Ты о c++ или о си?

А у ОПа наверное уровень другой?

Ну ты говоришь не про уровень ОПа?

Вот тут я не понял твоей мысли. Ты согласен, что костыли писать не надо?

Да, их не надо писать, если ты не можешь. Либо, если можешь и на результат насрать. Протопирование, впарить лохам дерьмо и прочее.

Или таки ты считаешь, что он правильно все делает? Я из этого предложения твоей позиции по вопросу не понял.

Дело в том, что эта мантра, которую ты использовал - используется всеми, и не только в контексте дошколят, но и вообще. Я против этого.

Вот ты выше пишешь «не можешь управлять нормально памятью», дак и С++ не может. Всё зависит от того с какого уровня смотреть.

Окей, попробую объяснить что у тебя не так.

1) Тебе нужен интерфейс на все операции с списком: операции добавления, удаления, вставки(она должна в идеале принимать данные, а не внутреннюю структур списка).

2) Добавить итераторы для обхода и обращения к внутренней кухне списка

3) Операция удаления одного элемента должна принимать на вход итератор.

4) операция удаления всех или ренджа должна работать через операцию удаления одного

5) Операция удаления ренджа должна работать через итераторы

6) никакого обращения к внутреней кухне контейнера

7) Зануление некста при вставке

8) проверка на нулл при удаление

И это что первое пришло в голову. У тебя просто портянка.

Дело в том, что эта мантра, которую ты использовал - используется всеми, и не только в контексте дошколят, но и вообще. Я против этого.

Ну я выше писал, что случае когда свои костыли и велосипеды нужны бывают. Но сказал, что опу о этом думать пока рано. Только если для обучения и понимания алгоритов, но он вроде как продукт пишет, а не лабу в универе=)

Безусловно писать что-то, что уже есть иногда надо. Иначе бы не было б столько библиотек с похожими вещами.

Щас код освобождения такой, так как сделал двумерный массив одномерным.

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

Убогие конструкции вида &total_list [ i ], абсолютно шизофреническое:

pt = &total_list [ i ];
     pt = pt->next;
//вместо
pt = (total_list + i)->next;

Мне даже смотреть на это больно - мой мозг не выдерживает.

Просто убогий write-only «стиль» на подопотопной параше. Ты там в 95 году чтоли?

Почему ты не можешь написать нормальную функцию «снести список» и вызвать её в цикле? Зачем тебе вообще список?

Ты не написал ничего лучше крестовой параши - толку с этого? Написал бы лучше - был бы смысл. Написал чисто для себя, для обучения. Был смысл, но ты не можешь тогда говорить, что другое - дерьмо. Другое такое же, даже лучше.

И о том и о другом.

операция удаления всех или ренджа должна работать через операцию удаления одного

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

И это что первое пришло в голову. У тебя просто портянка.

Так код же на си.

1) Тебе нужен интерфейс на все операции с списком: операции добавления, удаления, вставки(она должна в идеале принимать данные, а не внутреннюю структур списка).

2) Добавить итераторы для обхода и обращения к внутренней кухне списка

3) Операция удаления одного элемента должна принимать на вход итератор.

4) операция удаления всех или ренджа должна работать через операцию удаления одного

5) Операция удаления ренджа должна работать через итераторы

6) никакого обращения к внутреней кухне контейнера

7) Зануление некста при вставке

8) проверка на нулл при удаление

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

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

Безусловно писать что-то, что уже есть иногда надо. Иначе бы не было б столько библиотек с похожими вещами.

Это из-за того, что в c++ постоянно говорят по повторное использование кода, а на деле только в си используют повторное использования кода, но не говорят об этом постоянно, как в с++.

Да, отчасти «зачем тащить тонны дерьма, если я могу написать просто и быстро нужный мне функционал» правильно, но есть нюансы. Действительно ли ты пишешь нужный функционал и ограничиваешь себя объективными ограничениями, а не ограничениями как следствие твоей слабости. Очень просто ошибиться.

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

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

Тут есть ловушка интерфейса, когда интерфейс к тому же stl сложнее реализации списка, то у тебя сразу пропадает желание в нём разбираться и хочется сваять его самому. Это ошибка.

Так код же на си.

И что?

Просто ради понимания: что ты подразумеваешь под «повторным использованием кода»?

pt = (total_list + i)->next;

А ты интересно написал. Но это всегда так, смотришь со стороны и критикуешь. Ты у кого учился рефакторингу?

Да, согласен. Но это легко запиливается если есть грамотный интерфейс и все инкапсулировано под него.

И что?

Ну попробуй к структуре применить свои правила, для этого ты напишешь отдельные функции. Так как код участок кода один раз использоваться будет, то бишь освобождение памяти, то прыгать на другой адрес нет смысла. Да даже использовать inline. Конечно, выглядет интересно, когда в функции одни функции, но не всегда.

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

Ты у кого учился рефакторингу?

У себя.

Думаю это о том, что хоть ты пишешь классы, они не будут в других программах эти же классы использоваться, а будут похожие

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

У себя.

Ты странно как то реагируешь. Говоришь плохой код, только из-за того, что тебе не привычно видеть. Это тоже самое что ты любишь например больше всего тефтели кушать с соусом, но соусом не поливать, а тефтели на соус ложить, и я тебе такой говорю, что за вид такой, что ты не можешь полить соусом чтобы красивее выглядело?

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

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

Так что получается, везде используется повторный код?

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

Какая глобльная область видимости? Ты ж динамическую коллекцию делаешь. И нет, стандарт гарантирует зануление только для глобальных ПЕРЕМЕННЫХ и статических. Память выделенная через malloc занулена не будет.

И в любом случае, тут разговор об инкапсуляции. Безопасный и качественный контейнер без нее сделать не получится. У тебя должно работать правило: указатели на элементы коллекции должны или указывать на реально существующий объект или быть равными нулю. Полноценное следование этому правилу возможно только через инкапсуляцию.

Так или иначе — да. Вопрос в том, насколько много кода может быть использовано повторно и сколько реально используется. В крупных проектах, которые пилит множество разработчиков, неизбежно появляются куски кода, делающие примерно одно и то же. Поэтому периодически приходится делать рефакторинг, чтобы объединять их и убирать избыточность

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

На какой адрес, куда прыгать? В данном случае разницы между си++ и си нет. Есть разница в синтаксисе, да. Но интерфейс (как и инкапсуляция через него) вполне реализуется и на си. В данном вопросе нет принциальной разницы. Правила которые я описал - это хороший подход для любого языка, независимо от того ооп он или нет, есть там темплейты или нет.

если ты создашь указатель без выделения памяти, то он будет указывать на ноль, разве нет. Я знаю что malloc делает, но я имею ввиду, что если создал указатель, то он указывает на ноль и так, я это специально повторил еще раз, чтобы ты понел.

На какой адрес, куда прыгать?

на адрес функции.

Правила которые я описал - это хороший подход для любого языка,

Ты где учился этому? Или читал макконела?

//вместо
pt = (total_list + i)->next

Да ты же анскильный:

pt = total_list[i].next 

Да даже использовать inline.

При чем тут вообще inline?

При чем тут вообще inline?

Ну inline делает код функции как будто вызова функции нет, и код написан в том месте где происходит вызов функции, только eip не переходит на адрес функции, а дальше выполняет инструкции.

Ты где учился этому? Или читал макконела?

Учился из книжек, у других людей и конечно же из опыта.

Но ты пойми, что моим советам тоже слепо следовать не стоит, я лишь кратенько описал набор улучшений которые необходимо сделать. Тонкостей разных там еще оооочень много. Я лишь показал, что у тебя не так из совсем ОЧЕВИДНОГО, а там еще столько всего... И оптимальное выделение памяти, и копирование, и перемещение, и сравнение и еще много чего. Именно поэтому свои костыли пока имеет смысл писать только в целях самообразования. А для продуктов лучше искать готовые решения. Во всяком случае пока что.

Не надо мне рассказывать, что такое inline. Зачем ты тут вообще о нем думаешь? Или ты реально считаешь, что вызов функции прям много отожрет?

Или ты реально считаешь, что вызов функции прям много отожрет?

Я к тому что если мне нужен функционал в все волишь одного метода, то даже за очистку памяти я не стал бы использовать отдельную функцию или метод, если освободить нужно единожды.

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

Нет. Только если он глобальный.

Нет. Только если он глобальный.

Но ты мне явно привел правила, которые описывают класс, который находится в глобальной области.

Я к тому что если мне нужен функционал в все волишь одного метода, то даже за очистку памяти я не стал бы использовать отдельную функцию или метод, если освободить нужно единожды.

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

Волноваться об оверхеде с вызова функции тебе скорее всего не придется. Тем более если ты посмотришь на исходники stl, то там половина функций инлайн, ибо они как правило одна-двух строчные, которые дергают в этих двух строках другие функции которые тоже 1-2 строчные и они все инлайны. Это кстати еще одна из причин использовать stl, контейнеры в нем написаны максимально эффективно с inline и подобным. И код написан так, что компилятор скорее всего их реально зайнлайнит. Ты же в курсе, что inline не гарантирует реальный инлайнинг кода? А stl и подобные люди пишут не дураки, они специально пишут код так, чтобы он гарантировано инлайнился. Ну и тестят. Ты боишься лишнего вызова функций - плодишь говнокод и портянку. В stl есть норм интерфейс, нет портянки и нет лишних вызовов. Так почему ты упорствуешь?