Re: [Development] RFC: more liberal 'auto' rules?

[Julien Blanc]

Le samedi 05 décembre 2015 à 12:08 +, Bubke Marco a écrit :

> >
> >> - template code (esp., but not necessarily only, when the type name
> >> would require the use of 'typename')
> >
> > This is the one i’m not at ease with. Template code tends to be
> > difficult to read, partly *because* there’s no type information. For
> > readability concerns, i would prefer a local typedef named by the
> > concept. Yes, that makes it two lines instead of one, but i think that’s
> > one case where hinting the reader with a well-chosen type name makes a
> > lot of sense.
> 
> Most typedefs I have seen was about hiding pointer or container types like 
> CursorPointer or Cursors. But is CursorPointer a unique pointer,  a shared 
> pointer and which flavor is it. Cursors is the same because it could be 
> std::vector or QList. Some would hide a dictionary behind this name. So the 
> typedef can be misleading. In that case I prefer auto. 
> 
> std::shared cursorPointer = document.cursorAtPostion(46);
> 
> CursorPointer cursorPointer = document.cursorAtPostion(46);
> 
> auto cursorPointer = document.cursorAtPostion(46);
> 
> I prefer the last but we need good tooling to show the type. It would be nice 
> to have much more information like size,  is it movable or copyable. It is 
> not only the type and we can provide that information. 

My understanding of Marc’s proposal was that it was more for the
following case :

template void algorithm(List& input)
{
typename List::value_type& first = input.front();
...
}

replaced by :
template void algorithm(List& input)
{
auto& first = input.front();
...
}

whereas i prefer 
template void algorithm(List& input)
{
typedef typename List::value_type Serializable;
// there are some requirements on List : item_type must be
// Serializable : now i can look the doc to see what a
// Serializable is
Serializable& first = input.front(); 
// i know what to expect from first, which methods i can call
...
}

I think the latter improves readability over the two others, because it
just gives more information to the reader. And this information is
currently *not* given by the type system, because concepts do not exists
in the type system yet. No tooling will ever give you a type information
here : it depends on the template instanciation.

Regards,

Julien Blanc

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: new moc feature

[Marc Mutz]

On Saturday 05 December 2015 13:00:44 Sean Harmer wrote:
> So given the above example we'd be able to have something like this 
> (name of macro pending):
> 
>  if (e->type() == NodeUpdated) {
>  const QScenePropertyChangePtr  = 
> qSharedPointerCast(e);
>  switch (propertyChange->propertyNameStringId()) {
>  case qStrId("scale3D"):
>  m_scale = propertyChange->value().value();
>  updateMatrix();
>  break;
>  case qStrId("rotation"):
>  m_rotation = propertyChange->value().value();
>  updateMatrix();
>  break;
>  case qStrId("translation"):
>  m_translation = propertyChange->value().value();
>  updateMatrix();
>  break;
>  case qStrId("enabled"):
>  m_enabled = propertyChange->value().toBool();
>  break;
>   default:
>  qWarning() << "Unknown property update";
>  }
>  }
> 
> Where the qStrId macro expands to nothing and the preprocess tool 
> replaces its contents with the hashed value. No idea if all of our 
> supported compilers allow hooking in custom preprocessors or not.

How do you handle the invariable hash collisions?

What's wrong the the old and trusted

  switch (propName.front()) {
  case 's': if (propName == "scale3D") ...
  case 'r': if (propName == "rotation") ...

(and why the QByteArrayLiteral in the original code)?

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: new moc feature

[Marc Mutz]

On Saturday 05 December 2015 20:20:27 Sean Harmer wrote:
> I was 
> just wondering if we could get it down to the theoretical ideal of a 
> single integer comparison mapped into the finite set of strings in use. 
> Seems not, without some non-neglible effort.

man 1 gperf ?

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Marc Mutz]

On Saturday 05 December 2015 13:46:53 Julien Blanc wrote:
> Le samedi 05 décembre 2015 à 12:08 +, Bubke Marco a écrit :
[...]
> whereas i prefer
> template void algorithm(List& input)
> {
> typedef typename List::value_type Serializable;
> // there are some requirements on List : item_type must be
> // Serializable : now i can look the doc to see what a
> // Serializable is
> Serializable& first = input.front();
> // i know what to expect from first, which methods i can call
> ...
> }
[...]

Thank YOU! That's the PERFECT example of why you should use _auto_! In the 
best of Qt traditions:

   You're Doing It Wrong!

If you don't see why, try to pass a C array to your function... There's a 
_reason_ we have std::begin(), and a _reason_ why we have iterator_traits.

The _correct_ way to write this is without auto or decltype is:

template 
void algorithm(List ) {
using namespace std;
// no decltype, so way to refer to decltype(begin(list),
// so need to defer to a helper:
algorithm_impl(begin(list), end(list));
}
template 
void algorithm_impl(ForwardIterator first, ForwardIterator last) {
if (first == last)
return;
typedef typename std::iterator_traits::value_type
Serializable;
// useless comments
Serializable  = *first:
}

Well, or, with auto:

   template 
   void algorithm(List ) {
   using namespace std;
   auto first = begin(list), last = end(list);
   if (first == last)
   return;
   auto  = *first;
   
   }

Everyone who claims that the first one is more readable is crazy.

And please don't _anyone_ out yourself as _actually_ believing that the first 
is more readable, because then I would have personally insulted you, and I 
don't want to do that. Let's hope common sense prevails and we all get out of 
this awkward situation with saved faces...

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: new moc feature

[Konstantin Tokarev]

05.12.2015, 22:29, "Marc Mutz" :
> On Saturday 05 December 2015 20:20:27 Sean Harmer wrote:
>>  I was
>>  just wondering if we could get it down to the theoretical ideal of a
>>  single integer comparison mapped into the finite set of strings in use.
>>  Seems not, without some non-neglible effort.
>
> man 1 gperf ?

IMO, integration of gperf needs too much scaffolding. re2c is more convenient 
for implementing of string switch

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: new moc feature

[Sean Harmer]

Hi Marc,

On 05/12/2015 19:06, Marc Mutz wrote:

On Saturday 05 December 2015 13:00:44 Sean Harmer wrote:

So given the above example we'd be able to have something like this
(name of macro pending):

  if (e->type() == NodeUpdated) {
  const QScenePropertyChangePtr  =
qSharedPointerCast(e);
  switch (propertyChange->propertyNameStringId()) {
  case qStrId("scale3D"):
  m_scale = propertyChange->value().value();
  updateMatrix();
  break;
  case qStrId("rotation"):
  m_rotation = propertyChange->value().value();
  updateMatrix();
  break;
  case qStrId("translation"):
  m_translation = propertyChange->value().value();
  updateMatrix();
  break;
  case qStrId("enabled"):
  m_enabled = propertyChange->value().toBool();
  break;
   default:
  qWarning() << "Unknown property update";
  }
  }

Where the qStrId macro expands to nothing and the preprocess tool
replaces its contents with the hashed value. No idea if all of our
supported compilers allow hooking in custom preprocessors or not.

How do you handle the invariable hash collisions?


Not sure yet. Still thinking this through.

The chances of a collision within the scope of a comparison such as this 
is pretty small (of course dependent upon the quality of the hash 
function). If used within a hash the compiler would complain about 
duplicated case labels.


If the preprocess tool maintains a catalogue of entries in the hash it 
could also warn about collisions to allow the user opportunity to alter 
the names being used.



What's wrong the the old and trusted

   switch (propName.front()) {
   case 's': if (propName == "scale3D") ...
   case 'r': if (propName == "rotation") ...


Indeed, this is something we could adopt now with little effort. I was 
just wondering if we could get it down to the theoretical ideal of a 
single integer comparison mapped into the finite set of strings in use. 
Seems not, without some non-neglible effort.



(and why the QByteArrayLiteral in the original code)?


Simple oversight. Will fix.

Cheers,

Sean

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: new moc feature

[Marc Mutz]

On Saturday 05 December 2015 20:06:22 Marc Mutz wrote:
> invariable

inevitable

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Please do not remove QtWebkit from 5.6 official binaries

[Knoll Lars]

On 03/12/15 15:09, "Development on behalf of Edward Sutton" 
 
on behalf of edward.sut...@subsite.com> wrote:

Will Qt 5.6 have alternative methods to export HTML to PDF that support major 
platforms of Android, iOS, Linux, OS X, and Windows?

On iOS a Qt developer must resort to native code to generate PDF files.

Unfortunately Qt 5.5 PDF export is dependent on QPrinter which is not supported 
on iOS.  While iOS can create and displays PDF’s just fine, iOS has no printer 
support.


In the future, Is it possible the PDF creation dependency could be separated 
from QPrinter?  So that Qt PDF generation would have better cross-platform 
support?


QPrinter printer(QPrinter::ScreenResolution); // QPrinter not supported on 
iOS

printer.setOutputFormat(QPrinter::PdfFormat);

printer.setOutputFileName(pdfFileName);

drawReport(printer);

m_painter.end();


Without understanding internals of PDF file creation, it feels like PDF 
creation should not be dependent on QPrinter?

We have an alternative to using QPrinter since Qt 5.0. Please have a look at 
QPdfWriter. It's in Qt Gui, fully platform independent and should just work on 
iOS.

Cheers,
Lars



-Ed


On Dec 3, 2015, at 7:37 AM, Mark De Wit 
> wrote:

Thanks for all the feedback everyone.

We are excited about the 5.6 release because we are looking closely at the new 
Qt3D module, as well as migrating to VS 2015.  Sadly, PDF export of HTML 
content is a critical feature for our product (in general I’m happy to move to 
WebEngine, but we cannot remove output functionality from our software).

Building from source would be an option, I guess.  We have done it in the past, 
but the build process / flags (for distribution) is not sufficiently well 
documented, and starting with 5.5.1 we were excited to be able to use official 
binaries.

Kind regards,
Mark

From: Turunen Tuukka [mailto:tuukka.turu...@theqtcompany.com]
Sent: 03 December 2015 12:30
To: Mark De Wit >; 
development@qt-project.org
Subject: RE: [Development] Please do not remove QtWebkit from 5.6 official 
binaries


Hi Mark,

If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5. 
There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt 
WebEngine is in many aspects already much better in features than Qt Webkit. Qt 
WebEngine is also better maintained, and does receive much more improvements 
and security fixes than Qt Webkit. Even though some features of Qt WebKit are 
not in same way available with Qt WebEngine, it is overall a better choice. Qt 
Webkit is removed from Qt 5.6 because it is no longer maintained well enough to 
be part of an official Qt release. We are also not developing and testing it to 
work with Qt 5.6.

Yours,

  Tuukka

From: Development [mailto:development-boun...@qt-project.org] On Behalf Of Mark 
De Wit
Sent: torstaina 3. joulukuuta 2015 13.18
To: development@qt-project.org
Subject: [Development] Please do not remove QtWebkit from 5.6 official binaries

Hi all,

QtWebEngine does not yet have feature parity with QtWebkit.  For instance, 
print support (especially export to PDF) is a critical requirement for my use 
of Webkit.  This missing feature prevents me from migrating to WebEngine.

Removing webkit from the official distribution will prevent me (and surely 
others) from upgrading to 5.6.

Thanks,
Mark
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

This email and any files transmitted with it from The Charles Machine Works, 
Inc. are confidential and intended solely for the use of the individual or 
entity to which they are addressed. If you have received this email in error 
please notify the sender. Our company accepts no liability for the contents of 
this email, or for the consequences of any actions taken on the basis of the 
information provided, unless that information is subsequently confirmed in 
writing. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of the 
company. Finally, the recipient should check this email and any attachments for 
the presence of viruses. The company accepts no liability for any damage caused 
by any virus transmitted by this email.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: new moc feature

[Sean Harmer]

Hi Olivier,

On 05/12/2015 10:22, Olivier Goffart wrote:

On Saturday 5. December 2015 09:30:33 Sean Harmer wrote:

Hi devs,

I'd like to get some feedback on a new feature for moc before we take it
any further than mild musing. The context is Qt3D has some frontend
QObject subclass types, and corresponding backend, non-QObject subclass
types for reasons of allowing us to process data on the backend without
blocking the main thread or locking it.

To get the property values from the frontend objects to the backend we
wrap the data up in QScenePropertyChange and in the backend object we
unpack the data and handle it with code something like this:

  if (e->type() == NodeUpdated) {
  const QScenePropertyChangePtr  =
qSharedPointerCast(e);
  if (propertyChange->propertyName() ==
QByteArrayLiteral("scale3D")) {
  m_scale = propertyChange->value().value();
  updateMatrix();
  } else if (propertyChange->propertyName() ==
QByteArrayLiteral("rotation")) {
  m_rotation = propertyChange->value().value();
  updateMatrix();
  } else if (propertyChange->propertyName() ==
QByteArrayLiteral("translation")) {
  m_translation = propertyChange->value().value();
  updateMatrix();
  } else if (propertyChange->propertyName() ==
QByteArrayLiteral("enabled")) {
  m_enabled = propertyChange->value().toBool();
  }
  }

Not too bad in this case but those cascaded if-else if blocks are not
good when the number of properties is large.

Why not?  Readability or performence?


Both but performance is the main driver as potentially we have a large 
number of string comparisons.





This is where the proposed new feature of moc would come in. If moc were
able to generate an enum where each enum value corresponds to a static
property we would be able to use a switch in the above code.

Is such a feature feasible? Are there reasons why it couldn't work?

I'm afraid this is not feasable. This enum would need to be in the header, and
the moc generated code is not a header.


Ah yes of course. Silly me.


Instead, I would suggest something similar to llvm::StringSwitch
http://code.woboq.org/llvm/llvm/include/llvm/ADT/StringSwitch.h.html


Right, thanks. I've also been considering compile time hashing of the 
strings via constexpr implementation of some hashing algorithm but from 
reading around it seems MSVC2012 won't be up to the job for this approach.


So at present that leaves a build time preprocess tool that goes over 
the sources and replaces marked up strings with their hashed values. 
Plus side is that the work is done at build time leaving just an integer 
comparison at run time. Down side is getting access to the original 
strings during debugging/runtime. This could be overcome by having the 
debugger/runtime load up the mapping of hashed values to original strings.


So given the above example we'd be able to have something like this 
(name of macro pending):


if (e->type() == NodeUpdated) {
const QScenePropertyChangePtr  = 
qSharedPointerCast(e);

switch (propertyChange->propertyNameStringId()) {
case qStrId("scale3D"):
m_scale = propertyChange->value().value();
updateMatrix();
break;
case qStrId("rotation"):
m_rotation = propertyChange->value().value();
updateMatrix();
break;
case qStrId("translation"):
m_translation = propertyChange->value().value();
updateMatrix();
break;
case qStrId("enabled"):
m_enabled = propertyChange->value().toBool();
break;
 default:
qWarning() << "Unknown property update";
}
}

Where the qStrId macro expands to nothing and the preprocess tool 
replaces its contents with the hashed value. No idea if all of our 
supported compilers allow hooking in custom preprocessors or not.


Yes, I know in this particular case, the wrapping/unwrapping of the 
property values in QVariants is likely the bottleneck but we can solve 
that with specialised property change types.


Cheers,

Sean

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Bubke Marco]

On December 5, 2015 12:08:51 Julien Blanc  wrote:

> Le vendredi 04 décembre 2015 à 18:10 -0500, Matthew Woehlke a écrit : 
>> On 2015-12-04 17:43, André Pönitz wrote:
>> > On Fri, Dec 04, 2015 at 04:33:26PM -0500, Matthew Woehlke wrote:
>> >> Which of these is easier to read? (More importantly, which is easier to
>> >> *verify* that it is correct?)
>> >>
>> >>   for (int i = 0; i < list.size(); ++i)
>> >> foo(list[i]);
> [snip] 
>> 
>> >>   for (auto i : qtIndexRange(list.size())
>> >> foo(list[i]);
>> > 
>> > In any case, this is an uncommon pattern, using some unknown qtIndexRange()
>> > function.
>> 
>> Really?
>> 
>>   (Python)
>>   for i in range(len(list))
>
> Am I the only one to think that this example is inherently broken ? I
> mean, why wouldn’t any sane person write :
>
> for(auto const& element : list)
> foo(element)
>
> or
> std::for_each(list.begin(), list.end(), foo);
>
> Because :
> - it’s shorter
> - it’s more readable
> - it works for non random-access-container types
> - bonus : range checking is not needed, so it should be more performant
> - bonus : it doesn’t resort to a temporary value, same remark

What if you want to iterate over two lists.

for token,  cursors in zip(tokens,  cursors):
   ... 

is quite handy. 

You can use std::transform for some cases but C++ is sometimes very far behind. 
To my understanding Ranges should provide a good solution for it but they hide 
the type for good reasons. 

>
> Now, getting back to what Marc proposed initially, because the debate
> has gone far away from his initial proposal :
>
>> - template code (esp., but not necessarily only, when the type name
>> would require the use of 'typename')
>
> This is the one i’m not at ease with. Template code tends to be
> difficult to read, partly *because* there’s no type information. For
> readability concerns, i would prefer a local typedef named by the
> concept. Yes, that makes it two lines instead of one, but i think that’s
> one case where hinting the reader with a well-chosen type name makes a
> lot of sense.

Most typedefs I have seen was about hiding pointer or container types like 
CursorPointer or Cursors. But is CursorPointer a unique pointer,  a shared 
pointer and which flavor is it. Cursors is the same because it could be 
std::vector or QList. Some would hide a dictionary behind this name. So the 
typedef can be misleading. In that case I prefer auto. 

std::shared cursorPointer = document.cursorAtPostion(46);

CursorPointer cursorPointer = document.cursorAtPostion(46);

auto cursorPointer = document.cursorAtPostion(46);

I prefer the last but we need good tooling to show the type. It would be nice 
to have much more information like size,  is it movable or copyable. It is not 
only the type and we can provide that information. 

>> - all loop variables (both index and iterators)
>>   the reason being that spelling out the name is usually wrong:
>>  size_t i = stdVector.size() // wrong, should be
>>  std::vector::size_type...
>>  also helps when porting from Qt containers to STL ones
>
> That looks perfectly fine for me. Index based loops should be avoided
> whenever it is possible, and for iterator based loops auto makes no harm
> (seriously, who wants to write
> std::vector::const_iterator instead of auto ?).
>
>> - all references to elements in a collection (same problem - way too
>> easy to misspell std::pair for std::pair...)
>
> Same thing.
>
> Regards,
>
> Julien
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] RFC: new moc feature

