eferion's questions

I have a class that encapsulates the call to a member function of a class. The beauty of this encapsulation is that I can inject operations at runtime that will be executed before or after the function call itself. Very useful for, for example, associating a log to certain calls without having to modify the original class.

A fairly simplified example of the class could be this:

template<class Type, class ReturnType, class ... Args>
class FunctionWrapper
{
public:

  using FuncType = ReturnType (Type::*)(Args ...);

  FunctionWrapper(FuncType function)
    : m_function{function}
  { }

  ReturnType operator()(Type* type, Args ... args)
  {
    PreOperations();

    ReturnType toReturn = (type->*m_function)(args...);

    PostOperations();

    return toReturn;
  }

private:

  FuncType m_function;

  void PreOperations()
  { /* ... */ }

  void PostOperations()
  { /* ... */ }
};

The class in general fulfills its purpose:

struct POO
{
  int func1(int a)
  { return a*2; }

  void func2(int a)
  { std::cout << a; }
};

int main()
{
  FunctionWrapper<POO,int,int> wrapper1(&POO::func1);

  POO poo;
  std::cout << wrapper1(&poo,5);
}

However, it is not perfect and it fails when the function to encapsulate has void. So the following lines:

FunctionWrapper<POO,void,int> wrapper2(&POO::func2);
wrapper2(&poo,5);

They generate a compile-time error:

error: variable has incomplete type 'void'
    ReturnType toReturn = (type->*m_function)(args...);
               ^

The problem is that since the template is defined at the class level I can't disable the function using SFINAE:

typename std::enable_if<std::is_same<ReturnType,void>::value,void>::type
operator()(Type* type, Args ... args)
{
  PreOperations();

  (type->*m_function)(args...);

  PostOperations();
}

typename std::enable_if<!std::is_same<ReturnType,void>::value,ReturnType>::type
operator()(Type* type, Args ... args)
{
  PreOperations();

  ReturnType toReturn = (type->*m_function)(args...);

  PostOperations();

  return toReturn;
}

The compiler already takes care of letting me know that it doesn't buy the solution:

error: failed requirement 'std::is_same<int, void>::value'; 'enable_if' cannot be used to disable this declaration
  typename std::enable_if<std::is_same<ReturnType,void>::value,void>::type
                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

How can this problem be solved?

I have an object that internally stores a pretty heavy collection of objects. This collection is populated on demand, i.e. if the collection is not needed it will not be populated for life:

class Objeto
{
  std::vector<int> coleccion;

  // Solo una factoría puede crear objetos de este tipo
  Objeto();

  void RellenarColeccion()
  { /* ... */ }

public:

  // No se admiten copias
  Objeto(Objeto const&) = delete;

  // Constructor move
  Objeto(Objeto &&) = default;

  std::vector<int> const& Coleccion()
  {
    if( coleccion.empty() )
      RellenarColeccion();

     return coleccion;
  }
};

The class works perfectly. Returning a reference to the collection prevents copies and the program ends up working reasonably well... until the need arises to copy the collection from the object.

This need arises in a particular situation in which the only thing that matters about the object is its internal collection:

Objeto NuevoObjeto() // Función que emula la factoría
{ return Objeto; }

int main()
{
  // Se invoca la sintaxis move y la copia es bastante liviana
  Objeto o1 = NuevoObjeto();

  // Obtenemos la colección vía referencia. Evitamos la copia
  auto& v1 = o1.Coleccion();

  // El problema lo tenemos cuando del objeto solo queremos su coleccion
  // La copia es demasiado pesada
  auto v2 = NuevoObjeto().Coleccion();

  // Y no nos podemos quedar con la referencia
  auto& v3 = NuevoObjeto().Coleccion(); // Referencia a objeto destruido
}

Is there a solution that allows you to take advantage of the move syntax by making changes only to Objeto? The expected would be the following:

int main()
{
  // caso 1: se accede por referencia
  Objeto o1 = NuevoObjeto();
  auto& v1 = o1.Coleccion();

  // caso 2: Se llama a la sintaxis move para evitar la copia del vector
  auto v2 = NuevoObjeto().Coleccion();
}

A not very well known design pattern is the PassKey pattern which is mainly used to restrict access to certain public functions (the option would be to use friend in the main classes and that produces too much coupling).

A basic implementation could be:

template<class T>
class PassKey
{
  friend T;

  PassKey()
  { }

  PassKey(PassKey const&)
  { }

