[Development] QtCS: Notes from Modern C++ session

[Thiago Macieira]

On Friday 12 June 2015 10:17:21 Marc Mutz wrote:
> Hi Andre,
> 
> thanks for the write-up!
> 
> On Friday 12 June 2015 08:08:51 André Somers wrote:
> > Available for use then:
> range-for?

Nope and they are the ones that are bad for our containers until extended 
lifetime references show up, probably at C++17.

> variadic macros (these we already use in tests/ and no-one complained so
> far).

Nope, only with #ifdef.

> > No for now: std::for_each (issues with leaks)
> 
> Which leaks?

Not leaks, access to dangling references via as_const

	for (auto x : as_const(someFunction()))
		// dangling

> > For now, don’t put std lib ABI into Qt ABI, except for nulltpr_t.
> 
> Too late: QException inherits std::exception (for a looong time already),
> and by virtue of various exported subclasses of QVector and QList, we
> export ABI that contains std::vector and std::list (toStdList(),
> toStdVector()). We probably also export ABI using std::string, because I'm
> sure someone somewhere has inherited an exported class from QString...

QException is an exception, since we usually don't use exceptions anyway.

The export you're talking about only happens with MSVC.

Other than that, the rule stands firm.

> > For lambda’s: how to deal with captures? They are dangerous. Default to
> > capture by value, capture by reference or pointer is problem.
> 
> The first thing *I* think when thinking lambdas is: code bloat. Please be
> _very_ careful. Every lambda has it's own unique type, even if they are
> token- for-token identical. Using the same one on a template makes the
> whole template code duplicate. And I don't know any compiler that does a
> merge of binary identical code (does anyone?).

Good point, Marc.

> So, when a lambda is used in more than one place, please consider making it
> a namespace-level auto variable (only possible if it doesn't use local
> captures) or, yes, go the extra mile and write the function object
> explicitly.

No namespace-level lambdas, please. Go for a functor instead at that point, 
since you'll having a namespace-level object of 1 byte.

> Then again, using a lambda instead of a member-function private slot tends
> to leads to more compact executable code (at least than the SLOT()-based
> connect()).

I think that was the objective.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center