The first three lines are correct. You don't actually need to use typedef to define copies of the Ty1 and Ty2 types. I Just did that mostly out of habit.
Anywhere in the code first_type and Ty1 are the exact same and are interchangeable (and with second_type/Ty2).

Admittedly this example doesn't show any practical use of typedef, and that would take a bit too long for me to explain, so I'll just sum it up in a very short and probably not too helpful sentence: it's useful when you're using the templated types with other templates.

At 6/27/12 10:55 PM, egg82 wrote:
run function Pair(Ty1, Ty2)

(the pair constructor seems redundant, as it's pretty much the code above)

The first part is the declaration, the second part is the definition.
You could include the declaration inside of the class block, but that's not good practice.

They are both required though; that's how OOP works in C++.

At 6/27/12 10:55 PM, egg82 wrote:
Though I wonder: is there any real benefit in not using the namespace? It seems like using std::cout would be a pain after a while. Why not namespace it so all you have to type is cout?

Technically there is no benefit in either option.
If you do using namespace std; or using std::cout it will save you from having to type a few extra characters, but that's it. There isn't any reason I didn't use it; that's just the way I typed out the code.

Since int was used, and not int& or int* the variable was passed by value.
This means that a whole new int was made and only exists in the scope of the function at the time that it is executed, and afterward it is deallocated/destructed.

That will change the value of foo to 1234.
A new int object will not be created, although an int technically will be allocated since a pointer is an address to a memory location, which is just an integer, but I won't get into that.

At 6/27/12 10:55 PM, egg82 wrote:
That's... Somewhat hard to imagine. What about sizeof? It seems that it's pulling SOMETHING from the array.

Well what I meant by that is that arrays in C++ can't do something like this:

However, if you use sizeof on an array, you will get: SIZE_OF_TYPE_IN_BYTES * NUM_ELEMENTS.

So, if you had an array of 5 integers on a 32bit system you would get 20.
Because a 32bit integer is 4 bytes, and there are 5 elements. 4 * 5 = 20.

If you have an array of 12 integers on a 64bit system then you would get 96.
Because a 64bit integer is 8 bytes, and there are 12 elements. 8 * 12 = 96.

Using that knowledge you can make things like the ARRAY_LENGTH pre-processor macro I wrote in my previous post.

At 6/27/12 10:55 PM, egg82 wrote:
Yikes. What if the array is empty? You'd be dividing by zero o.o

You can't make an empty array in C++.
The following will not compile:

int main()
{
int foo[0];
return 0;
}

As well arrays in C++ can NEVER CHANGE SIZE.
That concept will seem very alien if you come from higher level languages such as PHP, Python or AS3, but arrays cannot change size in C++. If you make an array of 10 integers then it will always be an array of 10 integers until it is de-allocated.

So, so long as you know for a fact you are giving that macro an array it will always work.

At 6/27/12 10:55 PM, egg82 wrote:
Why do you even need to divide, anyway? It'd seem that sizeof() would get the size of the array object, would it not?

As I explained above using sizeof on an array returns the total amount of memory the array is using up.
So you need to divide that by the amount of memory the base type uses up, which you get by doing sizeof(myArray[0]).

Arrays can never change size, and arrays can only contain one type, so that's how you do it.

At 6/27/12 10:55 PM, egg82 wrote:
I would assume that #ifndef and #endif means something to the C++ compiler, I just have no idea what.

The compiler never sees that code. The pre-processor handles it, and then afterward the result is sent to the compiler.

I enjoyed this copy and paste, do you even make websites, or you fill of shit?

Post links please.

You're kidding me, right? First, you're lame for copying/pasting code. Secondly, what's with the run-on sentence? Third, you're going to sit there and question Diki's competence? I can say for sure that Diki knows what he is doing, and I go as far as saying that he is a useful resource on this forum. By-the-way, he's provided full examples, as well as clear and thorough posts. You haven't. Period. Yet. Period.

At 6/27/12 11:34 PM, Diki wrote:
The first part is the declaration, the second part is the definition.
You could include the declaration inside of the class block, but that's not good practice.

They are both required though; that's how OOP works in C++.

Declaration and definition seem awfully redundant in C++, then. You already created and assigned your variables above, then did it again in the constructor.

Technically there is no benefit in either option.
If you do using namespace std; or using std::cout it will save you from having to type a few extra characters, but that's it. There isn't any reason I didn't use it; that's just the way I typed out the code.

The ampersand is how you make the variable a reference, just like how the asterisk is used to make the variable a pointer.

Oh, duh. I remembered the asterisk, but not the ampersand.

Well actually, passing by value is neither using a pointer or a reference.

That's what I was talking about. I forgot that I learned about passing by reference (and the actual benefits), so I thought that in C++ all I could do was pass by value (make a copy) or pass by pointer (integer copy of the memory address of the variable you want to change)

So, if you had an array of 5 integers on a 32bit system you would get 20.
Because a 32bit integer is 4 bytes, and there are 5 elements. 4 * 5 = 20.

If you have an array of 12 integers on a 64bit system then you would get 96.
Because a 64bit integer is 8 bytes, and there are 12 elements. 8 * 12 = 96.

Using that knowledge you can make things like the ARRAY_LENGTH pre-processor macro I wrote in my previous post.

ahh,I see. I've never learned about getting the actual number of the array elements, so that will come in handy at some point.

You can't make an empty array in C++.

As well arrays in C++ can NEVER CHANGE SIZE.
That concept will seem very alien if you come from higher level languages such as PHP, Python or AS3, but arrays cannot change size in C++. If you make an array of 10 integers then it will always be an array of 10 integers until it is de-allocated.

So, so long as you know for a fact you are giving that macro an array it will always work.

Interesting. I suppose you could always create a larger (or smaller) array, move the elements to that array, and de-allocate the first array. You'd just have to watch out for overflows if you're moving to a smaller array.

The compiler never sees that code. The pre-processor handles it, and then afterward the result is sent to the compiler.

Okay, fair enough, but what exactly does the pre-processor see in that? Is writing code for it like a whole different language, or what?

At 6/28/12 01:39 PM, egg82 wrote:
Declaration and definition seem awfully redundant in C++, then. You already created and assigned your variables above, then did it again in the constructor.

It's not redundant, that's how it works. First you need to tell the compiler what the thing is, then you tell it what it does.
You're probably just too accustomed to high level languages like AS3 where you would just make a constructor like this:

class MyClass
{
public function MyClass():void
{
// ...
}
}

But remember that, although C++ and AS3 do share some similarities, they are worlds apart.
Here's an example of a class that is implemented using a header and source file, the way C++ should be written:

You declare the class in the header file, and then define it in the source file.
If you were to create this class into a library then the .CPP file would be turned into a .LIB file and the .HPP file would be used in conjunction with it.

So if you ever download a library for C++ you will get a bunch of .H/.HPP files and .LIB files.
The headers will contain the declarations, and .LIB files the definitions.

At 6/28/12 01:39 PM, egg82 wrote:
That's what I was talking about. I forgot that I learned about passing by reference (and the actual benefits), so I thought that in C++ all I could do was pass by value (make a copy) or pass by pointer (integer copy of the memory address of the variable you want to change)

That's actually another example of when to use a reference. If you're just changing the value you should pass the variable by reference.
Passing by pointer can be useful, for example, if you wanted to find the "distance" in memory between the values.

Memory positions are just the numbers 0 to a maximum of 4294967296 on a 32bit platform, and 0 to a maximum of 18446744073709551616 on a 64bit system (64bit computers can use a lot of memory).
So if you want the "distance" between two pointers you can simply do this:

At 6/28/12 01:39 PM, egg82 wrote:
Interesting. I suppose you could always create a larger (or smaller) array, move the elements to that array, and de-allocate the first array. You'd just have to watch out for overflows if you're moving to a smaller array.

That is precisely how you would make a dynamically resizing array in C++.
It's also how the vector container works. Although, the vector container will never shrink; it only grows.
Personally I find that to be kind of stupid, especially since the only way to actually de-allocate a vector's contents is kind of hacky:

The swap method does exactly what it sounds like: it swaps all contents of the vector with the one that it passed to it.
So if you pass an empty vector (which is created via its constructor) the contents are copied into said empty vector, and the empty vector's contents are copied into vec (in other words: vec is now empty).

Since the value of the empty-constructed vector was not stored in a variable it is de-allocated, and the memory allocated by the 10 integers is freed.

Sorry if I didn't explain that well. :)

At 6/28/12 01:39 PM, egg82 wrote:
Okay, fair enough, but what exactly does the pre-processor see in that? Is writing code for it like a whole different language, or what?

It just looks for macros that are pre-fixed with the # symbol and perform the necessary actions on the text of your code.
It does literally nothing but alter the plaintext that you type out before it's compiled.

It sees that you defined values for INT_TYPE and FOURTY_TWO.
So anywhere you typed the literal text "INT_TYPE" it will replace that with :int". Anywhere you typed the literal text "FOURTY_TWO" it will replace it with 42.

Note that it's smart enough not to fuck up strings are or anything like that:

I just realised that saying the preprocessor "literally" only alters the plaintext version of your code was a little bit inaccurate/disingenuous.
It can do other things, but chances are you won't need to use them that way.

This article does a good job of explaining the preprocessor in detail.

Sorry about the late reply, i've been running around like a chicken with my head cut off since I learned we were choosing teams for the jam. So much to do, so little time! Good thing energy drinks were on sale today.

At 6/28/12 02:14 PM, Diki wrote:
It's not redundant, that's how it works. First you need to tell the compiler what the thing is, then you tell it what it does.
You're probably just too accustomed to high level languages like AS3 where you would just make a constructor like this:

So if you ever download a library for C++ you will get a bunch of .H/.HPP files and .LIB files.
The headers will contain the declarations, and .LIB files the definitions.

I probably won't be working with libraries just yet :P

That's actually another example of when to use a reference. If you're just changing the value you should pass the variable by reference.
Passing by pointer can be useful, for example, if you wanted to find the "distance" in memory between the values.

I don't see finding the distance as useful. I mean, if it was static, then maybe... Maybe... But memory addresses aren't static, so I don't see what's useful about knowing the memory address of a variable (besides changing it via a pointer)

That is precisely how you would make a dynamically resizing array in C++.
It's also how the vector container works. Although, the vector container will never shrink; it only grows.

Yay, I figured something out! xD

Since the value of the empty-constructed vector was not stored in a variable it is de-allocated, and the memory allocated by the 10 integers is freed.

So basically if you have a null variable, it de-allocates after the function ends?

It just looks for macros that are pre-fixed with the # symbol and perform the necessary actions on the text of your code.
It does literally nothing but alter the plaintext that you type out before it's compiled.

Note that it's smart enough not to fuck up strings are or anything like that:

I would expect it not to screw with strings :P

though i'm still not sure what the #endif and all of that really means. It seems like a whole new programming language to me.

public class newClass{
public var vec:Vector.<Boolean> = new Vector.<Boolean>;

public function newClass(){
vec = new Vector.<Boolean>;
}

It just seems redundant.

I don't know what else to tell ya man, that's just how C++ works.
You can't compare to AS3; it's comparing apples to oranges, it doesn't work.

Low level languages like C++ can often require you to do a lot of work to achieve a little.

At 6/28/12 05:26 PM, egg82 wrote:
I don't see finding the distance as useful. I mean, if it was static, then maybe... Maybe... But memory addresses aren't static, so I don't see what's useful about knowing the memory address of a variable (besides changing it via a pointer)

You're still new to C++ so you haven't learnt enough to really appreciate pointers.
For example, I'm assuming you haven't learnt about the new operator yet, or how arrays can be treated as pointers.

For example, you could calculate the number of elements in an array like this:

Of course that example doesn't serve any real purpose, but I'm just showing you how you can calculate the length of an array.
However when you allocate memory using the new operator it works pretty much the same way as an array (emphasis on "pretty much").

This specific topic is getting too complicated for someone just starting out with C++, but there you go.

At 6/28/12 05:26 PM, egg82 wrote:
So basically if you have a null variable, it de-allocates after the function ends?

No. Variables are de-allocated under two conditions:

1) They fall out of scope. For example, if you create a variable inside of a function, once that function ends the variable will be de-allocated, because the scope ends. Remember that your main is just a function, so when that ends, everything not already de-allocated will be.

2) When you use the delete operator on memory allocated with the new operator, but again, don't worry about that; if you're just starting out you don't need to learn this stuff yet.

A NULL variable has not been allocated; that's specifically what it means.
Think of it like null/undefined in AS3; you know what the variable is, but it hasn't been allocated and cannot be used for anything.

Having said that, there is something about NULL in C++ that you should understand: there's no such thing as NULL.
NULL in C++ is actually a #define macro that is actually just the number zero. Basically think of NULL as this:

#define NULL 0

When using pointers in C++ the integer 0 means "not allocated". The word NULL was created just to make a word that can be specifically used with pointers which makes code easier to understand.

At 6/28/12 05:26 PM, egg82 wrote:
though i'm still not sure what the #endif and all of that really means. It seems like a whole new programming language to me.

If the condition is true then the text inside the block is not touched.
If the condition is false then the text inside the block is removed.

At 6/28/12 08:15 PM, Diki wrote:
I don't know what else to tell ya man, that's just how C++ works.
You can't compare to AS3; it's comparing apples to oranges, it doesn't work.

Low level languages like C++ can often require you to do a lot of work to achieve a little.

Wow those first two sentences were poorly written.
What I meant to say was that comparing AS3 to C++ won't ever make sense because the languages are too different. They were created for entirely different purposes, and follow/allow entirely different paradigms.

I understand where you are coming from; C++ is a difficult language to learn, as well as wrap your head around.
Always keep in mind that AS3 is a very high level language; C++, while still comprising of high level features, is, in my opinion, a low level language; it will will always be more cumbersome and confusing by comparison.

You have to understand that C++ was made a long time ago and due to the way it works it has to make things this way.
A very simple example would be this:
Let's say you have a main.cpp that just prints hello world. This isn't a problem you can compile it as is and everyone is fine with that.
You start to build on this example and add a class, then another class etc until the source file gets too big and you start losing yourself in the code. Well when that happens you would ideally want to separate your code and have it in multiple files. This poses a problem because now that the classes are in other files, the compiler alone wouldn't be able to make a program out of that main.cpp because it won't be able to find the classes you used.
That's when the idea behind the extern keyword was born. Basically what happens is that you say somewhere in your code that you promise that sometime in the future some program will be able to find what's marked with extern, just not when it's going to get compiled into bytecode, so the compiler basically flags that piece as missing and then passes what comes out to the linker. So the compiler will spit out object files(that's what the .o files are) which are basically programs that are almost finished but are missing the part that you promised will be there sometime by adding extern. This is where the linker comes in. It takes all the .o files you give it and starts to fill in the gaps until you have an executable file at the end.

Now the next problem is that whenever you want to use your class somewhere, you will have to declare it as extern first so that you won't have troubles compiling it. It helps that the standard specifies that anything you declare will be treated as extern by default, but then whenever you'd have to use a class somewhere you'd have to write it all over again, all the functions and members so that the compiler knows that they will be there.

This is why you have .h files, #include will just replace that line with the actual contents of the file, so if you declare your class in a .h file you can then use #include to add all the definitions the compiler needs at once without having to remember where you put all of them in case you need to add a function definition.

Of course you still need to implement them somewhere, you could do that in the .h file by making the body of the function right after the declaration, but that would be inefficient because it would mean that the compiler has to process the same class over and over again for each appearance, so the preferred method is to have a separate file with the actual implementation of the functions.

If you think something is unclear do tell.
Also sorry if I missed anything

At 6/29/12 10:25 AM, everette00 wrote:
What you said did not indicate innocent curiosity; it was clearly smug and arrogant.

Which is why I ignored him.
That and the websites I make are for multimillion dollar companies whom would sue the fuck out of the company I work for if I posted links to their sites on a message board.

At 6/29/12 10:42 AM, Diki wrote:
Which is why I ignored him.
That and the websites I make are for multimillion dollar companies whom would sue the fuck out of the company I work for if I posted links to their sites on a message board.

At 6/29/12 01:57 PM, apocalypseven wrote:
And you wanted me to post my video game code, shame on you DIki.

No one asked you post any code pertaining to any projects you're working on. Only thieves do that - bad ones at that. What we're saying here is you should post C++ code that you're capable of writing. If you're so good, then you should have no problem whipping up some random code that shows your ability.

At 6/29/12 04:47 PM, apocalypseven wrote:
I am not a whore, I do not flaunt my pussy in public.

Nice expletive vocabulary. Do you always value yourself as highly as you do? I mean, there has to be a point at which you say to yourself, "I'm so full of it right now." I realize you're trolling, but I doubt that you have any aforementioned skills.

At 6/13/12 08:52 PM, apocalypseven wrote:
I'm using Actionscript 3 for the games, thanks for the tip for the conversion, but I'll use this dumbed down language for now, because if I use C++ now you thieves will jack my source code, LMAO.

You could have been a legendary troll in my eyes if you had stopped posting after this.

after 14 hours of sleep in 4 days, I am incredibly tired, so I will make this short.
Sorry, Diki, I really wanted to give a longer response and ask more questions.

I will learn C++ at some point (it's required for my major, anyway) so I figure it's not too terribly important that I start right now. I will finish learning AS3 first, and then I will learn C++ the way I do best.
How do I do that? I'm going to make a 3d multiplayer game as soon as I pick up a compiler. Yes, that really is the best way I learn. Jump in the deepest practical end and start asking questions the second I feel my feet hit water.

Anyway, sorry for the short response, g'night folks!

and i'm pretty sure apocalypse is a troll - though either somewhat unintentionally or one with a lot of time and patience, but i've seen quite a few of his/her posts, and he/she is no "ordinary" troll

At 7/2/12 03:20 AM, egg82 wrote:
How do I do that? I'm going to make a 3d multiplayer game as soon as I pick up a compiler. Yes, that really is the best way I learn. Jump in the deepest practical end and start asking questions the second I feel my feet hit water.

Don't do this. Trust me: you will not finish.
You have no idea how complicated 3D programming in C++ is. Combine that with how complicated socket programming in C++ is and you're in a for a world of trouble.

When I was in college, in my second semester, our final project was to make a basic 3D game; we had five people in our group, three of us programmers, two of us artists.
The five of us, after working our asses off for 3 months, didn't have much to show for it and our end result was an ugly, buggy pile of crap. And that was five of us going to college specifically for developing games with C++.

Here's some examples; this code does nothing but prepare OpenGL for rendering:

(Note: this will only work on Windows. The code will be completely different for Linux.)

So just trust me when I say to not attempt a multiplayer 3D game as your first C++ project.
Try something simple like a text-adventure game that uses the console (seriously; this will be more complicated than you think).

Don't try to run before you can walk; you will learn far less if you do that.

I don't really know what you would compare AS2 to, but other than AS2 being a C-like language it's not comparable to C++; they're too different. Plus ActionScript is a dialect of ECMAScript, making it even less comparable to C++.

AS3 certainly took some pages from the Java, so they are similar, but they're languages used for different purposes (with some exceptions, such as making games, which, in my opinion, Java sucks at).

At 7/2/12 02:06 PM, Diki wrote:
When I was in college, in my second semester, our final project was to make a basic 3D game; we had five people in our group, three of us programmers, two of us artists.
The five of us, after working our asses off for 3 months, didn't have much to show for it and our end result was an ugly, buggy pile of crap. And that was five of us going to college specifically for developing games with C++.

speaking of college, I finally signed up for the beginner's C++ and beginner's Javascript for the fall semester. Wish me luck! o.o

At 8/2/12 06:42 PM, doodle-bread14 wrote:
Most of the users (like Diki and egg82) are trying the best they can to fully answer any of our questions. So get your dirty ass out of here and troll at those threads that deserve trolling!

well, only some of the thread was dedicated to "clawing at eachothers' faces"
the rest of it was real learning.

besides, I wasn't exactly answering a whole bunch of questions; just asking a whole bunch.
Thank Diki for pretty much all of the answers O.o

How's C++ going? What have you learned so far?

haven't started yet. I'm pretty much still in the same boat I was in before.
I have a feeling that I chose correctly when I decided to only take two classes this semester. It seems that learning C++ and Java at the same time may be a bit of an overload by themselves.