Russian Qt Forum

На код ниже компилятор выдаёт ошибку:

ошибка: conversion from 'std::list<std::pair<unsigned int, int> >::const_iterator {aka std::_List_const_iterator<std::pair<unsigned int, int> >}'
to non-scalar type 'std::list<std::pair<unsigned int, int> >::iterator {aka std::_List_iterator<std::pair<unsigned int, int> >}' requested
std::list<std::pair<unsigned int, int> >::iterator iter = headIndexes.end();
                                                                                                ^
Я понимаю, что std::list::end() возвращает константный итератор, и что я не могу присваивать его обычному итератору.

Как заставить этот метод вернуть обычный итератор? Метод ведь перегруженный, и существует нужная мне версия.

mingw 4.8, QTCreator, QT 5.1.1.

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

C++ (Qt)
    class test
    {
    public:
        void test_1() const
        {
            std::list<std::pair<unsigned int, int> > headIndexes;
            headIndexes.push_back( std::make_pair( 0, -1 ) );
            std::list<std::pair<unsigned int, int> >::iterator iter = headIndexes.end();
            --iter;
        }
    };
 
    test t;
    t.test_1();

Больше подробностей... Это можно.

https://github.com/Dalidul/FSAT/blob/lazy/headtailliteral.h
https://github.com/Dalidul/FSAT/blob/lazy/headtailliteral.cpp

в файле .срр строчки 67 и 81.

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

Дело происходит в константном методе, поэтому все константное.

Как все? Даже локальные переменные? Странно...

Почему локальные? Итератор конструируется для члена класса.

А  как же мой тестовый код?

Истину говорите, сенсей.
Спасибо. Я бы не догадался.

В тестовом коде переменная, которая создает итератор - локальная.

А, строчкой выше создается другой лист, точно

Указатель на список delta лучше сразу делать умным, а не при выходе из метода.
Что-бы сразу исключить любые утечки памяти.

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

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

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

Да, это я понял.

А вы напишите маленький тест и все увидите сами. :)
Ничтожное (хотя я сомневаюсь что вы его заметите) снижение производительности на разименование никак не может сравниться с удобством и эффективностью умных указателей.
Ну тесты и профилировщик это все скажет и без меня. :)

Принято)

Почему не просто back() ?

Потому что потом я делаю перебор элементов контейнера. И их может быть больше, чем один.

Если Вы хотели перебирать в обратном порядке - есть штатный rbegin()

А вот об этом я не знал. Спасибо. Это как раз то, что нужно.

Глянул Ваши исходники - ну конечно сходу во все подробности не вник, так все аккуратно, но "сопля длинная", может лучше так

C++ (Qt)
typedef std::shared_ptr<std::list<unsigned int> >  TSharedList;

И использовать TSharedList. А то читается тяжеловато

Лучше начиная от pair и далее все нормально назвать. :)

Не стоит акцентировать внимание на shared, в программе практически все указатели будут shared (ну и некоторые weak), а то что это указатель выделить нужно:

C++ (Qt)
typedef std::list<unsigned int> DataList
typedef std::shared_ptr<DataList>  DataListPtr;
typedef std::shared_ptr<DataList>  datalist_ptr;
 

Вариант Old-а, на мой взгляд, очень хорош. Сократить название типа + скрыть ненужные подробности. Круто.

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

Самое главное при таком подходе не уйти в крайность. Когда начнут появляться дефайны дефайнов дефайнов.

Какие дефайны? Не надо дефайнов. :)
А вот typedef'ов побольше.

Может тайпдефы тайпдефов тайпдефов? :)

А еще можно using в новом стандарте. :)