Version: git master (using KDE 4.8.0) OS: Linux As std::auto_ptr is declared deprecated in C++ 11, it would be nice if KDevelop understands declaration of std::unique_ptr. So far it does not support it's dereference operators Reproducible: Always Steps to Reproduce: #include <memory> class A { public: void f(){ } }; void g() { std::unique_ptr<A> ptr; ptr->//no completion here, "->" is replaced with "." } Expected Results: see above
confirmed, odd - dunno whats going on there. If I look at unique_ptr.h I see that operator->() is parsed properly - at least it seems like that... I'll investigate
minimal testcase whichs shows that we don't understand the specialization with T[] properly, see: template <typename T> class test { public: void foo() {} }; template<typename T> class test<T[]> { }; int main() { test<int> t1; // should work: t1.foo(); test<int[]> t2; // should not work: t2.foo(); return 0; }
Git commit 0832a4ddbd4ccaf53ad8425e547b7506bf65b43d by Milian Wolff. Committed on 20/02/2012 at 16:55. Pushed by mwolff into branch '4.3'. some work towards supporting template specializations with dynamic array types the instantiation is still not properly associated though, yet at least for unique_ptr the proper version is now chosen. The latter is still unusable though since the ::pointer return type is not properly evaluated yet M +6 -0 languages/cpp/cppduchain/overloadresolution.cpp M +1 -1 languages/cpp/cppduchain/templatedeclaration.cpp M +1 -0 languages/cpp/cppduchain/tests/test_duchain.h M +56 -0 languages/cpp/cppduchain/tests/test_duchain_cpp2011.cpp M +9 -0 languages/cpp/cppduchain/type_visitor.cpp M +14 -0 languages/cpp/parser/name_compiler.cpp http://commits.kde.org/kdevelop/0832a4ddbd4ccaf53ad8425e547b7506bf65b43d
what's missing now is the support for the SFINAE lookup of unique_ptr::pointer ...
Current master stopped to understand auto_ptr :(
eugene, please post a new bug report including a proper example that shows the borken auto_ptr support. it works as expected for me. bye
Hello! We are working on a new clang-based C/C++ language plugin for KDevelop 5 which supersedes the old C++ plugin in KDevelop 4. See e.g.: https://www.kdevelop.org/news/first-beta-release-kdevelop-500-available Due to a lack of manpower, we cannot fix bugs in the old C++ plugin. We rather want to supply a good Clang based C++ experience for KDevelop 5 than wasting our time on the legacy C++ support for KDevelop 4. With the new clang-based C/C++ language plugin, the bug presented here does not occur in my testing. For these reasons, I'll close this bug. Please stay tuned for KDevelop 5. If you think this bug is applicable to Clang/KDevelop 5, please reopen the report and add new information on how to reproduce the bug there. Sorry for the inconvenience, I hope you understand the reasoning above. Cheers