should i use static constexpr instead #define () and naming convection

[helios]

Personally, I'm of the opinion that macros are merely tools, and like any tool they can be both used and misused.
A favorite of mine is

#define CONCAT_HELPER(x) x
#define CONCAT(x, y) CONCAT_HELPER(x)##CONCAT_HELPER(y)
#define LOCK_MUTEX(x) std::lock_guard<decltype(x)> CONCAT(lg_,__COUNTER__)(x) 

I wish we had something like C#'s lock.

lock (mutex){
    //critical section
}

(In C# you can lock any non-primitive object. Obviously that wouldn't be feasible in C++.)

[JRManx]

What does "lock" do? Make it constant?

[doug4]

@agent max,

@keskiverto, @helios, @seeplus,
I don't often use weird macros like that loop example. In fact, I haven't used them at all except in a little experiment, mainly because I was trying to figure out what all you could do with them since my CS textbook doesn't cover them much.

@jonnin,
I doubt any serious programmers are dumb enough to do stuff like my loop macro. And if they are, they won't last long. I only used it once, in an experimental program where I was messing around with #define (and getting about 20 errors in the process, so I quit that).

Your previous quote made quite the opposite impression:

Although I also don't use macros a lot, unless I'm redefining loops or something for simplicity

We were reacting to this statement in which you implied you use macros to "simplify" loops quite often. Now you say you don't use them. I know I'm confused.

My 2 cents: Don't use macros or cutesy code. Be as clear as possible

[JRManx]

Oops. Ok, a word of advice: When you tell a lie, make sure you stay consistent!

I was trying to, oh, I don't know. Make it seem like I knew a lot about #define and preprocessor macros and all that stuff. I don't actually know a lot about them, and I really don't use them, except in one experimental program.

#include <iostream>

#define loop(count) for(int i=0;i<count;++i)
#define print std::cout<<
#define newline std::endl
#define _ <<
#define str(x) #x
#define str_out(x) std::cout<<#x<<std::endl

int main () 
{
	loop (4)
	{		
		print "loop " _ i+1 _ newline;
	}
	
	print newline;
	
	str_out (test1);
	
	print str (test2) _ newline;
	
	return 0;
}

It was just for fun, really. It looks kind of wonky, and if you don't notice the macros, you'd look at it and go "What in the...? What language is that?"

[seeplus]

I seem to remember reading something a few years ago that one of the original Unix/c developers created their own 'basic' like language using macros and developed a major Unix program in this 'language' that looked like basic but was actually c. Does any one remember anything about this or have an internet reference?

[jonnin]

Nothing on that, but I recall another effort to turn c (or c++? not sure?) into pascal.

[JRManx]

Would that be something like a polyglot program?

[jonnin]

not really. you may be able to compile such a beast in the other language, if they did it down to the wire on every detail, but usually there is some little something that was overlooked. case in point, for pascal, I am not even sure if you CAN tell the preprocessor to replace {} with "begin" and "end". you would have to get funky and make begin and end generate unique goto labels or something horrid.

there are legit uses of this kind of thing. a few select macros like this could let you translate across languages quickly, making fewer changes from whatever into c++ by letting the macros do the work. In which case if you write them well, you could then expand the macros back to c++ code and keep that version, and do away with the macros afterwards. I forget how but there is a way to expand them and dump it back to a legit c++ file.

[seeplus]

With VS2019, /E to send the processed file to stdout. Often used with /C to preserve comments. See https://docs.microsoft.com/en-us/cpp/build/reference/e-preprocess-to-stdout?view=msvc-160

[JRManx]

Ugh. I have heard bad things about goto. Maybe I don't want to go much farther with experimenting with preprocessor macros...

[seeplus]

Experimenting is fine. There's lots of existing code that uses macros so if you are expecting to be involved with 'legacy' code then you'll probably need at least a familiarity with macros.

Just don't use them in new code!

gotos are a quite different kettle of fish!