So just as a reminder to the OP, but a struct is a class in C++, only difference is default visibility level, struct = public, class = private

Heh, this was my first answer-reflex, too. However, on closer inspection, that's not what the OP is asking. The question is not whether there is a difference in having member functions in a struct or class, but rather whether there is a difference between

struct foo{....};
void func1(foo* f);
...
void func2000(foo* f, type bar);

and

class foo
{
    ....
public:
    void func1();
    ...
    void func2000(type bar);
};

Jeff8j: Did I understand that you are basically trying to write a C++ decompiler? Knoweth that this is a daunting endeavour, next to impossible.

Decompiling Java bytecode or such into a human-readable source file is easy (the language is kind of specifically made for that, too). Decompiling C or C++ is harsh. While it is certainly possible to identify things as function prologs and such, there is no way of determining a meaningful variable name of any kind, or a function name (unless these are exported as symbols), no way to reproduce something like template instantiations into something that even vaguely ressembles the original, and no way to restore variables (or sub-expressions) which have been eliminated by compiler optimizations.

In one word, it's pretty much a nightmare...

Still the answer to that question is no, effectively this is what a member function does, its first param is the this pointer. So it comes down to how the structure is passed in those functions. If it is by value it is more expensive, because of the copy of the structure, pass by pointer or reference on the first argument to the function it would be the same as a member function.

lol well I know it probably not the right way of doing this but im making a x86-64 disassembler to c++/other languages and first it has alot of instruction codes then it will need to convert to a byte code then im shooting for c++ and javascript output c++ will be one thing but javascript is a completely different story.

I will do like swiftcoder mentioned and break it into different classes but just wanted to know what would happen with alot of functions in one class even say the disassembler to bytecode class will need a big switch and I was wanting to handle them in different functions so they can be over ridden and easily find able in a ide. I dont expect this to go anywhere just having my hand at learning more deeply about how everyting on the cpu gets done.

This is ridiculous. Don’t even break it into multiple classes, use data tables.
I’m the author of MHS (Memory Hacking Software) which has a disassembler and assembler.
http://memoryhacking.com/

Obviously whenever you have 2,000 methods on a class you are doing something wrong, but in this particular case it’s not a matter of breaking into multiple classes etc.; those methods simply should not exist at all, anywhere.
You need to build a data-driven parser using a table such as (partial code from MHS):

DIS_CMD g_cmdData[] = {
	//dwMask	dwCode		L,Bits	Ar1 Ar2 Ar3		ucType				DifopSize		DifAdd	Name			Desc
	{ 0x0000FF,	0x000090,	1,00,	NNN,NNN,NNN,	CD_CMD+0,			FALSE,			FALSE,	"NOP",			"No operation" },
	{ 0x0000FE,	0x00008A,	1,WW,	REG,MRG,NNN,	CD_CMD+0,			FALSE,			FALSE,	"MOV",			"Move [$1] (#1) to $0" },
	{ 0x0000F8,	0x000050,	1,00,	RCM,NNN,NNN,	CD_PSH+0,			FALSE,			FALSE,	"PUSH",			"Push $0 (%0) onto the stack" },
	{ 0x0000FE,	0x000088,	1,WW,	MRG,REG,NNN,	CD_CMD+0,			FALSE,			FALSE,	"MOV",			"Move $1 (%1) to [%0]" },
	{ 0x0000FF,	0x0000E8,	1,00,	JOW,NNN,NNN,	CD_CAL+0,			FALSE,			FALSE,	"CALL",			"Call near, relative, displacement relative to next instruction" },
	{ 0x0000FD,	0x000068,	1,SS,	IMM,NNN,NNN,	CD_PSH+0,			FALSE,			FALSE,	"PUSH",			"Push %0 onto the stack" },
	{ 0x0000FF,	0x00008D,	1,00,	REG,MMA,NNN,	CD_CMD+0,			FALSE,			FALSE,	"LEA",			"Store effective address for [$1] (%1) in register $0" },
	{ 0x0000FF,	0x000074,	1,CC,	JOB,NNN,NNN,	CD_JMC+0,			FALSE,			FALSE,	"JE,JZ",		"Jump short if equal/zero (ZF=1)" },
	{ 0x0000F8,	0x000058,	1,00,	RCM,NNN,NNN,	CD_POP+0,			FALSE,			FALSE,	"POP",			"Pop top of stack (@([ESP])) into $0; increment stack pointer (ESP becomes @(ESP+4))" },
	{ 0x0038FC,	0x000080,	1,WS,	MRG,IMM,NNN,	CD_CMD+1,			FALSE,			FALSE,	"ADD",			"Add $1 to #0" },
	{ 0x0000FF,	0x000075,	1,CC,	JOB,NNN,NNN,	CD_JMC+0,			FALSE,			FALSE,	"JNZ,JNE",		"Jump short if not zero/not equal (ZF=0)" },
	{ 0x0000FF,	0x0000EB,	1,00,	JOB,NNN,NNN,	CD_JMP+0,			FALSE,			FALSE,	"JMP",			"Jump short, relative, displacement relative to next instruction" },
	{ 0x0000FF,	0x0000E9,	1,00,	JOW,NNN,NNN,	CD_JMP+0,			FALSE,			FALSE,	"JMP",			"Jump near, relative, displacement relative to next instruction" },
	{ 0x0000FE,	0x000084,	1,WW,	MRG,REG,NNN,	CD_CMD+0,			FALSE,			FALSE,	"TEST",			"AND %1 with #0 (@(%1&#0)); set SF, ZF, PF according to result" },
	{ 0x0038FE,	0x0000C6,	1,WW,	MRG,IMM,NNN,	CD_CMD+1,			FALSE,			FALSE,	"MOV",			"Move $1 to [%0]" },
	{ 0x0000FE,	0x000032,	1,WW,	REG,MRG,NNN,	CD_CMD+0,			FALSE,			FALSE,	"XOR",			"$0 XOR #1 (=@($0^#1))" },
	{ 0x0000FE,	0x00003A,	1,WW,	REG,MRG,NNN,	CD_CMD+0,			FALSE,			FALSE,	"CMP",			"Compare [$1] (#1) with $0 (%0)" },
	{ 0x0038FC,	0x003880,	1,WS,	MRG,IMM,NNN,	CD_CMD+1,			FALSE,			FALSE,	"CMP",			"Compare %1 with [$0] (#0)" },
	{ 0x0038FF,	0x0010FF,	1,00,	MRJ,NNN,NNN,	CD_CAL+0,			FALSE,			FALSE,	"CALL",			"Call far, absolute indirect, address #0" },
	{ 0x0000FF,	0x0000C3,	1,00,	PRN,NNN,NNN,	CD_RET+0,			FALSE,			FALSE,	"RETN,RET",		"Return to calling procedure (@([ESP]))" },

You need an entirely different approach, and because of your brute-force method you will spend a very long time on this project, gaining virtually nothing from it as a programmer, and all-in-all stunt your growth. You are literally harming yourself if you continue this project.

I would suggest you make 1 or 2 very simple projects that allow you to familiarize yourself with aggregation lists as shown here and restart from scratch your current project. By the time you wrote the first 50 methods by brute force you could have finished the whole project via better knowledge of programming languages.


L. Spiro