fellow noobs read this!!

Pages: 12
Have you ever had to send a whole bunch of related variables to a function? I just found these things called structs. If you think of a variable like a container for a value you can think of a struct as a container for containers. in other words you can have a bunch of variables in a struct and then rather than send all those variables individual to the function you just pass it the struct and your done!! check out structs here: http://www.cplusplus.com/doc/tutorial/structures/ this has helped me ALLOT I hope it helps you too.
I'm glad to see a person so excited about C++, it's refreashing. You're going to flip your **** when you discover classes though :D enjoy!
Last edited on
Make sure you're not standing when you read about templates, or OOD.
I know about templates and classes and such but I never knew you could use an object as an argument. If I would have known about this when I started using objects I could have saved hours! Instead or just passing the objects I would make like 4-7 functions to make it easier for me. If I would have know this sooner I also would not have quit my text based rpg.
Wait, so you knew about objects and classes, and just now figured out you could use them to store and pass around data? What did you use them for before?
oh I used them to pass around data but I did not know you could use it as an argument so rather than: function(objectname) I would use: function(objectname.data1, objectname.data2, objectname.data3, objectname.data4)
Must have been tough. Especially considering that without doing that, you can't perform many things you do in OOD.
now that I know there is literally a whole new world opened up to me.
Did you read about operator overloading?
;^)

http://www.cplusplus.com/doc/tutorial/classes2/
closed account (zb0S216C)
Let me get this straight. You're saying that placing method arguments into a structure( or struct ) is easier? If so, there are few problems. For example, this is an example of what you are saying in my eyes:
1
2
3
4
5
6
7
8
9
10
11
struct ARGUMENTS
{
    int Arg1;
    float Arg2;
};

void Method( ARGUMENTS &Args )
{
    Args.Arg1 = 5;
    Args.Arg2 = 5.5f;
}


What if I change the structure to this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
struct ARGUMENTS
{
    int Arg1;
    
    struct ConstArgs
    {
        float Arg2;
        const int ConstArg1;
    } ConstArgs;
};

void Method( ARGUMENTS &Args )
{
    Args.Arg1 = 5;
    Args.Arg2 = 5.5f;   // Error: Arg2 is a member of ConstArgs, not ARGUMENTS. 
}


In the last example, I would have to rewrite the entire method( Or how many methods that use this structure for it's arguments ) if I changed the layout of the structure.

For me, passing arguments in a list is preferred.
Your point makes no sense, it's like saying this:
1
2
3
4
void Function( int x )
{
    x = 5;
}

1
2
3
4
void Function( string x )
{
    x = 5; // error, x is not a number
}

I have to rewrite the function if I change the argument types.


When you design a class or struct you know what interface you are creating.
As Bazzy said- if you design interfaces, you don't just change them later on. The only exception is when it turns out your initial design was faulty and you absolutely need to change the interface to go on. But then that's a mistake on your part (and a pretty bad one too).
Welcome to the real world. You'll soon put all that Perl to rest.
closed account (zb0S216C)
When you design a class or struct you know what interface you are creating.

Yeah, I already know that. What if another developer( if you're working as a team ) decides that he needs( or want's ) to change the interface? If you used an argument list, you know what is and isn't accessible.

1
2
3
4
void Function( string x )
{
    x = 5; // error, x is not a number <-- I would rephrase this.
}

In the above example, I would personally throw an exception for an integer.
Last edited on
Im not thinking just for arguments more of a way to keep related values together for whatever you might need them for. The big point here is that I did not know you could use a struct or a class as an argument and it is something that may be helpfull for other noobs such as myself.
Framework wrote:
Yeah, I already know that. What if another developer( if you're working as a team ) decides that he needs( or want's ) to change the interface? If you used an argument list, you know what is and isn't accessible.
Usually who use an interface is not allowed to change it. You should read about OOP
closed account (zb0S216C)
may be helpfull for other noobs such as myself

Yes it may help but you have to make sure that you use strict rules for assignment and struct layout. Exceptions will help you with assignment.
In the above example, I would personally throw an exception for an integer.


How exactly? You are always assigning an integer, so you need to change the code. It isn't a run-time issue at all. >_>
closed account (zb0S216C)
How exactly? You are always assigning an integer

Type-casting springs to mind.
Typecasting to get around a compiler error sounds like a very bad idea. And in any case, you simply can't throw an exception for something like that, as it is a compile-time problem.
Pages: 12