  PassKey& operator=(PassKey const&) = delete;
};

Note that all elements are private... the trick is that only the type Twill be able to create objects of this type. An example of use to see it better:

class Objeto
{
public:

  // Puede ser llamada por cualquiera
  void FuncionPublica()
  { }

  // Solo Autorizado puede llamar a esta funcion
  void FuncionRestringida(PassKey<Autorizado>)
  { }

private:

  // Nadie puede llamar a esta funcion
  void FuncionPrivada()
  { }
};

class Autorizado
{
public:

  void Func(Objeto& obj)
  {
    obj.FuncionPublica(); // ok
    obj.FuncionRestringida(PassKey<Autorizado>()); // ok
    obj.FuncionPrivada(); // error de compilacion -> esperado
  }
};


class Espia
{
public:

  void Func(Objeto& obj)
  {
    obj.FuncionPublica(); // ok
    obj.FuncionRestringida(PassKey<Autorizado>()); // error de compilacion
    obj.FuncionRestringida(PassKey<Espia>()); // error de compilacion
    obj.FuncionPrivada(); // error de compilacion -> esperado
  }
};

Well, now that the context is explained, let's get down to business. Now it turns out that it Objeto.FuncionRestringida()has to be accessed by two different classes:

class Objeto
{
public:

  // Solo Autorizado y OtraClase pueden llamar a esta funcion
  void FuncionRestringida(PassKey<Autorizado,OtraClase>);

};

... in theory the problem is not too difficult... just expand the template. let's see:

Version 1

The template now supports two types:

template<class T1, class T2 = void>
class PassKey
{
  friend T1;
  friend T2;

  PassKey()
  { }

  PassKey(PassKey const&)
  { }

  PassKey& operator=(PassKey const&) = delete;
};

Problem... the copy constructor requires the received object to be of type PassKey<Autorizado,OtraClase>, which forces you to modify so much Autorizadoas OtraClaseto create the object of the correct type... too cumbersome:

class Autorizado
{
public:

  void Func(Objeto& obj)
  {
    obj.FuncionRestringida(PassKey<Autorizado,OtraClase>()); // ok pero engorroso..
    obj.FuncionRestringida(PassKey<OtraClase,Autorizado>()); // error de compilacion
  }
};

The idea should be that each one cares to create a key with its type and create some mechanism that does the relevant conversions:

PassKey<T1> -> PassKey<T1,T2>
PassKey<T2> -> PassKey<T1,T2>

version 2

We try to overload the constructors to do the conversions:

template<class T1, class T2 = void>
class PassKey
{
  friend T1;
  friend T2;

  PassKey()
  { }

  PassKey(PassKey const&)
  { }

  PassKey(PassKey<T1> const&)
  { }

  PassKey(PassKey<T2> const&)
  { }

  PassKey& operator=(PassKey const&) = delete;
};

Problem... compilation errors occur:

error: multiple overloads of 'PassKey' instantiate to the same signature 'void (const PassKey<Autorizado> &)'
  PassKey(PassKey<T1> const&)
  ^
note: in instantiation of template class 'PassKey<Autorizado, void>' requested here
    obj.FuncionRestringida(PassKey<Autorizado>());
                       ^
note: previous declaration is here
  PassKey(PassKey const&)
  ^
error: multiple overloads of 'PassKey' instantiate to the same signature 'void (const PassKey<OtraClase> &)'
  PassKey(PassKey<T1> const&)
  ^
note: in instantiation of template class 'PassKey<OtraClase, void>' requested here
    obj.FuncionRestringida(PassKey<OtraClase>());
                       ^
note: previous declaration is here
  PassKey(PassKey const&)
error: 'PassKey<T1, T2>::PassKey(const PassKey<T2>&) [with T1 = void; T2 = void]' cannot be overloaded
error: with 'PassKey<T1, T2>::PassKey(const PassKey<T1>&) [with T1 = void; T2 = void]'
In member function 'void Autorizado::Func(Objeto&)':
error:   initializing argument 1 of 'void Objeto::FuncionRestringida(PassKey<Autorizado>)'

At this point... is there a solution to the problem?

By default reading with cinis excruciatingly slow compared to its counterpart scanf... when logic tells us it shouldn't:

• With cina direct call is made to the function that knows what the type of the target variable is.
• With scanfthe function you have to read the format string (with the dozens of possibilities that exist) to know how you have to interpret the input and then process it.

