PaperBirdMaster's questions

In C, declaring a function with an empty parameter list tells the compiler that the parameters will be defined later:

#include <stdio.h>

void f(); // DECLARAMOS una función con un número aún indeterminado de parámetros.

int main(void)
{
    f(1, 2, 3); // Llamamos a la función, aún sin definir, con tres parámetros.
    return 0;
}

void f(int x, int y, int z) // DEFINIMOS la función para recibir tres parámetros.
{
    printf("{%d, %d, %d}", x, y, z);
}

Or so I thought, it actually seems that the compiler doesn't do any parameter checking after the function is declared, since this works too:

#include <stdio.h>

void f(); // DECLARAMOS una función con un número aún indeterminado de parámetros.

int main(void)
{
    f(1, 2, 3); // Llamamos a la función, aún sin definir, con tres parámetros.
    f(1, 2);    // Llamamos a la función, aún sin definir, con dos parámetros.
    f(1);       // Llamamos a la función, aún sin definir, con un parámetro.
    f();        // Llamamos a la función, aún sin definir, sin parámetros.
    f(1, 2, 3, 4, 5, 6, 7, 8, 9, 0); // Llamamos a la función con diez parámetros!!
    return 0;
}

void f(int x, int y, int z) // DEFINIMOS la función para recibir tres parámetros.
{
    printf("{%d, %d, %d}", x, y, z);
}

Not only does it not give any compilation errors, but it compiles without alarms and executes by assigning indeterminate values ​​to unprovided variables and ignoring extra passed variables. What is happening? Shouldn't the compiler compare the function call to the function definition and cause a compile error?

We have started working on a project that uses a library that we are not allowed to modify . We find ourselves with the problem that we need to change the internal state of some objects of this library but the interface of these objects does not offer methods for it:

class Clase
{
    std::string dato1;
    std::string dato2;
public:
    void actualiza1(std::string valor) { dato1 = valor; }
};

As can be seen in the simplified example, we can change Clase::dato1but we have no way to modify Clase::dato2:

Clase c;
c.actualiza1("Dato 1"); // Correcto.
c.dato2 = "Dato 2";     // Error! dato2 es privado!

We have tried to change the data using a pointer, but it has not been possible either:

Clase c;

using str_pClase = std::string Clase::*;
str_pClase p2 = &Clase::dato2; // Error! dato2 es privado;

c.*p2 = "Dato 2";

As a last resort we have copied the drafting of the library objects but with the public members, when we need to change the internal state of the object we use the newplacement state:

class Clase
{
    std::string dato1;
    std::string dato2;
public:
    void actualiza1(std::string valor) { dato1 = valor; }
};

struct Estructura
{
    std::string dato1;
    std::string dato2;
};

Clase c;
c.actualiza1("Dato 1"); // Correcto.

Estructura *e = new(&c) Estructura;
e->dato2 = "Dato 2";    // Correcto! c.dato2 ahora es 200;

Although this seems to work, it causes other bugs as when building an object on top of an existing one, the sub-object's constructors are called and change (initialize) values ​​of the original object that we didn't want to be modified.

Is it possible to somehow bypass the data access restriction?

^{Based on this SOen question}

I can't get this simple program to compile, I get dozens of errors:

#ı?ⅽ??ᑯ℮ ˂ıᴑѕ?ᴦ℮аⅿ˃

ı?? ⅿаı?〔〕
❴
    ѕ?ᑯ‎׃‎׃ⅽᴑ?? ≪ "Hᴑ?а ⅿ??ᑯᴑ!";
    ᴦ℮??ᴦ? ⵔ;
❵

Compiling with GCC or clang, most of the errors that come out are very rare and I had never seen them before, I don't even understand them; but among the errors there is, one really catches my attention:

unknown type name 'ı??'

What do I have to include for the program to understand integer types? I only included ˂ıᴑѕ?ᴦ℮аⅿ˃because I thought a simple program doesn't need more headers.

Since c++11 the c ++ standards committee has made it a goal to approve a new standard every 3 years. This has been the case to date and we have had the following standards:

• c++14 approved in August 2014.
• c++17 approved in March 2017.
  • What are the new features of C++17? .
  • C++17 What is it? Isn't it C++? ¹ .

Standardization is divided into four working groups:

• Nucleus (Core): Maintenance of the language and standardization of new proposals.
• Evolution : Development of new features for the language.
• Library : Maintenance of the standard library and standardization of new proposals.
• Library evolution : Development of new features for the standard library.

In July 2019, the C++20 standard was considered closed. This implies that no new features can be added (although some could be removed if problems are detected) and approved features are being reviewed for possible improvements or minor corrections.

