constructor compile problems

[VictorH]

This constructor in my class implementation file is producing compile errors:

PWServer::PWServer (const char* infile, const char* outfile, unsigned int max) : inputfile_.Wrap(infile), outputfile_.Wrap(outputfile),
maxusers_ = max, users_(max), numusers_(0), location_(0)

inputfile_ and outputfile_ are xstring objects (std::string with mods). xstring::Wrap is a proven working member function of xstring that converts c-strings into xstring(takes a const char* parameter).

maxusers_ is a const unsigned int

The errors:
./pwserver.cpp: In constructor âPWServer::PWServer(const char*, const char*, unsigned int)â:
./pwserver.cpp:63: error: expected `(' before â.â token
./pwserver.cpp:62: error: uninitialized member âPWServer::maxusers_â with âconstâ type âconst unsigned intâ
./pwserver.cpp:63: error: expected `{' before â.â token
./pwserver.cpp: At global scope:
./pwserver.cpp:62: warning: unused parameter âinfileâ
./pwserver.cpp:62: warning: unused parameter âoutfileâ
./pwserver.cpp:62: warning: unused parameter âmaxâ
./pwserver.cpp:63: error: expected unqualified-id before â.â token

Must a const unsigned int absolutely take a const for value, or can it be a normal unsigned int? I'm sure there are lots more mistakes - what do you make of it?

[Disch]

You cannot call member functions from an initializer list. You can only call other ctors. You also can't use the assignment (=) operator (technically you can weasel either of those into a ctor call -- but nevermind that).

Anything that is NOT a ctor must be called from the ctor body:

PWServer::PWServer(const char* infile,const char* outfile, unsigned int max)
  : maxusers_(max)                            // note:  no assignment operator.  Use the ctor
  , users_(max), numusers_(0), location_(0)   // all okay -- ctor calls
{
  // the rest is not a ctor, so must be done in the function body:
  inputfile_.Wrap(infile);
  outputfile_.Wrap(outfile);  // note:  outfile here, not outputfile -- was that a typo?
}

Must a const unsigned int absolutely take a const for value, or can it be a normal unsigned int?

It can take a normal unsigned int.

[VictorH]

That did it. Thanks Disch. Now that the compiler got past that, I have to work through the hefty collection of new errors...

Quick question: if classA uses a "helper" classB (which specifically exists for classA), is the normal arrangement to forward declare classB in classA's header file, with its details in classA's implementation file?

[VictorH]

Also -- this error:
./pwserver.cpp:68: error: no matching function for call to âstd::basic_ifstream<char, std::char_traits<char> >::basic_ifstream(fsu::String&)â

in reference to:
std::ifstream infs(inputfile_);

I've #included the .h file which #includes <fstream>. Shouldn't that work?

[Disch]

Quick question: if classA uses a "helper" classB (which specifically exists for classA), is the normal arrangement to forward declare classB in classA's header file, with its details in classA's implementation file?

I just wrote an article on this topic a few days ago

http://cplusplus.com/forum/articles/10627/

Short Answer: if you can get away with forward declaring -- yes, do it. Only #include if you have to. See that article for further details (specifically, section 4 "The Right Way to Include")

std::ifstream infs(inputfile_);

There is no constructor for std::ifstream that takes a fsu::String as its parameter. The ifstream constructor takes a const char*. You need to somehow get a pointer to the buffer your string class uses. Now I'm not familiar with this string class you're using, but with std::string it'd be the following:

std::ifstream infs(inputfile_.c_str());

The c_str() function returns a const char* pointer, which is usable by the ifstream ctor. You can try that with your string class, but if it doesn't work, then I can't have a solution for you without seeing documentation on the class you're using.

[VictorH]

Yeah, I was definitely trying to pass a string... Used c_str(). Compiler's still fussing though - I'll keep playing with it.

I've started reading your article -- very useful!