Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » C / C++ IDE (CDT) » non-managed c++ projects and scanner (c++ version stanrd that is recognzed by the scanner)
non-managed c++ projects and scanner [message #1854725] Sun, 04 September 2022 22:31 Go to next message
Kent Dorfman is currently offline Kent DorfmanFriend
Messages: 20
Registered: December 2020
Junior Member
I don't like managed projects. I prefer to create and manage my own Makefiles. Since starting to work more with C++17 I'm seeing a lot of issues with the CDT scanner not recognizing the alowable C++17 syntax.

This is an example


templace<typename T=double> class X {};
X object; // allowed in c++17
X<> object; // empty type specializer required pre-C++17


When I create/import a C++17 external makefile project I don't have access to the "C++ dialect" project option so I'm not clear on what version of the standard the scanner expects my code to be. Under eclipse 2022-06 and associated CDT, what is the greatest c++ language standard version supported, and what must be done to make it recognized under "extern makefile" project?
Re: non-managed c++ projects and scanner [message #1855319 is a reply to message #1854725] Fri, 07 October 2022 21:14 Go to previous messageGo to next message
Kent Dorfman is currently offline Kent DorfmanFriend
Messages: 20
Registered: December 2020
Junior Member
crickets chirping...


and another serious annoyance: header file extends std::runtime_error as
class MyException:public std::runtime_error {
public:
    using std::runtimer_error::runtime_error;
};


in cpp file:

throw MyException("bug");


says MyError is ambiguous but doesn't provide any possible solutions. If it's ambiguous then it should at least list the possibilities of what it thinks it "may be".

not a language or build problem, as the Makefile builds it without issue, and it performs as expected, but as soon as the CDT scanner/analyzer runs it generates these superfluous errors...as well as others.

All I'm looking for is an authoritative statement on the latest C++ spec that should be well supported. If c++17 isn't supported then so be it, but trying to find specific information in the foundation website is ...


[Updated on: Fri, 07 October 2022 22:00]

Report message to a moderator

Re: non-managed c++ projects and scanner [message #1855409 is a reply to message #1855319] Wed, 12 October 2022 16:53 Go to previous message
Kent Dorfman is currently offline Kent DorfmanFriend
Messages: 20
Registered: December 2020
Junior Member
FWIW, I had to go the undesirable route of manually hacking (script wrapping) the g++-10 compiler to always insert --std=c++17 to get something close to the desired behaviour. Seems eclipse indexer/analyzer uses the compiler output extensively in determining warnings/errors. there are still c++17 things eclipse doesn't understand, even though the compiler defaults to the higher standard.

propagating exception constructors with "using" is one such thing that is still broken.

Previous Topic:Indexer fails: ambiguous node while parsing .cpp
Next Topic:Cant compile even hello world
Goto Forum:
  


Current Time: Fri Apr 19 00:26:24 GMT 2024

Powered by FUDForum. Page generated in 0.02529 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top