Разочарование

[Вад]

For read only, ошибки: как минимум - то, что указал Джон, включая указанное, надо полагать, при правке листинга: память будет течь безбожно (это будет труднозаметно в случае "карманного тестирования", но ошибку представляет собой очень серьёзную).

[Джон]

Джон, я тестила, всё работает и даже на крайних случаях)
подгонкой результата под ответ я никогда не занималась.
а что не так с Print_list() ?  Она по-идее распечатывает список с хвоста к голове, соответственно цикл отработает столько раз, сколько элементов в списке

Ну давай начнём вот с этого:

По-моему всё наглядно) имена говорящие

Значит имена говорящие...

Итак до сих пор "tail" был хвостом или в данном случае указателем КОНЦА списка, указатель на след. элемент которого (NEXT) всегда равен нулю. А что получается у тебя? (домашнее задание - нарисовать список из 5ти элементов каждый с полями PREV NEXT DATA и стрелочками установить связи; первый элемент назвать ГОЛОВА, последний - ХВОСТ; полученную схему тщательно проанализировать).

Таким же образом проанализировать ф-ю, которая должна добавлять новый элемент списка в ГОЛОВУ. В твоём случае происходит добавление элемента в хвост, хотя все "имена говорящие" утверждают обратное. Ну и про Print_list - ты говоришь, что он распечатывает список от хвоста к голове (от такого порядка слегка подташнивает, но это принципиально не запрещено), а я вижу что начиная с хвостового элемента делается попытка получить СЛЕДУЮЩИЙ элемент -> r=r->next; ,  который у ХВОСТА всегда нуль.

Вот таким образом "имена говорящие" и приводят к тому, что твой код понимаешь (я надеюсь) только ты, и поскольку он всё-таки работает, я и сказал, что результат был подогнан под ответ. Те я бы сказал, что логику ты примерно поняла, но при реализации ей абсолютно не следовала. Получилось - и ура. Победителей не судят.
Но вот только чем это чревато в дальнейшем? А если бы у тебя были гораздо более сложные ф-ции? А наследуемые объекты с шаблонами? А если бы ты работала "интимно" (in team)?

Ну собственно как я уже и сказал, что остальное даже не смотрел - пропало желание. За освобождением памяти абсолютно не следишь. Создаёшь ненужные объекты, где достаточно объявить переменную типа указателя... Действительно - "Разочарование".

Может всё-таки от простого к сложному? А мы поможем.

[For read only]

Я ПОНЯЛА!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Я поняла к чему эти всё делить на 2 класса, делать отдельные функции типа GetData, SetData!!!!

[Люсь]

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

[Dimka]

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

[Люсь]

Dimka, не, переводом нет )
Предварительная подготовка моя - это лёгкое понимание структурного программирования и затруднённое - в использовании классов и объектов. Постоянной практики в программировании нет, так что успешно забыла и то, что удалось понять в ООП год назад при сдаче экзамена...
https://forum.shelek.ru/index.php/topic,14070.0.html
https://forum.shelek.ru/index.php/topic,17824.0.html

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

Так что мне интересен путь от простого к сложному ) Где что конкретно можно почитать по твоей программе.

[Dmitry]

Код: (C++)

     bool getNextData(string &data)
    {
     if(this->current == NULL)
      {
       return false;
      }
     else
      {
       data = this->current->getData();
       this->current = this->current->getNextItem();
       return this->current != NULL;
      }
    }
 

В самом конце только просто

Код:

return true;

[Sla]

Зачем?

[Dmitry]

По возвращаемому значению смотрим, существует ли следующий непросмотренный элемент списка (тот, на который указывает current). Если ф-я вернула истину - считываем data. Сurrent после этого уже хранит адрес  следующего эл-та, или NULL. Вроде идея такая, и чисто логически именно так напрашивается. А тут получается,  если элемент есть -  передаём его через параметр data, а функция возвращает инфу о наличии следующего эл-та, а не того, что записала. С первым элементом head некрасиво будет.

[Sla]

с любым кодом можно извращаться

Код:

