[ICODE]return 0;[/ICODE] might be a good idea, no?
That requires you to fix the return type of function, though.
And you need to fix the the return type of main too, because it always must be int anyway.

[QUOTE=;][/QUOTE]
Yes, you need the header queue.

[QUOTE]I'd love to believe you but AD is stating otherwise.[/QUOTE]
No. I think your main problem is that you tend to misinterpret things people say - it's probably the same with your instructor.

[QUOTE="nbaztec"]I mean if we can just use const in C, then why use #define, off the top of my head, is it due to this?[/QUOTE]
Not at all, both variants are perfectly legal in C. In fact, you can even use non-constants as the array size since C99.
That #define is still used is probably because bad habits die slowly - const was added to C in 1990, but the language had been existing for quite a while until then.

nbaztec commented: Informative. +1

The relevant part of the C standard is in 5.1.2.2.1:
[QUOTE]The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int
[/QUOTE]

C does not have inheritance, so obviously there is no dynamic_cast either.

There are references in C++, but not in C.

Yes, constants are indeed often realized through macros in C, although const exists just like in C++.

Yes, C does not support default arguments or any other function overloading for that matter. C++ does.

Explain what?

You're meant to only access the top element of a stack, so std::stack provides no way to iterate over its elements.
But you could keep removing elements from the stack until you find the value you're looking for or the stack is empty, then push all elements back on the stack (possibly excluding the one you found, if any).

The error message says it all.
ApplyRoll expects seven arguments, but you're just passing one.

[QUOTE]but im not using numbers or vectors im using strings and arrays look ill post the question it might be helpful [/QUOTE]
What difference does that make? std::sort isn't restricted to vectors or numbers.

The code line I posted is the "code outline".
I'm talking about this sort:
[url]http://www.cplusplus.com/reference/algorithm/sort/[/url]

This assignment sounds very familiar...
anyway, why do you think you need to change the function?
std::string overloads operators <, == and >, so it should work without any changes.

Do you have to implement the sorting algorithm yourself?
If not, a
[code]sort(name,name+SIZE);[/code]
does the trick (needs the header algorithm).

Hm, sure doesn't look much like selection sort...
I particularly don't get what the checks for -1 are supposed to do and what ptrinput is for.

Selection sort can be done simpler and in-place (i.e. without an extra array):

[CODE]#include

include

using namespace std;

int main()
{
int numberCount;
cout << "How many numbers to sort? ";
cin >> numberCount;

vector input(numberCount);
for (int i=0;i<numberCount;i++)
{
cout << "Enter number #" << i+1 << ": ";
cin >> input[i];
}

for (int i=0;i<numberCount;i++)
{
int bestIndex=i;
for (int j=i+1;j<numberCount;j++)
{
if (input[j]<input[bestIndex])bestIndex=j;
}
swap(input[i],input[bestIndex]);
}

cout << endl << endl << "Final result:" << endl << "----------------------" << endl;
for (int i=0;i<numberCount;i++)cout << input[i] << endl;
}[/CODE]

tundra010 commented: +1 +2

This should be in Hardware Software/Linux and Unix/Getting Started.
Most Windows programs run fine when you have Wine installed. However, some show problems that are not present when running on Windows and some don't work at all.
See the Wine AppDB entry for your software (assuming it's what you mean):
[url]http://appdb.winehq.org/objectManager.php?sClass=version&iId=14218[/url]

Seems like it runs okay.

Perhaps you should explain the sorting algorithm you had in mind, because it isn't really obvious.

In the meantime, I have lots of comments about the code:
Line 7-9: Make sure to use descriptive variable names. A proper name for "a" could be arraySize or numberCount. b and temp aren't needed, because...
Line 15-16, 26-27: ...you can input a number directly without using a string (cin >> a)
Line 8-9; No need to initialize string explicitly with an empty string literal, string b; does the trick
Line 19-20: The array size must be a constant known at compile-time, so this is not valid standard C++. Replace this by vector input(a); (same for sorted) - you need to include the vector header for this.

In various lines: don't use NULL for integrals, that's confusing. NULL is just a define for 0 - and if you use NULL at all, it should only be used to indicate a null pointer.

You should have received login info for your server when you purchased it.
If the server runs Linux, you can login to a remote shell via SSH.
If it runs Windows, I believe the "remote desktop" tool is the preferred way to access your server.

To copy files on your server (Linux), use scp/WinSCP or mount the server's file system directly.
I'm sure there are simple ways to copy files remotely on a Windows server too. If in question, just upload your program somewhere and download it on the server.

You can't just listen on a foreign IP address - the address must be one of your own network addresses, i.e. one that your computer is connected to the network with.
If you use say, an address of a Google server, it won't do you much good: the internet routers will route all packets to the Google server, but never to you. Same for the webhost service - the messages will always be sent to the webhost server.
So in order for this to work, your program needs to run on [i]their[/i] server. You can simply rent one (virtual servers are usually quite cheap) or you can be the server yourself - then you'll need to connect to your own IP address. If you have a router, you'll probably need to add a port forwarding rule.

What?

aType is neither an English word nor a C++ keyword.

I'm sure it has. You're having an out-of-bounds array access somewhere.
Have you run this with valgrind yet? It can discover invalid memory accesses in some cases.

Because undefined behaviour can result in pretty much any behaviour, especially if it involves invalid pointer accesses.

Yes, there's an error in your code.

To read in a file, you can use ifstream:

[CODE] ifstream file("filename",ios::binary|ios::ate);
if (!file.is_open())return 1; /failed to open file/
const int fsize=file.tellg();
file.seekg(0);

unsigned char buffer[2000];
file.read((char)buffer,fsize);
if (file.fail())return 1; /
failed to read file*/[/CODE]

To convert the strings into numbers, you can use stringstream or just use ifstream directly (then reading the data into the buffer would be pointless though).

About the edit boxes... is VC++ a RAD environment? Or in other words... can you select components like text boxes and insert them into your window?

Some suggestions for improvement:

  1. No point importing every element manually from the std namespace. An "using namespace std;" does the trick. While you shouldn't just go and import every namespace you find (that would defeat the purpose of namespaces), it's fine for the std namespace. Library designers can generally be expected to avoid clashes with the C++ standard library and this works well in practice - you'll rarely (if ever) encounter problems with other libraries.

  2. Where are all the headers? Are you including them in stdafx.h?

  3. No atoi! stringstream can be used here for conversion as well - but that is not even necessary. You can read an int directly from cin.

  4. Instead of incrementing loopLimit, you can just use x<=loopLimit as the condition in the for loop.

  5. There's no point in passing simple types like int/float/pointers etc. by reference. This is just more typing work and does not improve performance (or can hurt it, when no inlining can be performed). Constant references should be used for types that are rather expensive to copy in comparison (e.g. string) and for uncopyable types.

Yes, that should be an appropriate solution.
The task says that the setw argument shouldn't need to be changed manually when i grows - and your solution does just that.

You only have the parts of the code where vectors are passed to functions and where they are being created. I don't know how much code there is, but it might be worth it. Using vectors automatically takes care of memory management and allows for easy resizing if necessary.

If you use new[], then make sure to use delete[] instead of free to delete your 2D array.

You shouldn't use malloc at all. This is how you do it properly:
[CODE]s_cell* cell=new s_cell[MAP_X];
for (int x=0;x<MAP_X;x++)cell[x]=new s_cell[MAP_Y];[/CODE]

Even better is the following:
[CODE]vector<vector > cell(MAP_X,vector(MAP_Y));[/CODE]

Here's a good tip to fix your range problem:
[url]http://www.cplusplus.com/reference/clibrary/cmath/fmod/[/url]

That'll work reliably even with a low limit.

empror9 commented: big thanks +1

The taylor series just gets you an [i]approximation[/i] of the real value when doing 20 iterations. The result -0.00000361132 is very close to zero, though. The result I'm getting is even closer.
If you want more precision, use double instead of float.
Then the function will give you exactly the same result as the "real" cos function (0.000000026795).

[QUOTE=empror9;1286497]i tried the function but it's not correct :([/QUOTE]
What makes you think that?
It's correct.

[QUOTE=empror9;1286492]it's me with the same nick name 'empror9'[/QUOTE]
I'm aware, but that's a correct solution for the cos approximation.