[Qt-creator] Alternative semantic-aware Python editor plugin
Hi everyone, a while ago I sent an email about a multi-language engine I was working on [1]. I've now created an actual Qt Creator plugin for it. In addition, since Python is typically used in conjunction with C++ projects, I decided to implement Python in my engine. I wouldn't call it production-ready yet, but I expect the editor to be doing the basics reasonably well. If you would like to try it out, just reserve a bit of patience to face eventual bugs. I even made a video, the coolest one I've ever done. :-) Unfortunately, I don't have Alessandro's charming voice and accent, but I hope you like it: https://youtu.be/XHrnvswtW6o Any feedback is appreciated. But if it's a bad one, please be kind. I've grown an emotional attachment to this project. :-) Regards, Leandro [1] https://github.com/ltcmelo/uaiso ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Use #pragma once as default instead of header guards
On Wed, Jan 13, 2016 at 7:52 AM, Joerg Bornemann wrote: > On 13-Jan-16 16:43, Coda Highland wrote: > >> #pragma once isn't non-standard. It's defined by the C++11 >> specification and a compliant compiler MUST support it. > > > Can you show me where this is defined? > AFAICT it is widely supported, but not part of the standard. > *opens up working draft* I stand corrected. I had taken a C++ class that used N3485 as its core textbook, and that class required me to implement #pragma once. I had misinterpreted this as a requirement of the specification, but it was actually presented as implementation-defined and two years later I remembered wrong. /s/ Adam ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
[Qt-creator] Creator crash
The new 3.6 build is much better on OSX :-) But I was opening 5.5.1's qtmultimedia.pro and got the error below. I had just opened it for the first time, configured it for iOS/5.5.1, clang_64 (OSX). Process: Qt Creator [243] Path: /Users/USER/*/Qt Creator.app/Contents/MacOS/Qt Creator Identifier:org.qt-project.qtcreator Version: 3.6.0 (3.6.0) Code Type: X86-64 (Native) Parent Process:??? [1] Responsible: Qt Creator [243] User ID: 501 Date/Time: 2016-01-13 11:55:18.224 -0500 OS Version:Mac OS X 10.10.5 (14F27) Report Version:11 Anonymous UUID:2461ADA1-92D0-110D-7E56-F637D2850DFF Time Awake Since Boot: 41 seconds Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: EXC_I386_GPFLT Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 org.qt-project.QtWidgets0x000108c895a4 QAbstractButton::isChecked() const + 4 1 libUtils.1.0.0.dylib0x000108a0cf3a Utils::DetailsWidget::isChecked() const + 26 2 libProjectExplorer.dylib0x000110bc8442 ProjectExplorer::Internal::TargetSetupWidget::isKitSelected() const + 18 3 libProjectExplorer.dylib0x000110bc4e09 ProjectExplorer::TargetSetupPage::isComplete() const + 57 4 org.qt-project.QtWidgets0x000108de1811 QWizard::qt_metacall(QMetaObject::Call, int, void**) + 673 5 org.qt-project.QtCore 0x0001099da55d QMetaObject::activate(QObject*, int, int, void**) + 749 6 libProjectExplorer.dylib0x000110bcae25 ProjectExplorer::Internal::TargetSetupPageWrapper::updateNoteText() + 1045 7 org.qt-project.QtCore 0x0001099da55d QMetaObject::activate(QObject*, int, int, void**) + 749 8 libProjectExplorer.dylib0x000110d46020 ProjectExplorer::KitManager::kitUpdated(ProjectExplorer::Kit*) + 64 9 libProjectExplorer.dylib0x000110bd0e13 ProjectExplorer::Kit::makeSticky() + 419 10 libAndroid.dylib0x000112441353 Android::AndroidConfigurations::updateAutomaticKitList() + 5395 11 org.qt-project.QtCore 0x0001099da55d QMetaObject::activate(QObject*, int, int, void**) + 749 12 libQtSupport.dylib 0x000111b52b90 QtSupport::QtVersionManager::qtVersionsChanged(QList const&, QList const&, QList const&) + 64 13 libQtSupport.dylib 0x000111afe61e QtSupport::QtVersionManager::removeVersion(QtSupport::BaseQtVersion*) + 206 14 libQmakeProjectManager.dylib0x00011356ae3d QmakeProjectManager::Internal::QmakeProjectImporter::cleanupKit(ProjectExplorer::Kit*) + 365 15 libProjectExplorer.dylib0x000110bc5ad2 ProjectExplorer::TargetSetupPage::handleKitRemoval(ProjectExplorer::Kit*) + 34 16 org.qt-project.QtCore 0x0001099da55d QMetaObject::activate(QObject*, int, int, void**) + 749 17 libProjectExplorer.dylib0x000110d45fc0 ProjectExplorer::KitManager::kitRemoved(ProjectExplorer::Kit*) + 64 18 libProjectExplorer.dylib0x000110bed62f ProjectExplorer::KitManager::deregisterKit(ProjectExplorer::Kit*) + 831 19 libProjectExplorer.dylib0x000110bbbf85 ProjectExplorer::ProjectImporter::removeProject(ProjectExplorer::Kit*, QString const&) + 421 20 libProjectExplorer.dylib0x000110bc36e9 ProjectExplorer::TargetSetupPage::reset() + 201 21 libProjectExplorer.dylib0x000110bc606d ProjectExplorer::TargetSetupPage::setupProject(ProjectExplorer::Project*) + 381 22 libProjectExplorer.dylib0x000110bcb196 ProjectExplorer::Internal::TargetSetupPageWrapper::done() + 22 23 org.qt-project.QtCore 0x0001099da55d QMetaObject::activate(QObject*, int, int, void**) + 749 24 org.qt-project.QtWidgets0x000108f5edd0 QAbstractButton::clicked(bool) + 64 25 org.qt-project.QtWidgets0x000108c8a95a QAbstractButton::isCheckable() const + 906 26 org.qt-project.QtWidgets0x000108c8a7b4 QAbstractButton::isCheckable() const + 484 27 org.qt-project.QtWidgets0x000108c8b80e QAbstractButton::mouseReleaseEvent(QMouseEvent*) + 270 28 org.qt-project.QtWidgets0x000108be1be1 QWidget::event(QEvent*) + 1649 29 org.qt-project.QtWidgets0x000108c8b55f QAbstractButton::event(QEvent*) + 175 30 org.qt-project.QtWidgets0x000108ba2726 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 294 31 org.qt-project.QtWidgets0x000108ba5dad QApplication::notify(QObject*, QEvent*) + 9037 32 org.qt-project.QtCore 0x0001099a7384 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 164 33 org.qt-project.QtWidgets0x000108ba3
Re: [Qt-creator] Use #pragma once as default instead of header guards
Hi, the internet claims it is not in the standard but widely supported. (https://msdn.microsoft.com/en-us/library/4141z1cx.aspx) (http://stackoverflow.com/questions/23696115/is-pragma-once-part-of-the-c11-standard) Kind Regards, Thomas Hartmann From: Qt-creator on behalf of Joerg Bornemann Sent: Wednesday, January 13, 2016 4:52 PM To: Coda Highland Cc: qt-creator@qt-project.org Subject: Re: [Qt-creator] Use #pragma once as default instead of header guards On 13-Jan-16 16:43, Coda Highland wrote: > #pragma once isn't non-standard. It's defined by the C++11 > specification and a compliant compiler MUST support it. Can you show me where this is defined? AFAICT it is widely supported, but not part of the standard. Cheers, Joerg ___ 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
Re: [Qt-creator] Use #pragma once as default instead of header guards
On 13-Jan-16 16:43, Coda Highland wrote: #pragma once isn't non-standard. It's defined by the C++11 specification and a compliant compiler MUST support it. Can you show me where this is defined? AFAICT it is widely supported, but not part of the standard. Cheers, Joerg ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Use #pragma once as default instead of header guards
On Wed, Jan 13, 2016 at 4:52 AM, Joerg Bornemann wrote: > On 13-Jan-16 13:38, Ziller Eike wrote: > >> Let’s drop the argument about the clang code model from the discussion >> about whether to use #pragma once or not. > > > Still, as it came up, this argument raises the interesting question what > will happen to users of the clang code model that cannot switch to > (non-standard) pragma once for this or that reason? #pragma once isn't non-standard. It's defined by the C++11 specification and a compliant compiler MUST support it. The real problem with #pragma once is that most implementations rely on filesystem identity to support it, which means that if you somehow get to two different copies of the header file (perhaps you include it yourself with "" and then something you include includes it with <>, and the pathing finds separate copies) the pragma won't stop the collision while classic header guards will. This isn't a reason not to support the pragma, of course. But that combined with its lack of standardization in C++03 is a reason not to default to it in a template. /s/ Adam ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Use #pragma once as default instead of header guards
On Mittwoch, 13. Januar 2016 15:22:38 CET Nikolai Kosjar wrote: > On 01/13/2016 01:52 PM, Joerg Bornemann wrote: > > Still, as it came up, this argument raises the interesting question what > > will happen to users of the clang code model that cannot switch to > > (non-standard) pragma once for this or that reason? > > > > What would it take to fix this problem? Can we work around it? Can we > > provide an upstream fix? > > A fix from Erik is pending for review at http://reviews.llvm.org/D15994 > , but so far there were no comments. > > > Apart from that, I did not understand the problem at all. > > The opening #ifndef does match the #endif, doesn't it? > > If "matches" means "is balanced with" at least. > > As far as I understand: > > The preamble includes everything up to the very first declaration (not > including it). Now the rule seems to be that a preamble is only > generated if the preprocessor conditions are balanced *within* the > preamble. In the given example #ifndef is in the preamble region, but > not #endif. If I understand correctly now, this could only happen if you try to parse the header as a translation unit, which it isn't. If you have a .cpp including that header, the #ifndef + #endif is balanced and no issues arise - or? In KDevelop we do that - we try to find the translation unit entry point for a header and use that instead of the header file directly. This fixed a huge amount of bugs for us, also outside of the preamble afaik. Furthermore, this is what you usually want anyways as you then automatically update the state of the .cpp file as well. Furthermore, you can parse "broken" headers that way which depend on the include stack/state that came before it in the .cpp file. If you don't do that already, I can only recommend you to do something like that. Cheers -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part. ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Use #pragma once as default instead of header guards
On 01/13/2016 01:52 PM, Joerg Bornemann wrote: Still, as it came up, this argument raises the interesting question what will happen to users of the clang code model that cannot switch to (non-standard) pragma once for this or that reason? What would it take to fix this problem? Can we work around it? Can we provide an upstream fix? A fix from Erik is pending for review at http://reviews.llvm.org/D15994 , but so far there were no comments. Apart from that, I did not understand the problem at all. The opening #ifndef does match the #endif, doesn't it? If "matches" means "is balanced with" at least. As far as I understand: The preamble includes everything up to the very first declaration (not including it). Now the rule seems to be that a preamble is only generated if the preprocessor conditions are balanced *within* the preamble. In the given example #ifndef is in the preamble region, but not #endif. Nikolai ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Use #pragma once as default instead of header guards
On Wed, Jan 13, 2016 at 1:54 PM, Hunger Tobias < tobias.hun...@theqtcompany.com> wrote: > I do not think #pragma once is such an item: You don't need to remember to update it when you rename the file :) -- Giuseppe D'Angelo ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Use #pragma once as default instead of header guards
On Mittwoch, 13. Januar 2016 10:55:22 CET 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 // 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.
>
> https://en.wikipedia.org/wiki/Pragma_once
>
> Best regards, Marco
Hey Marco,
can you elaborate on this please? I haven't seen such issues in KDevelop so
far. What do you mean by "matching endif"? The header file seems to have an
opening #ifndef and a matching #endif.
Cheers
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Use #pragma once as default instead of header guards
On Mi, 2016-01-13 at 12:15 +, Bubke Marco 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. I agree with Christian that we should not change the coding standard to work around problems in the code model. > Maybe we can fix it in the future but it depends on Clang. Good. > 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. No. A coding standard is supposed to help developers work with code in their project that they are not familiar with by writing down a basic set of rules that provide a base-line of consistency. This is only possible when everybody follows the same set of rules. That is why we need a broad consensus on coding style rules, with "do whatever you want" being an option only for rules that the community is split on. I do not think #pragma once is such an item: * According to Marco #pragma once is supported by all compilers we support with Qt Creator. * It is less to type * It removes the need to come up with a long name that is unique in the project * It prevents unexpected results when that name is not as unique as you thought * It prevents unexpected results when you mistype that long name once in the #define or #ifndef lines. So I am in favor changing the coding style to ask developers to use #pragma once in all new headers. I think it will most likely even make sense to update existing headers in one patch and be done with this change. Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company 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
Re: [Qt-creator] Use #pragma once as default instead of header guards
On 13-Jan-16 13:38, Ziller Eike wrote: Let’s drop the argument about the clang code model from the discussion about whether to use #pragma once or not. Still, as it came up, this argument raises the interesting question what will happen to users of the clang code model that cannot switch to (non-standard) pragma once for this or that reason? What would it take to fix this problem? Can we work around it? Can we provide an upstream fix? Apart from that, I did not understand the problem at all. The opening #ifndef does match the #endif, doesn't it? If "matches" means "is balanced with" at least. #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. Sure, let's give users the possibility to choose between include guards and pragma once. Cheers, Joerg ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Use #pragma once as default instead of header guards
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 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 on behalf of Christian
> Kandeler
> 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 // 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
Re: [Qt-creator] Settings for naming conventions
Hi again, let me enumerate your requirements and propose something addressing those. Requirements: R1. Global and per project settings R2. API working on those settings, converting names R3. Settings/API used by: - Wizards - Refactoring Code - Text Editor to validate identifiers Proposal: Enhance CppTools::CppCodeStyleSettings with the specific C++ settings you need. This is fine since naming conventions are usually part of coding styles/rules. This does not introduces anything in the text editor, but uses the infrastructure that is provided by it and the project explorer (CppCodeStyleSettings are managed by CppCodeStylePreferences, which is a TextEditor::ICodeStylePreferences). Thus, you get R1 for free. For R2, just introduce and export your new class in cpptools. This class uses CppTools::CppCodeStyleSettings. Regarding R3: CppCodeStyleSettings is already exported and can be used. * Wizards - The plugins of the wizard that wants to use the settings/api obviously needs to depend on cpptools. Is this a problem for the wizards you had in mind? * Refactoring Code - No problem since this is already in cpptools itself. qmljstools depends on cpptools and thus could also access the settings. * Text Editor to validate identifiers - A virtual function in e.g. TextEditorWidget could serve this? And the specific editors have access to their settings. Something along the lines could also be done for QML/JS or other languages (e.g. in the projects mode you can already switch the language for the coding style). Would this work? Nikolai ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Use #pragma once as default instead of header guards
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 on behalf of Christian
Kandeler
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 // 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
Re: [Qt-creator] Use #pragma once as default instead of header guards
On Wed, Jan 13, 2016 at 12:29 PM, Christian Kandeler <
christian.kande...@theqtcompany.com> wrote:
> 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 // 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.
>
>
Qt Creator could provide a fix-it for this. ;-)
What does Xcode do in the case of include guard headers? Does it create a
preamble file?
Cheers,
Cristian.
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator
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 // 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] Use #pragma once as default instead of header guards
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 // 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.
https://en.wikipedia.org/wiki/Pragma_once
Best regards, Marco
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Dev: Qt Creator 3.7 schedule
On Fr, 2016-01-08 at 15:23 +0100, Jason H wrote: > > > Sent: Thursday, January 07, 2016 at 7:53 AM > > From: "Ziller Eike" > > To: "qt-creator@qt-project.org" > > Subject: [Qt-creator] Dev: Qt Creator 3.7 schedule > > > > I just updated https://wiki.qt.io/Qt_Creator_Releases > > > > The tentative dates for Qt Creator 3.7 are: > > > > * Feature freeze w10 (~Mar 1 2016) > > * Beta release w12 (~Mar 15 2016) > > * String freeze w14 (~Mar 29 2016) > > * Release candidate w16 (~Apr 12 2016) > > * Final release w18 (~Apr 26 2016) > > Is there a page that mentions what will be in it? (Subject to change until FF) Hello Jason, Not really. The contents entirely depends on what will be polished enough in time for feature freeze. Any ongoing work is discussed here or visible over at codereview.qt-project.org, so those are the best places to keep up to date with what is going on. Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company 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