bool getNextData(string &data)
    {
     if(this->current == NULL)
      {
       return false;
      }
       data = this->current->getData();
       this->current = this->current->getNextItem();
       return this->current != NULL;
}

Так на else { } короче, но при этом теряется читабельность.

 

[Dimka]

Никакого return true - будет баг.

[Dmitry]

Я вобще не понимаю, как можно делать ф-ю с названием GetData, которая бы возвращала статус след. элемента.

И я не понимаю.
Обратите внимание на

Код:

this->current = this->current->getNextItem();
return this->current != NULL;

current в последней строчке на что указывает?

[Dimka]

current в последней строчке на что указывает?

На то, что ему присвоено в предыдущей строчке.

[Dmitry]

На то, что ему присвоено в предыдущей строчке.

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

Теперь смотрим код:

Код:

list.beginIteration();
string myString = "";
while(list.getNextData(myString))
 {
  cout << myString << endl;
 }

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

[Dimka]

Dmitry, нет, не будет.

[Dimka]

Джон, если по-хорошему, то нужно иметь 3 вещи:
1) Функцию GetCurrentData (которую можно вызывать несколько раз в рамках одной итерации).
2) Процедуру MoveNext.
3) Функцию IsEndOfSequence.

Нередко пункты 2-3 объединяют в одно целое (например, в .NET так реализовано). Тогда для правильного обхода нужны некоторые оговорки для крайних случаев (типа элемента, следующего за последним или предыдущего первому).

Ну а тут вообще все 3 этих вещи объединены в одну функцию.

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

[Dmitry]

Я не так понял Джона. Показалось, что речь о неправильности возврашения функцией статуса имнное следующего элемента, о чём я и пытаюсь достучаться.. С названием менее критично

2Dimka, так ты согласился, что там "return true" должно быть?

[Sla]

Dmitry, зачем? а тем более в свете описанного словами в необходимости этой функции.
если возвращать true, то будет ж...о...

[Джон]

Джон, если по-хорошему, то нужно иметь 3 вещи:
1) Функцию GetCurrentData (которую можно вызывать несколько раз в рамках одной итерации).
2) Процедуру MoveNext.
3) Функцию IsEndOfSequence.

    

Я не знаю может это от серости, но шеф у нас в последнее время совсем озверел. Поначитался всяких умных книжек (ему-то хорошо, времени дофига, чёб не читать). Код запретил коментировать. Точнее не то, чтобы запретил, а сказал - коменты в коде только для refactoring и что если он в релизе увидит коменты он их поудаляет. Код должен быть читаем и понятен без коментов. Вдобавок очень больно бъёт по рукам, если одна ф-я выполняет действия двух и более ф-ций. Ф-я должна выполнять только то, для чего она предназначена.

[Джон]

Зачем? Для краткости. Целью являлось не написание программы, а иллюстрация подхода с выделением курсора/итератора как отдельной сущности.

Это я только теперь понял. Сначала я увидел название темы и сразу этот топик, вот и решил, что Dmitry нашёл где-то код и хочет над ним поприкалываться. А тут оказывается...
Короче сорри. Не со зла я это.

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

[Dimka]

2Dimka, так ты согласился, что там "return true" должно быть?

Там ни в коем разе не должно быть return true.

[Dmitry]

Код:

bool getNextData(string &data)
    {
     if(this->current == NULL)
      {
       return false;
      }
     else
      {
       data = this->current->getData();
       this->current = this->current->getNextItem();
       return true;
      }
    }

Код:

list.beginIteration();
string myString = "";
while(list.getNextData(myString))
 {
  cout << myString << endl;
 }

Где ошибка?
В твоей реализации я же показал нехороший момент, и ты согласился.

[Dimka]

Dmitry, здесь нет никакой ошибки. Просто второй кусок кода нужно дополнить, если так хочется. Мне не хотелось.

[Dmitry]

Dimka, ты не издеваешься надо мной? Джон уже хотел "поприкалываться"
Рабочий же код. Что тут дополнять?

[Dimka]

