octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #48753] KeyboardTranslator.h macros failing wi


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #48753] KeyboardTranslator.h macros failing with Qt5 and GCC 4.8.4
Date: Wed, 10 Aug 2016 21:48:04 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0

Follow-up Comment #3, bug #48753 (project octave):

I looked up the KDE license, as my memory is that it isn't GPL, but it looks
like multiple licenses for various parts of the code.

Anyway, your suggestion didn't change anything, just says:


         _k_static_##NAME = static_cast<TYPE *> (0);                          
                       \
                          ^


It seems to me there are two types of errors.  One is this:


/home/sebald/octave/octave/octave/libgui/qterminal/libqterminal/unix/KeyboardTranslator.h:100:19:
error: cannot convert 'QBasicAtomicPointer<KeyboardTranslatorManager>' to
'KeyboardTranslatorManager*' in initialization
         TYPE *x = _k_static_##NAME;                                          
 \
                   ^


My guess is that one is a Qt5 issue because of the QBasicAtomicPointer.  If
I'm remembering correctly, that declaration is to make the pointer something
for which signals/slots can be used, or passed within a signal/slot--I forget
exactly.

And then there is this second group:


error: use of deleted function 'QBasicAtomicPointer<X>&
QBasicAtomicPointer<X>::operator=(const QBasicAtomicPointer<X>&) [with X =
KeyboardTranslatorManager]'


I think that is a C++11 issue:

http://stackoverflow.com/questions/27959496/why-c11-implicitly-deletes-my-default-constructor

Following what the checkmarked reply says, it's that "=" and other operators
that is the problem.  The compiler doesn't know how to create those operators
implicitly.  The operator definitions within this macro code must not be to
the compiler's liking.

Is a static global translator manager necessary?  Couldn't there be a global
pointer to a translator manager and then use "new" at the start of the main
routine?


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48753>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]