Okay, so I was goofing around, and I tried to make a method that would return two variables (you can do it in a more snakey language). Is it possible in C#?
Let's say I am frequently using angle and power. Could I do something like
angle, power = FindTrajectory()
void FindTrajectory()
{
//ask user for angle and power
return a, p;
}
Is that possible somehow?
The short answer is no. C# isn't "snakey" enough for that. That was a feature of Python that I always liked. I wish more languages had it, but C# doesn't. Not directly anyway.
Of course, there are plenty of ways to get multiple things back from a method. Let me enumerate them:
This would look like this:
double[] FindTrajectory() { // Do some work... return new double[] { a, p }; }
Then:
double[] results = FindTrajectory(); double angle = results[0]; double power = results[1];
This is probably the simplest of approaches, but it has two serious drawbacks:
public class Trajectory { public double Angle { get; private set; } public double Power { get; private set; } public Trajectory(double angle, double power) { Angle = angle; Power = power; } }
(And actually, looking back at it, that is a perfect time for a struct instead of a class. Either one will work, functionally.)
Then:
public Trajectory GetTrajectory() { // Some work here... return new Trajectory(a, p); }
Trajectory trajectory = GetTrajectory();
That is a more "object-oriented" approach. It solves some of the problems that the first thing had. Your types can be different, and because the properties that the data is stored in are named ("Angle" and "Power") is is unlikely that anyone would mess it up.
But on the other hand, it means building a full class for use in potentially one location. Which if that's the case, seems like overkill for sure. (If you're using this data all over the place, this is probably what I'd recommend.)
If you like the above approach, but you don't like building a whole new class for a single use, you might consider using the Tuple class. It's generic, so you have to understand C# generics for it to be useful. I don't know what level you see yourself at, but generics aren't exactly a beginner level feature. I'm not going to explain generics here, but see that link for more information.
This would look more like this:
public Tuple<double, double> GetTrajectory() { // Do some work here. return new Tuple<double, double>(a, p); }
Tuple<double, double> trajectory = GetTrajectory(); double angle = trajectory.Item1; double power = trajectory.Item2;
The Tuple class lets you package up multiple values to pass around. Because it's generic, you could create one that has any parameter types. This keeps your type safety, so you know what type of data you're working with at all times, and you don't have to build and maintain a new class on your own, but Item1 and Item2 are terrible names. They're completely meaningless. If you built your own class, that's not a problem.
Again, I'd only recommend doing this if you are only going to use this in one place. (Even then, I'd personally still give strong consideration to option #2.)
The fourth option is to use output parameters. This, again, isn't exactly C# 101. The method would be restructured to look like this:
public static void GetTrajectory(out double angle, out double power) { // Do some work... angle = a; power = p; }
And then you'd call it like this:
double angle; double power; GetTrajectory(out angle, out power); // Use angle and power here however you want.
Using output parameters means that the two methods are essentially sharing the same memory location, and can both read from it and write to it. With the out keyword, we establish the expectation that the called method will write to the location before it finishes. (If you don't, it won't compile.)
Output parameters can be very useful, and very powerful. This exact situation is a big part of why they exist. But it takes a little bit of getting used to. Having two methods share the exact same memory/storage location like this has some gotchas that take some experience to get used to. Output parameters often are overused when people first learn about them. (Don't go make every method use output parameters.)
For the sake of being complete (I've typed all this already; I might as well keep going, right?) I should also mention that you can also have reference parameters, which look the same, but use the ref keyword instead of out. These, too, share the same storage location in the calling site and the called method. However, ref established the expectation that the caller will be the one to make sure it's assigned. The called method can assume there's already some data there to work with.
Whew. That was a lot. Hopefully I've helped you, not confused you. My personal normal approach is to build a class or struct for it (Option #2). But there is a time and a place for all of the above. You just have to consider the pros and cons of each, and what you're hoping to achieve.
Let me know if you have other questions from what I said…
Greetings BenStark, and hello again RB.
For what it's worth Ben, I support using method #2. I've found it to be the easiest to understand and implement. There's also the bonus (correct me if I'm wrong, Mr. Whitaker), that you can access the struct members by name if needed. For example, with the following code:
struct Trajectory
{
public Vector3 Direction;
public float speed;
}
Trajectory MyTrajectory;
You can manipulate settings in the following manner:
TestClass ClassTest=new TestClass(); //sample class
MyTrajectory=new Trajectory();
MyTrajectory.Direction = new Vector3(0.0f, 0.0f, 1.0f);
MyTrajectory.speed = 0.0f;
ClassTest.TestFunction(MyTrajectory); //function call to manipulate the Trajectory MyTrajectory
When calling classes, you can pass the struct in and return it as any other variable.
namespace WindowsGame1
{
class TestClass
{
public Trajectory TestFunction(Trajectory IncomingTrajectory)
{
// Code to manipulate IncomingTrajectory here
Trajectory OutgoingTrajectory=IncomingTrajectory;
return OutgoingTrajectory;
}
}
}
Of course, all of this working is contingent on placing the struct in the appropriate place (in the main class, directly after the using statements, so all the other classes can inherit it). Hope this is helpful, and if I've gotten anything incorrect, I defer to the unbounded wisdom of Mr. Whitaker. Stick with him, he knows how to put a whooping on some code!
Looking through this code example I saw this line and realized it might be a little confusing. You normally will NOT want to set the output to the input, however since I have no code that does the manipulation to the variables, I had to put something in so it would compile (can't return an empty variable, in this case the Trajectory struct). In most scenarios, you will want something that looks like the following:
namespace WindowsGame1 { class TestClass { public Trajectory TestFunction(Trajectory IncomingTrajectory) { // Code to manipulate IncomingTrajectory here Trajectory OutgoingTrajectory = new Trajectory(); //create a new temporary instance of the Trajectory struct OutgoingTrajectory.Direction = IncomingTrajectory.Direction; //set our new temporary direction instance to the one passed in OutgoingTrajectory.speed = IncomingTrajectory.speed; //set our new temporary speed instance to the one passed in //do whatever manipulation to the variables you want/need to (or retrieve input from the user); in this case I just added some random values to the incoming variables. OutgoingTrajectory.Direction = Vector3.Add(OutgoingTrajectory.Direction, new Vector3(0, 0, 1)); OutgoingTrajectory.speed = OutgoingTrajectory.speed+1; return OutgoingTrajectory; //return the manipulated figures in a Trajectory struct } } }
Sorry if that caused any confusion, I'm still somewhat new and learning myself.
"May the mercy of His Divine Shadow fall upon you." - Stanley H. Tweedle, Security Guard class IV, The League of 20,000 planets
Your comments made me laugh, PiscesMike! I have to correct you though. My wisdom is bounded. It's just over 9000! (Hee hee hee… It's funny because it's a meme….)
What PiscesMike said is the same reason why I like option #2 the best in most cases as well. You've got named properties (or instance variables, depending on how you implement it) bundled up in a reusable package. Option #1 and #3 don't have intelligent names associated with what you get back, while option #4 doesn't bundle them together into a reusable package.
In fact, if the mental model that you have is "I have a trajectory that has two pieces of information that define it (angle and power)," then to be true to object-oriented principles, you should definitely make a type out of it. Object-orientation tells you that you build reusable types out of the concepts that your program has or the mental model of the programmer or user.
The difference between a class and a struct is subtle but significant. I know I cover it in my tutorials, but I also know I cover it much better in my book. I won't go into the details about it here and now unless you're super interested in it. Either one could be used here though.
Generally speaking, people put new types (classes, structs, enumerations…) in their own file, with a matching name. If your Main method is in a Program class (that's the default, right?) then it is probably also contained in a Program.cs file. Unlike some other languages, you're not required to make the file name and type name match, nor are you limited to just putting one type in each file.
What PiscesMike was describing would have you put the class or struct in the same Program.cs file, which will work just fine. I have a personal preference (perhaps its the Java programming that I've done) to try to stick to the 1 type per file, and keep the file name and type name sync'd. It just makes it easier for me to find the code I'm looking for.
There are, of course, exceptions to this. Not the least of which is if you've got a class that's used by the world, and another that is very closely associated with that class. As in, it's never used except in conjunction with that class. Then I might consider putting this secondary/helper/utility class in the same file as the main class.
I believe in my tutorial on creating classes, I describe how to actually create a class in a second file.
The one thing you have to watch out for is the namespace that the different types (classes/structs) are in. A type can use anything in the namespace that it is contained in (assuming it's accessibility (the public/private/protected/internal junk) says it can). It can also use things in other namespaces, it just has to add a using directive at the top of the file (there are already a bunch there that you can mimic) or a fully qualified name. (That is, instead of just using the type name, you preface it with the namespace name that the type belongs to.)
And by the way, when you start getting lots of files and lots of types in your project, you'll usually want to start grouping things into folders. Generally speaking, each folder will get its own namespace, and the name of the namespace is whatever you had plus the folder name. (If you have a game that has a UI folder with some files in it, plus a subfolder containing a Controls folder, your namespace for things in the UI folder might be AwesomeCompanyName.Game9FromOuterSpace.UI, while things in the subfolder would be in the namespace AwesomeCompanyName.Game9FromOuterSpace.UI.Controls.
Once again, though, that's the standard practice, but there's no requirement on folder structures and namespaces. You can break with tradition if you want.
Once again… I've gone on and on. I need a cork.
By the way, PiscesMike, you can get the code snippets with something like this:
[[code]]
public static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
[[/code]]
This turns out like this:
public static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}You can specify a language like this:
[[code type="java"]]
public static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
[[/code]]
This turns out like this:
public static void Main(string[] args) { Console.WriteLine("Hello World!"); }
Unfortunately, there's no C#. So I'm forced to use Java. That gets you syntax highlighting that's fairly close at least. I've talked with the Wikidot people about adding C# in, but they can't do it. They're using a PHP module to do this (PEAR::TextHighlighter or something) so the only way to get it would be for me to go add a C# syntax highlighter to that project. I just don't have time for that.
There shouldn't be any restrictions on new users for this. I know some people have ran into problems trying to post links, and I usually try to go in and edit their posts so the link works (if it's not a spam link). I often do the same when people post code, but I'll let you go ahead and edit your own posts, now that you know how it works!
Holy Cow, that was a lot more information than I expected. I consider myself a beginner, but I understood most of what you posted. I think I am getting more comfortable with C#. I am on tutorial #22. Maybe I'll finish this weekend.
Thank you very much.
I haven't read all the post, too much…
Basicly C or any derivate DOES NOT support returning more than 1 variable. So you cannot return 2 or more values.
The options are:
1-encapsulate the returning values in an kind of object
2-using in/out parameters
For 1:
Old C hadn't objects so, the only way to do this was using STRUCTS. Well you could use arrays instead, but a struct makes more sense from a semantic point of view and less prone to errors. So, my preference (because my background is C hehe) is using first structs, then objects (objects add a significative amoount of overhead), then anykind of collection (arrays, lists, dictionarys -why not? ;) - ).
For 2:
If you have to use OUT parameters… well.. out types are designed for values that CAN change inside a method, not to workaround the limitations of the language. What if your method creates 2 objects, who would be the parameters? empty obviously because the user should never give any because is the method itself which creates the objects.
The key is OUT parameters are essentially related to the meaning of the variables.If the parameter needs to be changed in the method, then it's ok being out… if you are using it like a mechanism to return 2 values, then it's not a good method, but many times the language limitations imposes you the way to follow.
Use Structs.