However, with a simple example it is easy to see that reality is different:

#include <iostream>
#include <chrono>
#include <string>

void cinFunc()
{
  int N;
  for( int i=0; i<100000; i++)
    std::cin >> N;
}

void scanfFunc()
{
  int N;
  for( int i=0; i<100000; i++)
    scanf(" %d",&N);
}


template<typename Func>
void Test(std::string const& title, Func f)
{
  auto start = std::chrono::steady_clock::now();
  f();
  auto end = std::chrono::steady_clock::now();
  auto diff = end - start;
  std::cout << "Test " << title << ":\t" << std::chrono::duration<double, std::milli>(diff).count() << " ms\n";
}

int main()
{
  Test("cin",cinFunc);
  Test("scanf",scanfFunc);
  return EXIT_SUCCESS;
}

The program is executed with a file containing 200,000 1-digit integers separated by a space, and the results speak for themselves:

Test cin:       64.7967 ms
Test scanf:     49.855 ms

What is the reason that C++'s own reading is so slow? How can this situation be corrected?

Let us suppose a function that must receive a random number of values ​​to display them on the screen, separating said values ​​with a certain separator.

The idea is to take advantage of the features of the new C++ standards, so the solution should take advantage of variadic templates .

The first attempt is promising, the template is able to print a sequence of numbers:

template <typename... Args>
void print(Args... args)
{
   (std::cout << ... << args) << '\n';
}


int main()
{
  print(1,2,3,4,5);
}

Now I try to insert the separator and that's when the problems start:

template <typename... Args>
void print(Args... args)
{
   (std::cout << ... << ',' << args) << '\n';
}

Bug details:

prog.cc:8:29: error: expression not permitted as operand of fold expression
   (std::cout << ... << ',' << args) << '\n';
                        ~~~~^~~~~~~
                        (      )

How could the separator be added to the sequence? The idea is to obtain a sequence such that:

1,2,3,...,N

Suppose we have the following classes:

struct A
{
  virtual ~A() = default;
};

struct B : A
{ };

In addition, we have a factory function that returns generic smart pointers of type A:

std::shared_ptr<A> FuncionFactoria(int n)
{
  if( n % 2 )
    return std::make_shared<A>();
  else
    return std::make_shared<B>();
}

And on the other hand, we have a couple of functions. One supports a smart pointer of type A and the other a smart pointer of type B:

void FuncionGenerica(std::shared_ptr<A>);
void FuncionEspecifica(std::shared_ptr<B>);

How could one perform a safe conversion between pointers? A possible example of use:

int main()
{
  for( int i=0; i<10; i++ )
  {
    std::shared_ptr<A> aSptr = FuncionFactoria(i);
    std::shared_ptr<B> bSptr = /* ¿¿¿??? */
    if( bSptr )
      FuncionEspecifica(bSptr);

    FuncionGenerica(aSptr);
  }
}

Note that pointers of type A must be valid after conversion...

Let's assume a scenario where two enums need to be in sync:

// Este enumerado necesita los valores porque se almacenan en la base de datos
enum class Enum1
{
  A = 12,
  B = 4,
  C = 5,
};

// Este enumerado es necesario para realizar tareas de iteración
// y porque si :)
enum class Enum2
{
  NoValue,
  A,
  B,
  C,
  MaxValues
};

In addition, we find a catalog of utility functions that take advantage of these enumerated:

// Convierte cada etiqueta en su representación a string
std::string ToString(Enum1 valor)
{
  switch( valor )
  {
    case Enum1::A: return "A";
    case Enum1::B: return "B";
    case Enum1::C: return "C";
  }

  return "";
}

Enum1 FromString(std::string const& valor)
{
  if( valor == "A" ) return Enum1::A;
  if( valor == "B" ) return Enum1::B;
  if( valor == "C" ) return Enum1::C;

  throw std::runtime_exception("valor no valido");
}

Enum1 Convert(Enum2 value)
{
  switch( value )
  {
    case Enum2::A: return Enum1::A;
    case Enum2::B: return Enum1::B;
    case Enum2::C: return Enum1::C;
  }

  throw std::runtime_exception("valor no valido");
}

// ...

Is there a more elegant way to keep the enums in sync?

Ideally, the implemented solution would also avoid the cost associated with manually editing utility functions every time values ​​are added/removed to enumerations.

Since time immemorial we have at our disposal macros and inline functions:

#define SUMA(a,b) a+b