At this last meeting, it was considered that the Contracts ² proposal (technical document P0542R4 ) would not be incorporated in C++20 and is delayed to C++23.

We are going to list some of the main features that C++20 will incorporate.

¹ Due to some strange oversight, I wrote two threads about C++17.

² According to Wikipedia the contract is:

Design - by-contract is a methodology for the design and implementation of applications and components popularized by the Eiffel programming language . It consists of considering design elements as participants in a relationship similar to a business contract. Thus, components can be designed assuming that certain input conditions (pre-conditions) will be met, while certain output conditions (post-conditions) must be guaranteed, as well as class invariance (properties that remain invariant despite of the processing performed by the component).

C++ Contracts will follow the attribute syntax (added in C++11):

[[contrato modificador: expresión-condicional]]

Contracts have been moved to C++23, the following is subject to change: The available contracts are:

• expects: A type contract expectsis a pre-condition. Indicates what a function expects from its arguments, and that contract is expected to hold throughout the function call.
• ensures: A type contract ensuresis a post-condition. Indicates the state that the objects passed to a function (or the return from it) are expected to have at the end of the call.
• asert: A type contract assertis an assertion. Indicates a condition that is expected to be satisfied where the contract appears.

When a contract is not fulfilled, a function call will be made with the following signature:

void(const std::contract_violation &);

The object std::contract_violationwill contain information about the breach of contract such as where (file, line, function) has been breached.

Modifiers can be applied to contracts, modifiers will affect how code with contracts is generated and whether or not contracts are checked at runtime. The available modifiers are:

• axiom: The verification of the conditions of this contract is expected to have no cost, it is not evaluated at execution time.
• default: Verification of the conditions of this contract is expected to be inexpensive.
• audit: Verification of the terms of this contract is expected to be expensive.

The contracts that will be verified at compile time contain code that will be compiled, you can specify the level with which you want to compile each translation unit and the resulting behavior will be:

• Default: Checks (compiles) contracts marked as default(contracts that have no modifier are considered default).
• Audit: Verifies (compiles) the contracts marked as auditand default.

I am doing some tests with simply linked lists and it fails me when inserting data, I have tried this:

struct nodo
{
    int dato;
    nodo *siguiente;
};

typedef nodo * lista;

void insertar(lista l, int dato)
{
    nodo *n = new nodo;
    n->siguiente = NULL;
    n->dato = dato;
    l->siguiente = n;
}

int main()
{
    lista mi_lista;
    insertar(mi_lista, 42);
    std::cout << mi_lista->dato;
    return 0;
}

I expected the program to display 42, but instead it displays:

Segmentation fault

How do you insert data into simply linked lists?

The problem I've encountered is easily reproducible with these two objects related by inheritance:

struct B
{
    virtual void update() = 0;
};

struct D : B
{
    void update() override
    {
        std::cout << this << ' ' << __PRETTY_FUNCTION__ << '\n';
    }
};

I have some aliases that define a wrapper on Bwhich is stored in a std::stack:

using Base = std::reference_wrapper<B>;
using Bases = std::stack<Base>;

Bases bases;

And two functions that make use of these aliases:

void push(B &&b)
{
    bases.push_back(b);
}

void update()
{
    bases.top().get().update();
}

When I run it, both with GCC and CLang it seems to work:

int main()
{
    push(D{});
    update();

    return 0;
}

0x7ffd064ecd68 virtual void D::update()

But if I add a destructor to B:

struct B
{
    virtual void update() = 0;
    virtual ~B() = default; // <--- ¡Nueva línea!
};

GCC fails:

pure virtual method called
terminate called without an active exception

Aborted

But CLang seems to work:

0x7ffdffc31500 virtual void D::update()

• Why does adding a virtual destructor fail at runtime in GCC but not at runtime in CLang?
• Which compiler is behaving correctly?
• Does the code incur undefined behavior?
• The move constructor of std::reference_wrapperis deleted, but I build a Bwith a temporary, how is it possible?

I recently discovered a feature of templates that I was unaware of. It is the fusion of different declarations of the same template with different default arguments in the template arguments, it is detailed in the C++ standard (my translation):

17.1 template parameters

10. The set of available default template arguments is obtained by merging the default arguments of all previous template declarations in the same way as the default arguments of functions [ Example:

    template<class T1, class T2 = int> class A;
    template<class T1 = int, class T2> class A;
    

    It is equivalent to

    template<class T1 = int, class T2 = int> class A;
    

    — end of example ]

So I've decided to try the example that the standard mentions:

template <typename T, typename U = int> struct S;
template <typename T = int, typename U> struct S
{ void f() { std::cout << __PRETTY_FUNCTION__ << '\n'; } };

int main()
{
    S s; s.f();
    return 0;
}

The above code shows void S<int, int>::f() [T = int, U = int]when compiled with gcc HEAD 8.0.1 201803 but the compilation fails with clang HEAD 7.0.0 unless angle brackets are used when instantiating:

S s; s.f(); // error: declaration of variable 's' with deduced type 'S' requires an initializer
S<> t; t.f(); // Correcto

Leaving aside this error, I have tested this behavior in the rest of the template types and the code is accepted or rejected in an irregular way:

template <typename T, typename U = int> void function();
template <typename T = int, typename U> void function()
{ std::cout << __PRETTY_FUNCTION__ << '\n'; }

int main()
{
    /* Rechazado por GCC: no matching function for call to 'function()'
       template argument deduction/substitution failed:
       couldn't deduce template parameter 'T'
       mismo error con function<>()

       CLang compila sin problemas. */
    function(); // CLang muestra 'void function() [T = int, U = int]'
    return 0;
}

template <typename T, typename U = int> int variable;
template <typename T = int, typename U> int variable = 0;

int main()
{
    /* GCC se queja del número de argumentos (0, should be at least 1)
     mientras que CLang se queja de la redefinición de 'variable' */
    std::cout << variable<> << '\n';
    return 0;
}

template <typename T, typename U = int> using alias = int;
template <typename T = int, typename U> using alias = int;

int main()
{
    /* GCC se queja de la redefinición de 'alias'
       mientras que CLang compila sin problemas. */
    alias<> v = 0;
    std::cout << v << '\n';
    return 0;
}

The standard text doesn't differentiate between template types, so I figured all types should behave the same.

Still, the case of the template variable is the only one rejected by both compilers, so I have some doubts about this type of template. It makes sense to me that CLang rejects the template on the grounds of redefinition while I think GCC is wrong to reject the template for the wrong reasons , but this reasoning does not follow what the standard says in 17.1.10.

So, what should you expect in the case of template variables:

• The code is rejected by redefinition (CLang is right).
• The code is accepted, merging all the definitions (both GCC and CLang get it wrong).

I have an alias to a static size array, it's very simple to use:

using triplet_t = std::uint8_t[3];

//           vvvvvvvvvvvvvvvvvv <--- más fácil que std::uint8_t(&triplet)[3]
void f(const triplet_t &triplet) { /* whatever */ }

triplet_t t{}; // Tan bueno como std::uint8_t t[3]{};

t[0] = '0';
t[1] = '1';
t[2] = '2';
for (auto &v : t) std::cout << v << ' ';
std::cout << '\n';

// Todo correcto...
triplet_t t3[3]{};
for (auto &r : t3)
    for(auto &v : r)
        v = 42;

I can even use the alias in containers:

std::vector<triplet_t> vt;

Or so I thought, because the moment you use it vtfails:

vt.push_back({});

GCC 8.0.0 201711