[Sean Harmer]

Hi devs,

I'd like to get some feedback on a new feature for moc before we take it 
any further than mild musing. The context is Qt3D has some frontend 
QObject subclass types, and corresponding backend, non-QObject subclass 
types for reasons of allowing us to process data on the backend without 
blocking the main thread or locking it.


To get the property values from the frontend objects to the backend we 
wrap the data up in QScenePropertyChange and in the backend object we 
unpack the data and handle it with code something like this:


if (e->type() == NodeUpdated) {
const QScenePropertyChangePtr  = 
qSharedPointerCast(e);
if (propertyChange->propertyName() == 
QByteArrayLiteral("scale3D")) {

m_scale = propertyChange->value().value();
updateMatrix();
} else if (propertyChange->propertyName() == 
QByteArrayLiteral("rotation")) {

m_rotation = propertyChange->value().value();
updateMatrix();
} else if (propertyChange->propertyName() == 
QByteArrayLiteral("translation")) {

m_translation = propertyChange->value().value();
updateMatrix();
} else if (propertyChange->propertyName() == 
QByteArrayLiteral("enabled")) {

m_enabled = propertyChange->value().toBool();
}
}

Not too bad in this case but those cascaded if-else if blocks are not 
good when the number of properties is large.


This is where the proposed new feature of moc would come in. If moc were 
able to generate an enum where each enum value corresponds to a static 
property we would be able to use a switch in the above code.


