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.

Thank you very much.

[[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!

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.

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.

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!

Of course, there are plenty of ways to get multiple things back from a method. Let me enumerate them:

1. Return an Array

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:

• It works best if all of the return values are of the same type, otherwise you have to use an array of type object and perform a bunch of casting.
• You have to manually pack and unpack the array, which means there's the potential for error. ("Was power first or second?" etc.)

2. Create an Object to Store Them All

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.)

3. Use the Generic Tuple Class

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.)

4. Use Output Parameters

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…

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?