Let’s drop the argument about the clang code model from the discussion about whether to use #pragma once or not.
#pragma once seems to be supported by all compilers that we care about for compiling Qt Creator. It is less to type, makes renaming classes/files much more pleasant, and is less error prone. +1 from me for at least allowing to use it. Br, Eike > On Jan 13, 2016, at 1:15 PM, Bubke Marco <marco.bu...@theqtcompany.com> wrote: > > We support it but it will be slow. It is your decision. Anyway how often do > you need code completion in the header file. > > Maybe we can fix it in the future but it depends on Clang. > > Anyway I don't want to force you to anything. It was about the future. So > #pragma once would be allowed for the people who want to use it. > > ________________________________________ > From: Qt-creator <qt-creator-boun...@qt-project.org> on behalf of Christian > Kandeler <christian.kande...@theqtcompany.com> > Sent: Wednesday, January 13, 2016 12:29 PM > To: qt-creator@qt-project.org > Subject: Re: [Qt-creator] Use #pragma once as default instead of header guards > > On 01/13/2016 11:55 AM, Bubke Marco wrote: >> Hello >> >> With the clang code model there is a problem to generate a preamble file >> with header guards. Imaging a preamble file is like a automatically pre >> compiled header for the include block at the top. But there are limitations. >> One is that every ifndef has to match is #endif inside of the preamble but >> this not the case for header guards. >> >> #ifndef HEADER_GUARD >> #define HEADER_GUARD >> #include <QtGui> // this would be compiled in the preamble once >> >> void foo() >> { >> auto bahn = nullptr; >> } >> >> >> #endif >> >> We don't generate a preamble for this case because the opening ifndefs is >> not matching the endif. In that case the clang model will be very slow! >> >> So I propose we change our wizards to utilize #pragma once and use it for >> every new file. We can change header files where we need code completion on >> demand too. > > Unless I'm misunderstanding the point, you seem to suggest that people > change their (non-broken) projects to work around problems in Creator's > code model. This cannot possibly be the solution, can it? The code model > needs to support users' code, not the other way around. > > > Christian > _______________________________________________ > Qt-creator mailing list > Qt-creator@qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator > _______________________________________________ > Qt-creator mailing list > Qt-creator@qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator -- Eike Ziller, Principle Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator