Errors, bugs, questions - page 2025

 

Double error in execution

#define  XY( X, Y )      X##Y
#define  f( X )  XY( g, X )
#define  MACRO1( X )     #X
#define  MACRO2( X )     MACRO1( X )
#define  SIZE    5
void OnStart()
{
    printf( "%s", MACRO2( f( SIZE )));
}

Result: f(SIZE)

Should be: g5

 
leonerd:

How do I remove the arrows from the test visualisation graph? I start testing and there are still arrows and lines from inputs from the last test.

Clean the tester.tpl template, the objects are probably there.

 
A100:

Double error in execution

Result: f(SIZE).

It should be: g5


Seems like a logical result to me.

 
fxsaber:
Seems like a logical result to me.

Expected: First substitution of the internal macro SIZE, then the intermediate macro f( X ) and finally the external macro MACRO2( X )

But the result is different even if you use incomplete logic:

#define  MACRO1( X )     #X
void OnStart()
{
    printf( "%s", MACRO1( f( SIZE )));
}
//Результат  :f(SIZE)
//должен быть:f( SIZE )

At least the difference is in the spaces

 
A100:

Expected: First substitution of the internal macro SIZE, then the intermediate macro f( X ) and finally the external macro MACRO2( X )

But the result is different even if you use incomplete logic:

At least the difference is in the whitespace

The priority for functions is, of course, from inside to outside. With macros, on the other hand, it's the other way around.

#X is a string without spaces. One can disagree with this, of course.

 
fxsaber:

The priority for functions is, of course, from the inside out. Macros, on the other hand, have it the other way round.

#X is a string without spaces. You can disagree with this, of course.

But why should we invent new complicated rules with old notation when there are already simple old rules with such notation - known to a wide circle of people and established for decades? If the rules are new, then the designations should also be new

 
A100:

Double error in execution

Result: f(SIZE)

Should be: g5

I sent similar request to service-desk a year ago (#1600034), it is still not responded. It seems they do not care about all these "geek" bugs. And in general, the language does not intend to improve, judging by all. Only big bugs are fixed, and no more.
 
A100:

Why invent new, complicated rules with old designations when there are already simple old rules with such designations - known to a wide range of people and established over decades? If the rules are new, the designations should also be new.

What exactly are we talking about? How should it be?

 
fxsaber:

What exactly are we talking about? And how should it be?

#X is the string as is - i.e. with spaces (if any). And see example above of f( SIZE ) -> g5. I did not invent these rules myself - that's how C++ compilers do it

 
Alexey Navoykov:
I sent a similar request to service-desk a year ago (#1600034), still no answer. It seems they do not care about all these "geek" bugs. And in general, the language does not intend to improve, judging by all. They only fix major bugs, nothing more.

I just came across this by accident yesterday and was surprised how in conjunction with

template<typename T, int n>

Several dozens of lines of code have literally turned into one or two (!). That's why I wrote it - at first glance it may seem a trifle. Once again I'm convinced that there is no nonsense in C++

Reason: