Issue with static libraries

[Ep1cM1n10n]

im making a static library and I have done everything correct to my knowledge, i don't know why its not working... The error is
'BinToText': is not a member of 'Convert'
'TextToBin': is not a member of 'Convert'

The Code

namespace Convert
{
	class Convert
	{
	public:
		string a;
		string BinToText(string a);
		string TextToBin(string a);
	};
}

[salem c]

Did you implement the functions?

Did you get the namespace right?

This compiles for me.

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

namespace Convert
{
    class Convert
    {
        public:
            string a;
            string BinToText(string a);
            string TextToBin(string a);
    };
    string Convert::BinToText(string a) {
        return a;
    }
    string Convert::TextToBin(string a) {
        return a;
    }
}

int main ( ) {
    Convert::Convert foo;
    string b = foo.BinToText("hello");
}

Where does "static libraries" come into this?
What's in the library, how did you create it, how are you linking with it?

[Ep1cM1n10n]

This is a static library i'm making in visual studio. https://pastebin.com/0m3fTt8P here is the code for the .cpp that calls the .h to set what BinToText and TextToBin do when called by other files. It gives the error
'BinToText': is not a member of 'Convert'
'TextToBin': is not a member of 'Convert'
when i compile.so i did something wrong with the .h file https://pastebin.com/DAf7XwTv
im trying to fix that error

[Ep1cM1n10n]

to create it i just selected static library in visual studio

[Ep1cM1n10n]

im linking it by typing
#include "Convert.h"

[E0p9LyTq]

Look real close at the order you include your headers, you are including your custom header before you include any of the C++/Visual Studio headers.

It should be:

#include <stdexcept>
#include <string>

using std::string;

#include "Convert.h" 

Put your custom header as the last include and if you've set up your VS solution correctly to create a static library it should compile cleanly. VS 2017 Community is what I use.

With that said, /mini-rant on:

I don't use precompiled headers, so no need for that PITA #include "stdafx.h" .

using namespace std; will potentially cause you problems later. Saving a couple of keystrokes now will end up giving you endless hours of unneeded conflicts when your programs get larger and you use 3rd party libraries.

If you don't want to constantly type std:: use the more restrictive form of using that I, erm, used.

Personally I don't bother with using statements, I prefer always typing std:: and it is a habit that doesn't require any thought.

/mini-rant off

[Ep1cM1n10n]

That fixed it, thanks! im kinda new but hey i know a decent amount. Thanks again!

[MikeyBoy]

FurryGuy wrote:

Look real close at the order you include your headers, you are including your custom header before you include any of the C++/Visual Studio headers.

It should be:

#include <stdexcept>
#include <string>

using std::string;

#include "Convert.h" 

I'm gonna have to disagree with that. Your header file should not have to depend on other header files being included before it is including.

If your header file depends on <stdexcept> and <string> (or any other header file), then it should include those files itself.

[E0p9LyTq]

@MikeyBoy, he originally had "Convert.h" before the other headers. That is what I was addressing because his Convert class uses std::strings. Without including <string> before using them doesn't that give an error? Yes, it does.

If your header file depends on <stdexcept> and <string> (or any other header file), then it should include those files itself.

That is a different discussion, whether to include headers in header files. The OP didn't do that, so the ordering of the included headers becomes a critical factor.

[MikeyBoy]

Yes, I understand what the original problem was. I'm disagreeing with your proposed solution.

The solution is to modify "Convert.h" so that it includes its own dependencies, such that it can then simply be included in a source file without having to worry about whether those dependencies are already included in that source file.

This has been standard practise in the entire time I've been developing in C and C++. You are the first developer I've ever encountered who has advocated that it shouldn't be done, and that, instead, it should be the responsibility of the including source file to include all the dependencies.

EDIT: I'm curious - why do you advocate this approach? What advantage do you think it has over the more usual approach? Because I can see clearly the advantages of the usual approach.