Is such a feature feasible? Are there reasons why it couldn't work?

Thanks in advance for any feedback.

Cheers,

Sean

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: new moc feature

[Olivier Goffart]

On Saturday 5. December 2015 09:30:33 Sean Harmer wrote:
> Hi devs,
> 
> I'd like to get some feedback on a new feature for moc before we take it
> any further than mild musing. The context is Qt3D has some frontend
> QObject subclass types, and corresponding backend, non-QObject subclass
> types for reasons of allowing us to process data on the backend without
> blocking the main thread or locking it.
> 
> To get the property values from the frontend objects to the backend we
> wrap the data up in QScenePropertyChange and in the backend object we
> unpack the data and handle it with code something like this:
> 
>  if (e->type() == NodeUpdated) {
>  const QScenePropertyChangePtr  =
> qSharedPointerCast(e);
>  if (propertyChange->propertyName() ==
> QByteArrayLiteral("scale3D")) {
>  m_scale = propertyChange->value().value();
>  updateMatrix();
>  } else if (propertyChange->propertyName() ==
> QByteArrayLiteral("rotation")) {
>  m_rotation = propertyChange->value().value();
>  updateMatrix();
>  } else if (propertyChange->propertyName() ==
> QByteArrayLiteral("translation")) {
>  m_translation = propertyChange->value().value();
>  updateMatrix();
>  } else if (propertyChange->propertyName() ==
> QByteArrayLiteral("enabled")) {
>  m_enabled = propertyChange->value().toBool();
>  }
>  }
> 
> Not too bad in this case but those cascaded if-else if blocks are not
> good when the number of properties is large.

Why not?  Readability or performence?

> This is where the proposed new feature of moc would come in. If moc were
> able to generate an enum where each enum value corresponds to a static
> property we would be able to use a switch in the above code.
> 
> Is such a feature feasible? Are there reasons why it couldn't work?

I'm afraid this is not feasable. This enum would need to be in the header, and 
the moc generated code is not a header.


Instead, I would suggest something similar to llvm::StringSwitch
http://code.woboq.org/llvm/llvm/include/llvm/ADT/StringSwitch.h.html

-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: new moc feature

[Kevin Kofler]

Olivier Goffart wrote:
> Instead, I would suggest something similar to llvm::StringSwitch
> http://code.woboq.org/llvm/llvm/include/llvm/ADT/StringSwitch.h.html

Ewww, this is horrible! It will evaluate ALL the result values passed to it, 
whether the cases match or not. That works if the values are just enum 
constants, as in their example, but if you have any function calls in it, 
the complexity and side effects (!) of EVERY function call get triggered. 
Plus, in that case, you'd be taking and storing the address of a temporary, 
which is a very very bad idea by itself. So this is a very dangerous class. 
At most, this can be used to convert the strings into an integer or enum to 
feed into a real switch that does the actual work.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development