I've got them to run as the tutorial shows fine, and went ahead and changed a couple of things. Everything works so far, but the next thing I'd like to do is get the message sent from the client (char buffer, I believe) to be changed into a string and communicated to another function, called secondaryCommand(), so that I can work with it further and incorporate it into the game. I can get WinServer.cpp to send basic integers to secondaryCommand(), but I can't get it to send the string it receives from the client I haven't eaten for 5 hours just trying to fix this, so I hope someone here knows what's going on.

Here's all of my code. Sorry it's kind of long. There are 3 pieces (Linkerfile.h, Secondary.cpp, and WinServer.cpp). I've highlighted the area in WinServer.cpp that's giving me a compiler error in blue.
I also attached all of the files to the top of this, including WinClient (if you'd like to try it out yourself and see).

Note: you'll need to add Ws2_32.lib for it to work, although I'm pretty sure you already know that. Sorry I'm pretty new to C++ and this is my first attempt at networking a program with a purpose. Thank you so much for helping (or just reading even).

Your code will actually be just fine if you eliminate every goto from your program, and never use one ever again...

Whether one believes that there is never a good reason to use a goto, or thinks that there are a few situations where they are acceptable, I think people will agree that from the looks of it you've become so reliant on them that you just cant write anything significant without them. That's a really bad place to be in. It's like being unable to afford insulation in your house because you have nothing left after paying the heating costs.

In my opinion, you need to decide to make a firm commitment that your practice of abundantly using gotos is history, and that from now on you will only even consider using a goto as a last resort, when even 1 hour of searching for alternatives cannot provide anything better. And that's for every time you even think of using one.
Without actually being there like a personal trainer to make sure you stick to such a goal, I can only hope that you succeed. Perhaps a goto jar (like a swear jar) would help.

This probably isn't the kind of answer you were expecting, but I am very much being serious here.

My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger

Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

Wow, not only is using goto a horrible idea. But using several goto-labels with the same name must be the epitome of poor coding. I tip my hat to you sir, you have reached unheard of levels of spaghetti code.

Have you by any chance had any "prior exposure to BASIC" ?

How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

The gotos were there originally from the tutorial link, and I left them because the program worked fine. When I added a few lines of code (the blue part) it suddenly decided it didn't want to compile anymore, which confused me since everything worked fine before. I know gotos are usually a bad idea, I was just confused why my program stopped working when I didn't think I altered anything that could mess with a goto.

As per iMalc's advice, I removed the gotos in the bottom section (the only section I've tampered with) and suddenly the code works!
Didn't think the solution would be so simple. I've never used gotos before, and now I definitely never will.
Thank you~

remove every use of goto. in main() you can replace every occurrence with return 0;

for SocketHandler(), you should use new instead of malloc to allocate space for the socket descriptor in main(), then after you pass it to SocketHandler(), you can use a std::unique_ptr<int> to wrap around the descriptor, which will automatically free it when the function returns. you can then replace all occurrences of goto in SocketHandler() with return 0;

The gotos were there originally from the tutorial link, and I left them because the program worked fine. When I added a few lines of code (the blue part) it suddenly decided it didn't want to compile anymore, which confused me since everything worked fine before. I know gotos are usually a bad idea, I was just confused why my program stopped working when I didn't think I altered anything that could mess with a goto.

As per iMalc's advice, I removed the gotos in the bottom section (the only section I've tampered with) and suddenly the code works!
Didn't think the solution would be so simple. I've never used gotos before, and now I definitely never will.
Thank you~

Oh that's a huge relief. Sorry I misjudged the situation.

Actually, now you mention it, I do recall finding an example about networking on Microsoft's site which used several gotos. I think my advice need to go to them instead.

My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger

Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

@Elkvis I'm glad to hear that simply replacing the gotos with 'return 0;' in main() would be the way to go. I got it working by doing that myself (after iMalc suggested to remove the gotos), but I wasn't confident it would be the best way so thanks for letting me know I wasn't wrong.
As for the other function with goto, I'm not confident I can easily switch malloc to new (I have almost no experience in regular C), but I'll try to look up some info on the internet so I can finally remove the remaining gotos with return 0s later. Thanks again for your help.

I went ahead and replaced malloc and free with new and delete, and the code runs perfectly fine (Thank you!!!). Now I can send buffer to Secondary.cpp and manipulate it (this is where my entire program will do its work, using the client's inputs and spitting out the results it should display back to the client's screen over the network). I haven't removed the gotos from the top section yet, since I'm not messing with the top yet, but I will as soon as I get this next small issue fixed (which is probably my last issue before I can start mixing in the game).

But now I'm having a new problem trying to get sString to be returned back to WinServer.cpp to be sent as buffer to go to the client program - I tried setting sString (a new string variable I made with Secondary.cpp) as a global string, and also tried converting sString to a char before sending it over, but in the end I can't get it to send.

This is the code area where I'd like sString to go into --> strcat_s(buffer, " <-- message from Server");
[I highlighted the area in my code in blue below]

Here's the code now: (Sorry this is so long)
Secondary.cpp

Code:

// Used as a middleman from Winserver.cpp to the game
#include "linkerfile.h"
#include <string>
#include <fstream>
#include <istream>
#include <iostream>
#include <stdio.h>
#include <stdlib.h>using namespace std;
int secondaryCommand(string sString)
{
cout << sString << endl; // just a temporary code to check and see if the Server can manipulate the data
sString = "If you see this message on the client, then everything works!";
return 0;
}

Actually, now you mention it, I do recall finding an example about networking on Microsoft's site which used several gotos. I think my advice need to go to them instead.

Looking at the implementation of SocketHandler, it seems that the idiom of using goto to jump to the clean up code was used. However, this was badly done in welcomeMessage, and then of course since this is C++, there was no need for this idiom in the first place since there is exception handling.

EDIT:

Originally Posted by Pikmeir

As per iMalc's advice, I removed the gotos in the bottom section (the only section I've tampered with) and suddenly the code works!

Unfortunately, by just removing the goto in SocketHandler without also duplicating the free(csock) and later the delete csock, you fail to clean up in one case. The goto in SocketHandler was a problem because you created a variable in the middle of the block, yet in terms of achieving the goal of keeping clean up code at the end of the function, the goto was fine. A better solution for this in C++ is to use a smart pointer or a container that can clean up after itself.

Last edited by laserlight; 05-02-2012 at 09:28 PM.

Originally Posted by Bjarne Stroustrup (2000-10-14)

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

But now I'm having a new problem trying to get sString to be returned back to WinServer.cpp to be sent as buffer to go to the client program - I tried setting sString (a new string variable I made with Secondary.cpp) as a global string, and also tried converting sString to a char before sending it over, but in the end I can't get it to send.

How does it not work?

I suggest that you stick to std::string, and then use its c_str() member function when you need a null terminated C-style string from it. Also, note that in your secondaryCommand function (what a useless name!), you assign to sString, but sString a parameter that will be destroyed immediately afterwards. Perhaps you intended to pass by reference?

Originally Posted by Pikmeir

I understand gotos aren't evil, but I see how they can easily screw everything up in a program. Either way, I'd much rather have a solid programs so I'll make sure I never start using gotos.

Then why do you still have goto in your program? I mean, I shake my head when I see that you incorrectly removed the use of goto when it had some value, but left the uses of goto when it provides no value over return statements (other than the notion of a single exit, which is kind of bogus in the face of possible exceptions anyway).

Originally Posted by Bjarne Stroustrup (2000-10-14)

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.