Dmitry, кто и где тебе сказал, что это рабочий код? Где ты тут увидел программу? Где ты увидел законченное решение?

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

Тут нет ни постановки задачи, ни спецификаций, и нигде нет моих слов вида: "Вставь вот этот код в свою программу, и будет тебе счастье."

Ты чего сказать хочешь? Что кусок кода не будет работать с пустым списком? Не будет - никто и не обещал, что будет. Это тебя беспокоит? Меня - нет.

[Dmitry]

Всё-таки сложные люди, эти программисты. Наверное, я не имел в виду, что эти огрызки - готовая программа, компилируй и запускай...  В моём сообщении перед этим функция с изменённой одной строчкой, которая теперь адекватно работает, и пример, как её использовать, твой же. Я просто подметил ошибку в коде, сделал это для новичков, для которых и создан этот раздел, чтобы,  если вдруг станут использовать написанное тобой, не путались. Было с багом - стало без. Что плохого?
И к чему было всё это:

Никакого return true - будет баг.

Там ни в коем разе не должно быть return true.

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

[Dimka]

В моём сообщении перед этим функция с изменённой одной строчкой, которая теперь адекватно работает

Я не заметил, куда ты вставил return true - сейчас увидел. Из ранее сказанного я понял, что ты его собрался вставить в конец функции вместо остальных return (тогда был бы баг), а не в конец ветки else.

Твой вариант будет работать.

Я просто подметил ошибку в коде, сделал это для новичков, для которых и создан этот раздел, чтобы,  если вдруг станут использовать написанное тобой, не путались. Было с багом - стало без. Что плохого?
И к чему было всё это

Плохо и возмутительно следующее.

По возвращаемому значению смотрим, существует ли следующий непросмотренный элемент списка (тот, на который указывает current). Если ф-я вернула истину - считываем data. Сurrent после этого уже хранит адрес  следующего эл-та, или NULL. Вроде идея такая, и чисто логически именно так напрашивается. А тут получается,  если элемент есть -  передаём его через параметр data, а функция возвращает инфу о наличии следующего эл-та, а не того, что записала. С первым элементом head некрасиво будет.

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

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

Нужно говорить подробно и в следующем порядке:
1) Итератор работат по такому-то принциу и обладает такими-то недостатками. Чтобы устранить недостатки, я предлагаю изменить принцип работы итератора.
2) Новый принцип работы заключается в ...
3) Внедрение нового принципа работы требует:
- таких-то изменений в интерфейсе;
- таких-то условий использования;
- таких-то изменений в коде реализации.

Без смены семантики для исходного куска кода нужно было добавить вывод последнего элемента:

либо

Код:

list.beginIteration();
string myString = "";
while(list.getNextData(myString))
 {
  cout << myString << endl;
 }
cout << myString << endl;

либо

Код:

list.beginIteration();
string myString = "";
bool needContinue = false;
do
 {
  needContinue = list.getNextData(myString);
  cout << myString << endl;
 }
while(needContinue);

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

Твой вариант лучше, но способ его предложения к обсуждению неудачен.

[Dmitry]

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

Про изменение интерфейса, конечно, согласен. В данном случае реализация (и семантика) была подстроена под интерфейс, ожидаемый клиентским кодом, который ты привёл. Потому, что так существенно лучше (на мой взгляд), мне и показалось, что именно в методе  просто вкралась "описка".

По поводу названия/поведения функции. Если обходить список одной функцией, то как ни крути, клиент всё равно будет просить  - "хочу следующий элемент"   

[Алексей++]

но шеф у нас в последнее время совсем озверел. Поначитался всяких умных книжек (ему-то хорошо, времени дофига, чёб не читать). Код запретил коментировать.

Джон, можно настроить коменты цветом текста как фон:) Или загонять табом далеко вправо. Может и не прокатить, правда

[Dimka]

В данном случае реализация (и семантика) была подстроена под интерфейс, ожидаемый клиентским кодом, который ты привёл.

"Клиентский код" может ожидать только одного - того, что прописано в интерфейсе. Первичен интерфейс, он же контракт.