The problem seems to be the 'namespace' keyword in your header file - try to move it to the main cpp file, e.g.

// Main File
#include <iostream.h>
#include <cstdlib>
#include "cardClass.h"
#include "deckClass.h"
#include "handClass.h"

usinf namespace std;

When I do that I have problems with string not being recognized.

"c:\euchre\cardclass.h(32) : error C2146: syntax error : missing ';' before identifier 'toString'
c:\euchre\cardclass.h(32) : error C2501: 'string' : missing storage-class or type specifiers"

I then tried to #include <string> in the main cpp file, but had the same problem..

What about putting it at the beginning of the file before anything gets included (I'm pretty sure it's a namespace problem)

I tried that too, and it didn't work.. I'm sure that it is a namespace problem.. I just can't fix it! :-)

I tried that too, and it didn't work.. I'm sure that it is a namespace problem.. I just can't fix it! :-)

FYI:
By the way, you should use the following includes:
#include <iostream>
#include <string>

In the code you posted, you're using iostream.h.
Your code is mixing two different types.
According to ANSI C++ standards a compiler can support two types of headers for the STL classes.  The (*.h) type and the (*) name-by-itself.
The *.h type globalizes the functions, which means you don't need std namespace.
The (*) isolates the functions within the std namespace.

The standards recomend that you use the (*) type.

thanks, adding std:: in front worked..

>>I tried that too, and it didn't work.. I'm sure that it is a namespace problem.. I just can't fix it! :-)

Did you do it to both ostream's?
If you only did it to one, the compiler will still give you an error.
I just tested it, and when I remove the std::, I get the "C2872 ambiguous symbol" error.
But when I add the std:: to BOTH ostream's, the error goes away.

Now with that working it isn't recognizing the << operator!  "error C2678: binary '<<' : no operator defined which takes a left-hand operand of type 'class ostream_withassign' (or there is no acceptable conversion)"

Any ideas?

Now with that working it isn't recognizing the << operator!  "error C2678: binary '<<' : no operator defined which takes a left-hand operand of type 'class ostream_withassign' (or there is no acceptable conversion)"

Any ideas?

Your code was bugging me because I didn't understand why you where getting the error.  So I did a little checking.
I think I know why.

If you have one file with #include <iostream.h>
And another file with #include <iostream>

If you use "using namespace std; ", your compiler is not going to know which ostream to use.

That will give you the "error C2872: 'ostream' : ambiguous symbol"

I recomend that you go through all your files, and make sure they're all using the same type of STL headers.

This should also fix the "error C2678: binary '<<' :" error.

>> I recomend that you go through all your files, and
>> make sure they're all using the same type of STL headers.
There is only one type of STL file.

The files that include extensions, like <iosteam.h> and <vector.h> are old legacy files that VC continues to ship so that old programs can still compile without changes.  However there are old non-standard files and you should not use them for new projects--for reasons that I woudl think are obvious.

From a different question

The official STL (Standard Template Library) files are all extensionless files, like <iostream>, <vector>, and <list>.  You may find that your compiler has files with these names but a .h extension, like <iostream.h>, <vector.h>, and <list.h> but these are not the standard files.  These files are old, non-standard files that are provided for compativbility for old programs that used them before the standard files were settled upon.  You want to avoid usign this files if you have the standard ones availalbe.  The non-stnadard files may not have all the features of the standard ones, they also likely to have more bugs and other problems, and also since they are not standardized, they will varry from compiler to compiler, and might not even exist on many compilers.  So avoid using these files if you have the extenionless, standardized files.

Now there is one big difference between the standardized files and many of the non-standardized files.  The standardized files place all of their symbolic names in the "std" namespaces.  This is so that the names defined in these files don't clash with names you write in your program.  So in order to access the names inside the standard STL files you need to prefix them with "std::" like

std::vector<std::string> StringArray;

If you do not wish to use those "std::",  you can instead add a using directive like

using namespace std;

after you include the STL  .h files.  Then these names will all be brought into your namespace.

>>there are old non-standard files

Wrong answer again.  These files are part of the current standard.  The standard however recomends using the extensionless.
Please read the standard.  If you need me to give you the section, let me know.

>>The official STL (Standard Template Library) files are all extensionless files

Also wrong.  Please read the standard.  

nietod,
If you would have read all the comments you would have notice that I already let him know that the extensionless method is the recommended approach.

Of course I have no problem with you reiterating the same thing I already posted, but when you copy and paste my comments in to yours, and then try to correct my comments, you should at least verify that you’re correction is correct.
If you don’t know, you shouldn’t correct someone else, or at least you should say, “this is what I believe”, so that the questioner knows you’re not speaking factual.

>>many of the non-standardized files.  

If you're referring the extension files (which are part of the current standard), the difference you posted exist not just for many, but for all.
That is stated in the standard.

The following is a Quote from the standards:
The ".h" headers dump all their names into the global namespace, whereas the newer forms keep their names in namespace
std. Therefore, the newer forms are the preferred forms for all uses except for C++ programs which are intended to be strictly com-patible
with C.

NJordan72,
Sorry we got your question involved in this.  nietod likes to go around correcting experts, and he's cought me with my foot in my mouth a couple of times, so I'm certainly not blameless.
So of course when I catch him putting his foot in his mouth, I like to take the oppurtunity to give him some verbal bashing. :-)

>>  If you need me to give you the section, let me know.
Definitely.  i don't see them listed anywhere.

They do discuss the depreciated C headers, but of course none of these have STL in them.

>>  I already let him know that the extensionless method is the
>> recommended approach.
But my point is that the other approach is not "unrecommended" It is a mistake.  There is a differrence.  

>>  when you copy and paste my comments in to
>> yours, and then try to correct my comments, you
>> should at least verify that you’re correction is correct.
If you can show me its wrong you definitly have my appology.  But I don't see it and now and i don't recall it from the past.    And I have actually read the standard one or two or a dozen times.  

>> The following is a Quote from the standards:
Yes it is.  And it is taken completely out of context.  It applies to the standard C files, not the C++ library files.  There are no .h versions of the C++ library files.

Read it again.  It s foot note.  make sure you read the text it is footnoting.  That quote applies to the C90 standard library files only, in particular

  <assert.h>   <iso646.h>   <setjmp.h>   <stdio.h>    <wchar.h>
      <ctype.h>    <limits.h>   <signal.h>   <stdlib.h>   <wctype.h>
      <errno.h>    <locale.h>   <stdarg.h>   <string.h>
      <float.h>    <math.h>     <stddef.h>   <time.h>

>> So of course when I catch him putting his foot in his mouth, I like
>> to take the oppurtunity to give him some verbal bashing. :-)
Bashing is not called for.  But yes you did correct me at least once.  On the depreciated string stream class.

>>Yes it is.  And it is taken completely out of context.  It applies to the standard C files, not the C++ library files.  There are no .h versions of the C++ library files.

I can't believe you said that.  First of all, it's an ANSI C++ standard, not a C standard.  Second, the text clearly shows that it's referring to C++.

I'm not sure what you're reading into it.  But anyone can figure out that they're referring to C++ programs, and it makes a point of stating that if it's a C++ program that needs to be C compatible, to use *.h files.

The standards clearly are not support your statement.
It seems like you're trying to twist it to make it into what you belieave.

>>That quote applies to the C90 standard library files only, in particular

That quote is listed under section 17.4.
Quote:
Section title : Using the library
1 This subclause describes how a C++ program gains access to the facilities of the C++ Standard Library.


Hmmm... That does sound like anything in that section applies to the C++ standards.
Hmmm... Also looks like it referring to STL.

If you've read the C++ standards twice, maybe you should read it again.

To tell you the truth, I haven't read the standards completely, and I only reveiw it when I'm porting code from MFC to unix.

I do deal with a lot of different compilers, which forces me to choose code that I know is compatible with them all.
You'll find the extensionless vs extension standard on VC++, compaq c++, rational rose C++, Apex C++, and g++.
Reading the documentation on the compaq c++ compiler is what first clued me in to the fact that this is part of the standards.  In its documentaion it referred to the standards as justification for extensionless vs extension difference.

Now they could be wrong, and I could be wrong, but I don't think so.

>>On the depreciated string stream class
I already forgotton about that, and I never thought it was a big deal.

What I really thought was a big deal was the one time you told someone that their #if defined was wrong, and that they had to change it.
And then you acted supprise when I told you it was part of the C++ standard.

And I don't think the issue on the extension STL header's are a big deal, but I've seen you make a simalar statement about these extension headers on other questions, and it's just not true.

STL Extension headers are part of the standards.  It's just not recommended unless you need C compatibility.

Please post the quote that says that there are any .h STL files?

>> First of all, it's an ANSI C++ standard, not a C standard
The quote you posted so far only applies to the C library.   It says that in the standard.  To be exact it says

  17) The ".h" headers dump all their names into the  global  namespace,
  whereas the newer forms keep their names in namespace std.  Therefore,
  the newer forms are the preferred forms for all uses  except  for  C++
  programs which are intended to be strictly compatible with C.

Do you see that 17?  it indicates that the text is a footnote.  It is a footnote for paragraph

7 Subclause  _depr.c.headers_, Standard C library headers, describes the
  effects of using the name.h (C header) form in a C++ program.17)

See.  That is why I said the quote applies to the C library files.  Technically it is the C90 library files.  Now what are these depreciated C headers?  Take a look at

  1.5  Standard C library headers                       [depr.c.headers]

1 For compatibility with  the  Standard  C  library,  the  C++  Standard
  library provides the 18 C headers, as shown in Table 1:

                            Table 1--C Headers

      <assert.h>   <iso646.h>   <setjmp.h>   <stdio.h>    <wchar.h>
      <ctype.h>    <limits.h>   <signal.h>   <stdlib.h>   <wctype.h>
      <errno.h>    <locale.h>   <stdarg.h>   <string.h>
      <float.h>    <math.h>     <stddef.h>   <time.h>

Those are the only standard files that have .h extensions listed in the standard.  needless to say <stream.h> is NOT listed.  

Can you find a place where stream.h is listed?  Or any part of the standard that suggests it is standard?  

>> I do deal with a lot of different compilers, which
>> forces me to choose code that I know is
>> compatible with them all.
Well stream.h certainly is not.  It is not even listed as depreceiated in the stadnard.  Not that I can find.  And if it is depreciated, why do some compilers not ship it?  metroworks doesn't.

>> And then you acted supprise when I told you
>> it was part of the C++ standard.
I was surproised that #if was part of the standard?  I don't think so.  I may have said that it was innapropriate to use it for something.  But that is very different.

>> STL Extension headers are part of the standards.
There are no STL extension headers.  Unless you can find something in the standard that indicates otherwise.   And if there are STL extension headers, how come there is almost never (probably never) an <algorithm.h> <set.h> <stack.h> etc?  Why would only some STL files be singled out?  The ones that just happen to be older?

https://www.experts-exchange.com/jsp/qShow.jsp?ta=cplusprog&qid=11970839

Seeing how I can't even get you to admit you're wrong in the above quuestion, I would obviously be wasting my time here.

So to save us both from wasting time, I'll sign-off this thread too.

Axter, I am not wrong int he above question.  That is VERY basic stuff.  I am also not wrong here.  Can you find anything to contradict me?