error: parenthesized initializer in array new [-fpermissive]
{ ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

error: request for member '~unsigned char [3]' in '* __p', which is of non-class type 'unsigned char [3]'
destroy(_Up* __p) { __p->~_Up(); }
                    ~~~~~~^~~

The problem seems to be that after unrolling all the template wizardry a placement-new is called which is passed the parameters in parentheses, and this is obviously not the way to initialize a statically sized array.

Also, somehow the container thinks it triplet_t's an object and so asks for a destructor, again failing to compile. The problem obviously persists without the alias:

std::vector<std::uint8_t[3]> vt;
vt.push_back({});          // Mal!
vt.push_back({255, 0, 0}); // Error!

But there is no problem if an object with the same memory representation is used:

struct rgb { std::uint8_t r, g, b; };
std::vector<rgb> vt;
vt.push_back({});          // Bien!
vt.push_back({255, 0, 0}); // Genial!

I wonder why this happens. Is there a way to save statically sized arrays in containers?

Reading about the C++ language I have seen that some developers talk about C++17 and it is not clear to me if it is the same as C++ or if it is another language.

What is C++17?

I have the following code:

struct datos
{
    char c;
    int i;
    long l;
};

#define SO(x) #x << " = " << x

int main()
{
    datos d;

    std::cout
        << SO(sizeof(d)) << '\n'
        << SO(sizeof(d.c)) << '\n'
        << SO(sizeof(d.i)) << '\n'
        << SO(sizeof(d.l)) << '\n'
        << SO(sizeof(char) + sizeof(int) + sizeof(long)) << '\n';

    return 0;
}

Which produces the following output:

sizeof(d) = 16
sizeof(d.c) = 1
sizeof(d.i) = 4
sizeof(d.l) = 8
sizeof(char) + sizeof(int) + sizeof(long) = 13

I finished my primary studies a long time ago, but the last time I checked, adding one, four and eight was thirteen; but requesting the size of datosreturns sixteen, which is not the sum of one, four, and eight.

What's going on?

I'm working on confusing and error-prone code; the problem arises when using two coordinate systems and continually confusing the coordinates of one of the systems with those of the other.

Problem.

The application consists of a 2d roguelike game with a top view . The coordinate system for the character, projectiles, enemies, and props on the map (world coordinates) is that each number is a dungeon tile; so the tile in the upper left corner starts at position 1 {0, 0}and extends to position {0.9999…, 0.9999…}¹ .

In other words:

• Values {[0, 1), [0, 1)}​​belong to the tile {0, 0}.
• Values {[8, 9), [3, 4)}​​belong to the tile {8, 3}.
• etc…

On the other hand, the painting coordinate system (screen) is not based on tiles but on sprites , being able to zoom in on the room and placing the room in different positions depending on how the camera points, we find that the coordinates to paint the tile {x, y}would be in reality:

{x * ancho_sprite * nivel_de_zoom, y * alto_sprite * nivel_de_zoom} - vector_cámara;

This causes me problems when I pass a paint coordinate to a paint function, or when I pass a paint coordinate to an AI, logic, or physics function, which has happened to me more than once, leading to hard-to-find errors. debug.

Solution.

I have thought of creating differentiated types for each family of coordinates, and when the coordinates travel from one context to another, apply transformations automatically; that is to say: transparently to the programmer; or in the worst case cause the use of a coordinate system in the wrong context to fail.

For this purpose I am using the sfml template class Vector2and to make the coordinates of one system incompatible with those of another I have added one more level to the template:

enum contexto : char
{
    mundo,
    pantalla,
};

template <typename T, contexto C>
struct coordenada : public sf::Vector2<T>
{
    using base = Vector2<T>;
    using base::base();
    using base::base(T, T);
    // Mas directivas using...
};

With this simple trick I avoid unintentionally using coordinates from one system in another (illustrative code):

using Vector2fm = coordenada<float, mundo>;
using Vector2fp = coordenada<float, pantalla>;

struct jugador
{
    Vector2fm posicion_logica;
    Vector2fp posicion_visual;
    sf::Sprite s;
} j1;

void mover_con_teclado(Vector2fm &elemento) { /* ... */ }
void pintar_en_posicion(Vector2fp &elemento, sf::Sprite &s) { /* ... */ }

// ...

/* Error no existe conversion conocida
   de coordenada<float, pantalla> a coordenada<float, mundo> */
mover_con_teclado(j1.posicion_visual);
/* Error no existe conversion conocida
   de coordenada<float, mundo> a coordenada<float, pantalla> */
pintar_en_posicion(j1.posicion_logica, j1.s);

With this trick, if I correctly define the types of each coordinate, it solves the problem of using screen coordinates in world and vice versa.

Mistake.

All I have to do is supply the conversion operators in both directions:

enum contexto : char
{
    mundo,
    pantalla,
};

template <typename T, contexto C>
struct coordenada : public sf::Vector2<T>
{
    using base = Vector2<T>;
    using base::base();
    using base::base(T, T);
    // Mas directivas using...

    template <typename U>
    operator coordenada<T, mundo>() const
    { return { x / 2.f, y / 2.f }; } // El 2.f es ilustrativo

    template <typename U>
    operator coordenada<T, pantalla>() const
    { return { x * 2.f, y * 2.f }; } // El 2.f es ilustrativo
};

But this raises an alarm for every conversion function and still fails when trying to do the conversion:

alarma: la función de conversión convirtiendo 'coordenada<float, contexto::mundo>' a si misma nunca será usada
operator coordenada<T, mundo>() const { return { x / 2.f, y / 2.f }; }
^

alarma: la función de conversión convirtiendo 'coordenada<float, contexto::pantalla>' a si misma nunca será usada
operator coordenada<T, pantalla>() const { return { x * 2.f, y * 2.f }; }
^

The alarm apparently occurs when a certain instance of the template tries to generate conversion to itself... at the moment it doesn't bother me, what I don't understand is why the conversion still doesn't work despite having created (at least) one function valid conversion code that does not generate an alarm:

error: ninguna función coincide para llamar 'mover_con_teclado'
mover_con_teclado(j1.posicion_visual)
^~~~~~~~~~~~~~~~~
nota: la función candidata no es viable: no existe conversión conocida de 'coordenada<[...], contexto::mundo valor 0>' a 'coordenada<[...], contexto::pantalla valor 1>' para el primer argumento

error: ninguna función coincide para llamar 'pintar_en_posicion'
pintar_en_posicion(j1.posicion_logica, j1.s);
^~~~~~~~~~~~~~~~~~
nota: la función candidata no es viable: no existe conversión conocida de 'coordenada<[...], contexto::pantalla valor 1>' a 'coordenada<[...], contexto::mundo valor 0>' para el primer argumento

Ask.

How should I define the conversion operator of coordenada<float, mundo>to coordenada<float, pantalla>and its inverse?

¹ The orientation of the coordinates is the one used by sfml in that it {0, 0}is in the upper left corner and the axis ygrows downwards.

I have seen the word SFINAE mentioned in several questions, I don't know if it is all in capital letters or as a proper name: Sfinae.

Searching in Stack Overflow in Spanish I find that there are even standard documents that refer to this term, such as n3462 mentioned in How to know the version of the C standard that I am using in code? , but as much as I search I don't see that it is a library or a class. So I wonder:

What is SFINAE?

I have a series of rectangles stored in the following class:

struct rectangle
{
    rectangle(int x_, int y_, int w_, int h_) :
        x{ x_ },
        y{ y_ },
        w{ w_ },
        h{ h_ }
    {}

    bool contains(int x_, int y_) const
    {
        return (x_ >= x) &&
               (x_ <= (x + w)) &&
               (y_ >= y) &&
               (y_ <= (y + h));
    }

    int x{}, y{}, w{}, h{};
};

A fairly simple class that stores the coordinates of the top left corner of the rectangle and its width and height; also provides a function that indicates whether a given point is inside the rectangle.

I need to purge my collection of rectangles so that any rectangle that is contained in another rectangle is removed. For example my data is as follows (full data collection at the end of the thread):

[00] X: 5  Y: 2  W: 3  H: 9
[01] X: 5  Y: 3  W: 3  H: 8
[02] X: 5  Y: 4  W: 4  H: 7
[03] X: 7  Y: 5  W: 7  H: 7
...
[28] X: 7  Y: 9  W: 3  H: 3
[29] X: 6  Y: 10 W: 3  H: 3

And the visual representation of the first four rectangles would be as follows:

The rectangle 0(filled with vertical lines) contains inside the rectangle 1(filled with horizontal lines), but although both ( 0and 1) touch the rectangles 2(filled with blue) and 3(filled with yellow) they do not contain them.

So the only rectangle in the top 4 that should be removed would be the 1. I had thought that to get the functionality I want a std::setcontainer would be the right one since it doesn't allow duplicates... I just have to modify what duplicate means in this context, for that I create a free rectangle comparison operator:

bool operator <(const rectangle &l, const rectangle &r)
{
    return
        r.contains(l.x,       l.y) &&
        r.contains(l.x + l.w, l.y) &&
        r.contains(l.x,       l.y + l.h) &&
        r.contains(l.x + l.w, l.y + l.h);
}

He std::setuses total preordering through the concept of comparison using the less-than operator ( <), so the above implementation will return true if the rectangle to the right of the operation contains within it all the points of the rectangle to the left of the operation. , that is, the right rectangle is larger than the left one. With the sample data the rectangle 0would not be less than the rectangle 1but the 1would be less than 0.

But when executing the code, not only does it not eliminate the rectangles that are eaten by other rectangles, but it also eliminates rectangles that it should not eliminate. Of my collection of 30 rectangles, the std::setonly keeps the 0and the 1!

It's not clear to me if the problem is in my code or my understanding of the container std::set(or both). I'm thinking of switching to a std::vectorand cleaning the content in a second pass instead of relying on container mechanisms that don't allow duplicates, but I'd rather not.

Is there a way to get the behavior I'm looking for?

[00] X: 5  Y: 2  W: 3  H: 9
[01] X: 5  Y: 3  W: 3  H: 8
[02] X: 5  Y: 4  W: 4  H: 7
[03] X: 7  Y: 5  W: 7  H: 7
[04] X: 8  Y: 5  W: 6  H: 6
[05] X: 9  Y: 5  W: 5  H: 5
[06] X: 10 Y: 5  W: 4  H: 4
[07] X: 11 Y: 5  W: 3  H: 4
[08] X: 5  Y: 6  W: 9  H: 5
[09] X: 6  Y: 6  W: 8  H: 7
[10] X: 7  Y: 6  W: 7  H: 6
[11] X: 8  Y: 6  W: 6  H: 5
[12] X: 9  Y: 6  W: 5  H: 4
[13] X: 10 Y: 6  W: 4  H: 3
[14] X: 11 Y: 6  W: 3  H: 3
[15] X: 5  Y: 7  W: 12 H: 4
[16] X: 6  Y: 7  W: 11 H: 6
[17] X: 7  Y: 7  W: 10 H: 5
[18] X: 8  Y: 7  W: 9  H: 4
[19] X: 9  Y: 7  W: 8  H: 3
[20] X: 13 Y: 7  W: 4  H: 3
[21] X: 14 Y: 7  W: 3  H: 4
[22] X: 5  Y: 8  W: 13 H: 3
[23] X: 6  Y: 8  W: 12 H: 5
[24] X: 7  Y: 8  W: 11 H: 4
[25] X: 8  Y: 8  W: 10 H: 3
[26] X: 14 Y: 8  W: 4  H: 3
[27] X: 6  Y: 9  W: 4  H: 4
[28] X: 7  Y: 9  W: 3  H: 3
[29] X: 6  Y: 10 W: 3  H: 3

As a continuation of the question " Differences between Rvalue and Lvalue " and based on the question " What are rvalues, lvalues, xvalues, glvalues, and prvalues? ".

In C++03, an expression could be rvalueor lvalue.

As of C++11, three new categories were added, the full list of categories being:

1. rvalue: Value of the right side ( right value).
2. lvalue: Value of the left side ( left value).
3. xvalue: Expiration value (e xpiring value).
4. glvalue: Value of the generalized left-hand side ( generalized eft g) .lvalue
5. prvalue: Value of the pure right hand side ( pure right value).

We have gone from two categories to five.

• What are these new categories of expressions?
• How are they related to the rvaluey lvaluethat existed before?
• Are the rvaluey lvalue's in C++03 the same as in C++11?
• Why are these categories necessary?

Is the standards committee just trying to confuse us?

I have to process a string of comma separated values ​​containing triplets of values ​​and translate at run time each triplet to different types according to its content, the input data would be similar to:

"1x2y3z,80r160g255b,48h30m50s,1x3z,255b,1h,..."

So each sub-string should be processed as follows:

• 1x2y3zwould be processed as Vector3with x = 1, y = 2and z = 3.
• 80r160g255bwould be processed as Colorwith r = 80, g = 160and b = 255.
• 48h30m50swould be processed as Timewith h = 48, m = 30and s = 50.

The problem I run into is that each component is optional (although it always appears in the same order) so the following strings are also Vector3, Colorand Timecorrect:

• 1x3zwould be processed as Vector3with x = 1, y = 0and z = 3.
• 255bwould be processed as Colorwith r = 0, g = 0and b = 255.
• 1hwould be processed as Timewith h = 1, m = 0and s = 0.

What have I tried so far?

All components as optional.

((?:\d+A)?(?:\d+B)?(?:\d+C)?)

The characters A, Band Cwould be replaced by the correct letter in each case. This expression works fine except for the fact that it returns twice as many expected results (one for the searched string and another returns an empty string just after the first match), for example:

• 1h1m1stwo matches:
  1. "1h1m1s".
  2. "".
• 11x50ztwo matches:
  1. "11x50z".
  2. "".
• 11111htwo matches:
  1. "11111h".
  2. "".

I can't say I didn't expect it... after all an empty string matches the provided regular expression when all components are empty; so to fix this issue i tried the following:

Quantifier from 1 to 3 elements.

((?:\d+[ABC]){1,3})

But with this expression, strings are captured with the wrong order or even with repeated elements:

• 1s1m1ha match, it should not match (wrong order).
• 11z50za match, it should not match (repeated components).
• 1r1r1ba match, it should not match (repeated components).

So I made another try with a modified version of my first try:

Match from start ^to end $of the string.

^((?:\d+A)?(?:\d+B)?(?:\d+C)?)$

It works better than the first version but still matches empty strings, with the added disadvantage that I must first separate the string by each comma ( ,) and pass the expression over each sub-string.

Using Lookahead

The attempt using Lookahead:

\b(?=[^,])(?=.)((?:\d+A)?(?:\d+B)?(?:\d+C)?)\b

Against the following chain:

"48h30m50s,1h,1h1m1s,11111h,1s1m1h,1h1h1h,1s,1m,1443s,adfank,12322134445688,48h"

The results are very good, it detects valid matches without adding false positives. Unfortunately, every time a string is found that doesn't match the expression, it adds an empty string just before the invalid string (finds ""before "1s1m1h", "1h1h1h", "adfank"and "12322134445688") so I've made one last try by modifying the lookahead condition:

\b(?=(?:\d+[ABC]){1,3})(?=.)((?:\d+A)?(?:\d+B)?(?:\d+C)?)\b

This expression removes empty strings found before any strings that do not match (?:\d+[ABC]){1,3})(empty strings before "adfank"and "12322134445688"), but empty strings before "1s1m1h", "1h1h1h"are still caught.

So my question is: Is there a regular expression that matches value triplets in a given order, without repetitions, with all optional components but composed of at least one element, and doesn't match empty strings?

The regex tool I'm using is <regex>from C++11 .

I am working hard to translate my project macros into constant expressions that can be used with if constexpr. At the moment I have achieved almost satisfactory results by doing some tricks with macros, I start by defining some macros to transform values ​​to text:

#define STRINGIFY(X) #X
#define TO_STRING(X) STRINGIFY(X)

These macros behave surprisingly when passing existing or non-existent definitions, for example the following code:

std::cout << TO_STRING(_DEBUG) << '\n';

It shows _DEBUGif the homonymous macro is NOT defined, while if it is defined it shows the value of the macro. The type of the resulting value will always be a text literal (due to the macro's operator# STRINGIFY ). I use this trick to create the following enum:

template <int SIZE>
constexpr bool b(const char (&definition)[SIZE])
{
    return definition[0] != '_';
}

enum operating_system : bool
{
    iOS     = b(TO_STRING(__APPLE__)),
    Windows = b(TO_STRING(__MINGW32__)),
    Linux   = b(TO_STRING(__linux__)),
};

With this trick , the macros that are defined will have a true value while those that are not defined will have the opposite value, so I can write the following code with if constexprinstead of with #ifdef:

int main()
{
    if constexpr (operating_system::Windows)
    {
        // Cosas especificas de Windows
    }
    else if constexpr (operating_system::iOS)
    {
        // Cosas especificas de iOS
    }

    // Cosas independientes de sistema operativo.

    return 0;
}

I don't like having to delegate to a helper function to translate the values ​​(the function b), but it's a lesser evil. The biggest problem with this system is that it is only able to detect the presence of macros that start with an underscore ( _), it gives false positives for macros whose value is something that starts with an underscore ( _) and the value of the macro is lost by complete since there is no compile-time computable function that passes text to number (none of my attempts have been successful).

Therefore the following macros (obviously) do not act as expected:

#define _DEBUG 0
#define DRIVERS _09072007

template <int SIZE>
constexpr int i(const char (&definition)[SIZE])
{
    return definition[0] != '_'; // que poner aqui?...
}

enum stuff : int
{
    cpp_version     = i(TO_STRING(__cplusplus)),
    debug_enabled   = i(TO_STRING(_DEBUG)),
    drivers_version = i(TO_STRING(DRIVERS)),
};

int main()
{
    std::cout << "C++ version: "     << stuff::cpp_version << '\n'
              << "Modo debug: "      << stuff::debug_enabled << '\n'
              << "Drivers version: " << stuff::drivers_version << '\n';

    return 0;
}

The code above shows:

C++ version: 1
Modo debug: 1
Divers verson: 0

When the ideal would be to have shown:

C++ version: 201500
Modo debug: 0
Divers verson: _09072007

Since it __cplusplushas a numeric value that does not start with an underscore ( _), it gets the value 1. _DEBUGThe same thing happens to the macro : it has value 0, which would be like considering that we are not in debug mode but it gets the value 1. The opposite happens with the macro DRIVERS, which when starting with an underscore gets the value 0.

Ask.

Is there a way to get the desired output? It would be necessary at least one constexprthat passes literals from text to number.

What have I tried?

I have tried a recursive function, but indexing a text literal is not a constant expression (even with indexes known at compile time).

constexpr int power10(int n)
{
    if (n == 0)
        return 1;

    return 10 * power10(n - 1);
}

template <int SIZE>
constexpr int v(const char (&definition)[SIZE], int INDEX)
{
    // error: 'definition' no es una expresion constante
    constexpr char c = definition[INDEX];


    if (INDEX >= 0)
    {
        if constexpr (c >= '0' && c <= '9')
        {
            return v(definition, INDEX - 1) + (power10(SIZE - INDEX - 2) * (c - '0'));
        }
        else
        {
            return 0 + v(definition, INDEX - 1);
        }
    }

    return 0;
}

template <int SIZE>
constexpr int f(const char (&definition)[SIZE])
{
    return v(definition, SIZE - 2);
}

enum operating_system : bool
{
    // error: valor de el enumerador para 'iOS' no es una constante integral
    iOS     = f(TO_STRING(__APPLE__)),
    // error: valor de el enumerador para 'Windows' no es una constante integral
    Windows = f(TO_STRING(__MINGW32__)),
    // error: valor de el enumerador para 'Linux' no es una constante integral
    Linux   = f(TO_STRING(__linux__)),
};

My idea of ​​the C++17 feature Template Parameter Induction for Template Classes was that it was intended to homogenize the behavior of template functions and template classes in cases of parameter induction. But I think there is something I have not understood.

If we have this template object:

template <std::size_t S, typename T>
struct test
{
    static constexpr auto size = S;
    using type_t = T;

    test(type_t (&input)[size]) : data(input) {}
    type_t (&data)[size]{};
};

I usually use a helper function to make object creation easier test:

template <std::size_t S, typename T>
test<S, T> helper(T (&input)[S]) { return input; }

Which can be used in the following way:

int main()
{
    int buffer[5];

    auto a = helper<5, int>(buffer); // Sin deduccion.
    auto b = helper<5>(buffer);      // Tipo deducido.
    auto c = helper(buffer);         // Tipo y tamanyo deducidos.

    std::cout << a.size << b.size << c.size;

    return 0;
}

The above code shows 555as expected. I have tried the same thing on Wandbox using newer compilers ¹ :

int main()
{
    int buffer[5];

    test<5, int> a(buffer); // Sin deduccion: Funciona.
    test<5> b(buffer);      // Tipo deducido: FALLO.
    test c(buffer);         // Tipo y tamanyo deducidos: Funciona.

    std::cout << a.size << b.size << c.size;

    return 0;
}

It seems that parameter deduction for template classes only works when all parameters are deducted, I was expecting both behaviors (per-function and per-class deduction) to be the same, is there something I misunderstood?

¹ The latest compilers available on Wandbox are gcc HEAD 7.0.1 201701 and clang HEAD 5.0.0 (trunk) .

Researching the consequences of misusing the statement returnin functions voidand non- voidin the C standard I realized that it does not specify what happens when a non- function ^usesvoid an returnempty statement or a function voiduses a returnnon-empty statement:

int devolver_entero() { return; }  // no-void usa una return vacio

What I have been able to find in the standard is the following (translations are mine):

6.8.6.4 The return statement

restrictions

1. A statement returnwith an expression must not appear in a function whose return type is void. A statement returnwithout an expression must appear only in functions whose return type is void.

The above standard quote states what should be done with statements returnfor return and non-return functions, but elsewhere in the standard it states what happens when the constraints are not followed:

6.9.1 Function definitions

12. If the function terminator is reached }and the value of the function call is used by the caller, the behavior is undefined.

The above quote from the standard indicates that undefined behavior is incurred if the return value of a function that has reached the closing brace is used }, so the following example has undefined behavior:

int comportamiento_indefinido(int x) { if (x) return x; }

printf("%d", comportamiento_indefinido(1)); // Correcto
printf("%d", comportamiento_indefinido(0)); // Comportamiento indefinido

In the call comportamiento_indefinido(1)the function returns 1through the statement returnunder the conditional if (x); in the call comportamiento_indefinido(0)the condition if (x)is not met and the function ends when the closing brace is reached }, using the return of the call comportamiento_indefinido(0)is undefined behavior (but using the return of is not comportamiento_indefinido(1)). But what happens in this case?

int comportamiento_indefinido(int x) { if (x) return; } // return vacio

printf("%d", comportamiento_indefinido(1)); // Comportamiento indefinido?
printf("%d", comportamiento_indefinido(0)); // Comportamiento indefinido

In the previous example, the call comportamiento_indefinido(1)does not comply with what is indicated in §6.9.1/12to achieve undefined behavior, since the function ends without reaching the closing brace }and does not return any value either.

What part of the C standard takes this into account?

¹ Or at least I couldn't find it.

I don't understand why this code fails at runtime, it compiles with no errors and no matter how much I review the code I don't see why a segmentation fault: should jump out.

#include <iostream>

constexpr std::size_t BUFF_SIZE { 256u };

int buffer[BUFF_SIZE] {};
int *_begin = buffer;
int *_end   = buffer + (BUFF_SIZE / 2u);

int main()
{
    for (unsigned indice{}; indice < (BUFF_SIZE / 2u); ++indice) {
        *(_begin + indice) = indice;
        *(_end + indice)   = (BUFF_SIZE / 2u) - indice;
    }

    for (const auto &v : buffer) std::cout << v << '\n';

    return 0;
}

You can see the code working [here] .

Translation based on Yakk 's SO question in English .

All features of C++17 have already been approved, so it is unlikely to see any major changes. Hundreds of proposals were made for C++17.

Which of these features were added to C++ in C++17?