|
# define foo(x) this.GoToThe(x)
|
|
|
|
|
|
Nor does
#define if while 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
#define then {
#define endif }
lets make C really basic so anyone can do it
Edit: more complete
#define IF if (
#define THEN ) {
#define ELSE } else {
#define ENDIF }
this internet has become nothing but fake news.
... time to fix it, time to get back to the fax!
modified 29-Nov-19 12:58pm.
|
|
|
|
|
I've killed for less
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Chanting:
ELSEIF ELSEIF ...
|
|
|
|
|
The C pre-processor works just fine with C# code.
|
|
|
|
|
PIEBALDconsult wrote: The C pre-processor works just fine with C# code.
That's very interesting; please say more.
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
I wonder if the fact that the notion of successfully creating useful output isn't mentioned, is relevant?
I'm sure it would be perfectly happy to tell you whereabouts the input file contained text that wasn't C compliant. In that case, I'd say that it did in fact work just fine with what you gave it. That you gave it C# when it has a dietary restriction that only allows it to consume C is irrelevant. The pre-processor still ran and exited without an error code, a crash or undefined behaviour.
Reasonable people call them Semantics, others think that Symantec's is about tiny differences in language, rather than a word that implies ownership by the Symantec company..
Going to be interesting to see what the answer is on this one. 
|
|
|
|
|
"Everything is exactly as useful as you make it." - Hacker lore
"Everything is exactly as real as it is useful." - Honey the Monster.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
Thanks, for your educational response ! The article, and comments/discussion, was interesting; imho, the technique you show is too esoteric for someone who is not C/C++ highly literate, like me.
I am reminded, by your article, of using a factory class to spit out different flavors of stuff depending on input parameters/types.
cheers, Bill
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
honey the codewitch wrote: does this refer to an invocation of the method foo? or an invocation of the delegate instance referred to by the variable or argument foo?
It's the latter which I know because of casing.
If it were the former surely it would be Foo("bar");
Oh, but I forgot, style isn't important and we can forget about consistency.
We write for compilers and they can read it just fine 
|
|
|
|
|
do you REALLY want me to enforce title casing for methods vs fields? because I can do that, and it makes my job a HELL of a lot easier.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I was thinking of this conversation of a while back: The Lounge[^]
Unfortunately, not everyone agreed with me and so they were wrong 
I won't mention names (although it's quite easy to look up), but someone literally said "Style is not important because you're writing code for compiler to read, not for developers."
And here you are wondering what the hell you're looking at while I would be absolutely sure (in my own code) because I CARE ABOUT STYLE!
I wouldn't mind enforcing PascalCase for methods and camelCase for fields and variables
|
|
|
|
|
I agree with SuperLloyd in that discussion. Context is everything.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Message analysis complete.
Found 1 error in "I agree with SuperLloyd" on line 1 column 0.
Suggested fix: change "SuperLloyd" to "Sander".
Compilation failed.
|
|
|
|
|
I admire your self confidence. When even the compiler disagrees with you, you know you've won.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I'm so confident I file a bug report when the compiler refuses to compile MY code 
Inspired by Chuck Norris, who doesn’t get compiler errors, the language changes itself to accommodate.
Seriously though, style is (somewhat) important and I think your question is a great example of how having consistent styling can make reading code so much more easy
You're probably wondering because you somehow need to parse/lex/tokenize it, in which case the other person was right, you write for compilers (maybe that's what he meant)
|
|
|
|
|
That's because Chuck Norris doesn't code in C++, C++ codes in Chuck Norris.
Style is important and if I had my way I'd make my little parser enforce my own naming conventions as it would be a bit easier on me.
But I'm not here for that. I'm here for you and I each being able to use this thing how we want, even while fighting with each other over how to use it properly. 
I used to use hungarian notation. Now I've evolved to not bother with that, and instead focus on other things because of tools like intellisense. I always try to code in a way that works well with the tools I use and that looks at home with the tools I use.
That's why I adopt different naming styles and even coding guidelines depending on context. My C++ library code uses different conventions than my other C++ code which uses different conventions than my C# code which uses different conventions than my java code, etc. My XML naming styles are different depending on context, and json naming style tends to be camelCase.
Context is everything.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: That's why I adopt different naming styles and even coding guidelines depending on context. My C++ library code uses different conventions than my other C++ code which uses different conventions
I could agree there if I (and my team) always used the same tools.
Which I (and formerly, we) do, so my style is adjusted to VS2012+.
If I sometimes used VS2019 and other times VS Code and they somehow had different styles then I'd still stick with one style.
honey the codewitch wrote: C# code which uses different conventions than my java code, etc. My XML naming styles are different depending on context, and json naming style tends to be camelCase
That's just common sense.
Or did you think me some barbarian who uses PascalCasing in JavaScript as well!? 
I've seen JavaScript written like it was C# and it really hurts the senses 
|
|
|
|
|
We at least agree on that much, bracing notwithstanding
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Privates get lower-case; all others get Pascal casing,
|
|
|
|
|
Some languages do use casing to differentiate between different classes of name. Haskell requires types to start with an upper-case letter, values (and functions are just values of course) to start with a lower-case letter and if you stray away from that, a compiler error is raised. Rust has a convention with similar rules, but raises a warning not an error if you break it.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
and i otherwise love haskell but i'm not a fan of that.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
