making a class

I see a lot of different conventions on the net when it comes to making
a class. Currently I make a class in a single .cc file like:

#include <string>
#include <iostream>
using namespace std;

class List {
private:
string name;
int id;

public:
// edit name
void setName(string newname);

// get name
string getName();

};

void List::setName(string str){
List::name = str;
}

string List::getName(){
return List::name;
}

int main(){
List mylist;
string newname = "Bo";
mylist.setName(newname);
string pp = mylist.getName();
cout << "sdfsdf \n" << pp << '\n';

return 0;
}


But is it better to leave implementation of the functions in another
file and keep the private/public sections in a .h file?

On Apr 23, 12:25 am, Johs <a...@asd.comwrote:Up to this point, you can insert the above lines to a header file
namely List.h.
The function bodies should be located to the .cpp file namely
List.cpp

The main function should be located in main.cpp file. By this way, you
can easily insert or remove any precompiled files just only using
#include.

bohemistanbul wrote:Ok, should there only be one class per header file or is it ok to
declare multiple classes per header file?

Another thing I have read that the extern keyword can be used. I have
omitted this so far and it works fine, is extern just an optional
keyword to make it more clearer if a variable is implemented somewhere else?

Johs wrote:There aren't any fixed rules, but one class per file keeps things short
and makes it easier to reuse the class.
The extern keyword is required for a variable declaration (extern int
foo;) where the variable is defined in a single compilation unit and
used elsewhere. It is optional for function prototypes.

--
Ian Collins.

bohemistanbul wrote:
Ok, should there only be one class per header file or is it ok to
declare multiple classes per header file?

Another thing I have read that the extern keyword can be used. I have
omitted this so far and it works fine, is extern just an optional
keyword to make it more clearer if a variable is implemented somewhere
else?

Johs wrote:You asked this half an hour ago.

--
Ian Collins.

Johs wrote:
....I think one class per header would create far more complexity than there
needs to be.

One header per "interface" make better sense to me. e.g. if you're doing
a thread pool interface, then all the classes that are needed for the
thread pool should be in the same header. It would make little sense
though to have an interface for logging and another interface for fast
fourier transforms to be in the same header.

There used to be a desire to keep headers smaller because you could
eliminate compiling code that was never used, however, this is no longer
really an issue.

The real answer to your question is "whatever makes you and your clients
most efficient".

Johs wrote:Many people have the misconception that a header file is a file
where you dump all the type and function declarations used by a
cpp file, regardless of whether those types/functions are used
anywhere else.

However, a header file declares the *public interface* of a module.
In other words, it declares types and functions which other modules
may need.

As with all public interfaces, they should contain as little
implementation details as possible. (Due to technical reasons the
private sections of classes have to be declared alongside their
public sections, but that's more or less unavoidable.)

If the implementation of a module (ie. the "cpp file") uses a
very small class, used exclusively by that module, there's often
no need to make that "public" by creating a header file for it.

Of course if that private class is bigger it will start cluttering
the cpp file if you keep it there. If that's the case, then you might
want to put it in a separate file and make a header file for it. It
all depends on how much clutter you avoid by doing that, I suppose.

(Sometimes, if the class is very small and all of its functions are
also very small, one option is to put the entire class, implementation
and all, in the header file, with all the functions declared inline.
This shouldn't be abused, though.)

Ian Collins <ian-news@hotmail.comwrote in message ..."A.D.D." and programming don't mix well! <G>

--
Bob R
POVrookie