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

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*

Re: [Development] RFC: new moc feature

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

Re: [Development] RFC: new moc feature

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

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

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

Re: [Development] RFC: new moc feature

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

Re: [Development] RFC: new moc feature

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 =

Re: [Development] RFC: new moc feature

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 ___

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

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

Re: [Development] RFC: new moc feature

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

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

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

[Development] RFC: new moc feature

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

Re: [Development] RFC: new moc feature

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

Re: [Development] RFC: new moc feature

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