inline int suma(int a, int b)
{ return a + b; }

However since C++11 it is available constexpr(whose functionality has been greatly increased in C++14):

constexpr int suma(int a, int b)
{ return a + b; }

What is the difference between these three options? Which option would be more recommended?

I am not able to compile the following code snippet:

struct Base
{
  int valor;

  Base()
    : valor(1)
  { }
};

struct Hija : Base
{
  int func()
  { return valor; }
};

int main()
{
  Base* punteroBase = new Hija;
  Hija* punteroHija = dynamic_cast<Hija*>(punteroBase);
  std::cout << punteroHija->func();
}

The error that appears to me is the following:

main.cpp:21:54: error: cannot dynamic_cast 'punteroBase' (of type 'struct Base*') to type 'struct Hija*' (source type is not polymorphic)

Looking at the code it is clear that both classes are related via inheritance and yet it dynamic_castdoes not work.

What is causing this problem? How can I solve that?

In this portal I have met people who think that the scope of the variables should be the minimum essential while others think that it is best to extend their life to the maximum possible.

What advantages does each of these two options provide?

I have a TextBoxand I want that while the mouse is over the control, a will appear Buttonon the right side, above the TextBox. The fact is that the TextBoxalso has a custom behavior, so both controls are embedded in a custom control that inherits from UserControl. All of this, of course, using WinForms.

The first thing that occurred to me is to handle the events MouseEnterand MouseLeaveas shown below:

public partial class MiControl : UserControl
{
  void textBox_MouseEnter(object sender, EventArgs e)
  {
    boton.Visible = true;
  }

  void textBox_MouseLeave(object sender, EventArgs e)
  {
    boton.Visible = false;
  }
}

This option works fine until the mouse hovers over the Button. At that moment both events begin to alternate uncontrollably and the only visible effect is that the button cannot be pressed. The truth is that it makes all the sense in the world: if the mouse hovers over it, Buttontechnically it is leaving the TextBox, so the event is fired MouseLeave. The latter causes the mouse to become inside the TextBox, which triggers the event MouseEnterand starts over.

How could I control this situation?

In Qtyou can create nested projects, for which you have to define the main project as SUBDIRS. Apart from this configuration, the main project does not support many more modifications.

If you want to share, for example, configuration files (.pri) between the different subprojects, you can choose several ways:

• Indicate the absolute path to the file. The disadvantage of this mechanism is that it can cause problems when working in a group, since you force everyone to have the projects in the same place.
• Indicate the path relative to the file. The disadvantage of this system lies in the fact that each subproject can host more subprojects, which makes it necessary to indicate a different route for each project.
• Storing the path in a system variable, which forces you to create, edit, and maintain the system variable, usually by hand.

Ideally, you would be able to determine the path from the location of the parent project and make that information accessible to all projects. What has been commented here could be extended to any type of values ​​to be shared between the different projects (version information, manifest, ...)

Isn't there a slightly more elegant mechanism for sharing information in the context of nested projects?

In C++ we have two similar mechanisms to limit the scope of a variable to the current code file (not header):

//fichero.cpp

// opción 1
static std::string Mensaje = "algo"; 

// opción 2
namespace
{
  std::string Mensaje = "algo";
}

Is there a difference between both options? Which should be used? Why?

For some time now, two terms have been appearing on some blogs that I don't quite understand: Rvalueand Lvalue. Without being clear about the meaning of both terms, the content of certain examples becomes complicated to understand.

1. What differences are there between a Rvalueand a Lvalue?
2. How can each be identified?
3. What can and cannot be done with each of them?

In what scenarios is it recommended to use std::move?

std::vector<int> func()
{
  std::vector<int> toReturn(1000000,5);
  return std::move(toReturn); // 1
}

int main()
{
  std::vector<int> datos = std::move(func()); // 2

  // operaciones varias
}

In the example above, are the uses of std::move? Why? What effects can misuse of std::move have?

Given the following code:

class Padre
{
  public:
    int func()
    { return 0; }

    int func2()
    { return 0; }
};

class Hija
  : public Padre
{
  public:
    int func(int param)
    { return param; }
};

int main()
{
  Hija clase;

  std::cout << clase.func(); << std::endl; // ERROR
  std::cout << clase.func(5); << std::endl; // OK
  std::cout << clase.func2(); << std::endl; // OK
}

Why does the method funcof the parent class not exist in the child class despite the fact that the inheritance is public, and yet it func2does?