Jump to content

  • Log In with Google      Sign In   
  • Create Account

Awesome job so far everyone! Please give us your feedback on how our article efforts are going. We still need more finished articles for our May contest theme: Remake the Classics

C# how to mimic #define X A and #include <defs.h>


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 dragonalumni   Members   -  Reputation: 106

Like
0Likes
Like

Posted 14 March 2012 - 07:58 AM

Wow, I just took a bullet to the head. I can't believe C# doesn't have proper include and define abilities. I've been reading on google about it for the past hour and I don't know how I should deal with some easily solved problems in C++.

For example

--start defs.h

#define GAME_NAME "REALLY GOOD GAME"
#define MAIN_IP "127.0.0.1"
#define MAIN_PORT 1234

--end defs.h


So, problem 1, can't define anything, problem 2 can't include it if I could. I want every single bit of code part of the code to know some definitions, I'm quite new to C# so please spell it out exactly if you have time to help with this problem.

#2 Cornstalks   Moderator*   -  Reputation: 5362

Like
1Likes
Like

Posted 14 March 2012 - 08:06 AM

It looks like what you actually want are global variables (even in C++, it's better to have a global variable than a global #define). C# tried to get people to not use globals, but you can do the same thing by making variables static. While I don't actually really like this page's explanation, I think it's got a simple enough sample: linky.
[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#3 NightCreature83   Crossbones+   -  Reputation: 1158

Like
0Likes
Like

Posted 14 March 2012 - 08:08 AM

Stick them in a static class and make them all public statics, this achieves the same thing as defines as those are global as well. If they are in their own namespace use "using namespaceYourGlobalsAreIn;" at the top of your C# files where you want to use them.
Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2

#4 Álvaro   Members   -  Reputation: 5802

Like
0Likes
Like

Posted 14 March 2012 - 08:37 AM

Why exactly do you feel that the whole program needs to know about the name of the game or some IP and port? It's probably much better to have non-global variables for this.

If you want to use "defs.h" as some sort of configuration file, you should probably have an actual configuration file instead, so the program reads in key-value pairs at startup and then different parts of the program can query for whatever configuration they need.

#5 Serapth   Members   -  Reputation: 3283

Like
0Likes
Like

Posted 14 March 2012 - 08:59 AM

Why exactly do you feel that the whole program needs to know about the name of the game or some IP and port? It's probably much better to have non-global variables for this.

If you want to use "defs.h" as some sort of configuration file, you should probably have an actual configuration file instead, so the program reads in key-value pairs at startup and then different parts of the program can query for whatever configuration they need.




This, especially the config file thing.

Take advantage of the language you are using, C# makes using configuration files laughably easy, chances are you already have an app.config xml file that you aren't using. Use it, then accessing it's contents is literally a single line of code.

#6 Telastyn   Members   -  Reputation: 3329

Like
0Likes
Like

Posted 14 March 2012 - 09:40 AM

Personally I like a normal class that just contains config values. You can (de)serialize it from disk, but it doesn't need to be there. Makes it much easier to allow different configuration sources which makes unit testing less impeded. Plus you can use json serialization, which is just nicer for config files humans might need to work with. And there's actually type information with your config values (yay).

#7 dragonalumni   Members   -  Reputation: 106

Like
0Likes
Like

Posted 16 March 2012 - 10:16 AM

It looks like what you actually want are global variables (even in C++, it's better to have a global variable than a global #define). C# tried to get people to not use globals, but you can do the same thing by making variables static. While I don't actually really like this page's explanation, I think it's got a simple enough sample: linky.


At first I was just crazy about the lack of include and defines, but through this example I found it really was no big deal and I learned a bit in the process about my new language. Thanks.

#8 Cornstalks   Moderator*   -  Reputation: 5362

Like
0Likes
Like

Posted 16 March 2012 - 11:42 AM


It looks like what you actually want are global variables (even in C++, it's better to have a global variable than a global #define). C# tried to get people to not use globals, but you can do the same thing by making variables static. While I don't actually really like this page's explanation, I think it's got a simple enough sample: linky.


At first I was just crazy about the lack of include and defines, but through this example I found it really was no big deal and I learned a bit in the process about my new language. Thanks.

I'm glad it was useful, but I honestly hope you take to heart what was said about config files. They're a beauty in C#.
[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#9 dragonalumni   Members   -  Reputation: 106

Like
0Likes
Like

Posted 16 March 2012 - 12:16 PM

I'm sorry, I have re-read you post and it's 2am here and I've been coding for 10 hours but I just don't see what you said about config files..




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS