why am i getting mixed up strings when i am trying to append them end to end

[devonrevenge]

so i tried string = string + string +string

I dont the expected output in order

I have tried

output.insert(0,"\r\n PRIVMSG ");
output.insert(11,joined);
output.insert(strlen(output.c_str())," :");
                                     output.insert(strlen(output.c_str()),sendstring);
std::cout<<"\n-"<<output<<"-\n";

I have tried

string.append(this);
string.append(thenthis);
string.append(and then this etc)

But i still get a garbled mix of what i want.

so if I want this

string privatemessage = "\r\n PRIVMSG ";
string joined = "#chessplusplus";
string message;

output = privatemessage+joined+" :"+message;

and the output I get is this

:SG #chessplusplus

!!! !!! !

what in the bloody hell???

[Disch]

It's pretty straightforward.

string foo = "foo";
string bar = "bar";

string foobar = foo + bar;  // foobar == "foobar" 

The left of the + is the left of the joined string, and the right of the + is the right of the joined string.

string privatemessage = "\r\n PRIVMSG ";
string joined = "#chessplusplus";
string message;

output = privatemessage+joined+" :"+message;

since...
privatemessage == "\r\n PRIVMSG "
joined == "#chessplusplus"
message == ""

the final string is...
"\r\n PRIVMSG #chessplusplus :";

and the output I get is this
:SG #chessplusplus

That's not possible with the code you posted. Your code must be different.

Please post actual broken code.


EDIT:

in cases where the broken code is too large... do a smaller example code which reproduces the problem.

[vlad from moscow]

@devonrevenge

Instead of bla..bla..bla it is always usefull to present a simple program that demonstrates the problem that everybody could copy, paste, compile it and get the same result as you.
Usually when you are preparing such a program you can yourself find your mistake.

[devonrevenge]

The ouput is outputted from a paralel running thread in a switch statment

 case 2:
           mymutex.lock();
           ircsocket.send(output.c_str(),output.size()+1);
           std::cout<<output.c_str();
           mymutex.unlock();
           output = "";
           sending = false;
           break;
                                                                              

but everything else in the entire code really isnt relevant, it could be some option somewhere maybe, could it be including like a header file that changes things, like stdio or summink?

[o1vk4iN6]

If you are sending parts of the message through a network with packets, unless you are using TCP or some other protocal that guarantees the order of packets, you can get packets in a different order than they were sent or you might not even get them at all.

[devonrevenge]

just learned something about simplifying code...maybe this :

string output,privmsg="/r/n stuff",joined="#chessplusplus";
int b;

int main()
{
sfml thread (&sendfunction)

while(1)
{
//possibly irrelivant code (switch and if statments)
 if(certain conditions) 
 {
      if(//hit return)
      {
          output = privmsg+join+message;
          send = true;
          b = 2
  
    }
     if(1sending)
    {
       b =1
    }
   thread.launch()
 }
}

void sendfunction
{
switch(b)
  {
      case 1:
      mutex.lock()
      recieve()....
      mutex.unlock()
      break;
      
      case 2:
      mutex.lock() 
      send(output)
      mutex.unlock()
  }
}

[Disch]

Pseudo code really doesn't help. You need to give us an actual program that is broken in order for us to see what is broken.

vlad's suggestion is my suggestion as well. Make a smaller version of this program that does nothing but exhibits the symptoms you are seeing.

[devonrevenge]

This problem is really fascinating, It may take a better or more alert coder to find the problem suspect the cause is going to be subtle.

unfortunately I have been trying to recreate the problem to no avail (I have spent hours!) so I cant really provide the right pseudo code either.

all I have discovered is that if i was to initialize the variables in main and not in the header file like I have the problem goes away!! however popping the header files in main allover again doesn't help at all!!


heres a link to my project, im dying for complex feedback, I have never really had any feedback on my code, I think that is because although its readable its not well commented, I also have written it in a C style too much.

I have looked in to learning how to plan codes better, I would have preffered to use a few class's decisivley but im new to SFML so I thought I wouldn't cover new ground just yet.

https://www.dropbox.com/sh/m5t7w2ysxdx4la8/EYmvPxHcEi

[Disch]

unfortunately I have been trying to recreate the problem to no avail

That usually means the problem is unrelated to what you think it's related to. It might take some old-fashioned debugging (stepping through the code and watching vars to make sure they're updated as you expect).

heres a link to my project, im dying for complex feedback,

That code does not compile for me due to your misunderstanding/misuse of globals. I had to copy/paste the contents of load_files.cpp and stringtoint.cpp into main.cpp to get it to build.

Running the program also causes it to immediately crash (also because of the misuse of globals -- looks like static initialization order fiasco)

I'm surprised this is building for you -- and even more surprised that it is actually running. =x

I'm going to outline some things about SFML (and C++ in general) that you should know. If this is too much to follow... it's basically summarized with "Globals are bad and you shouldn't use them"

1) Global variables are constructed before "main" starts. In one "compilation unit" (basically, a single cpp file), globals are constructed in the order they are declared. That is:

string a;  // a will be constructed before b because it is declared first
string b = a;  // <- safe because a has already been constructed 

If you have multiple compilation units... the order of construction is not guaranteed and this can lead to nasty problems. Example:

// in a.cpp
string a;


// in b.cpp
string b = a;  //<- NOT SAFE, see below 

Here, there is no way to know whether a or b is constructed first. And since the construction of b depends on a already being constructed... you are HOSED.

2) SFML may or may not have its own globals. I don't think it does anymore... but I still would not attempt to construct any SFML object globally, as its construction may depend on some SFML initialization that doesn't happen until main starts. This isn't really specific to SFML... it's just a general rule of thumb when using any library.


3) SFML creates the OpenGL context with the first created window, and destroys it when there are no more windows.

4) Things like sf::Texture require a GL context to construct/destruct. This combined with #3 mean you are blowing yourself up with this code. You have a globally created sf::Texture ('contact'). Being globally created means it is constructed before your window, and destructed AFTER your window.

This is the opposite of what you need. The window must be created FIRST and destroyed LAST so that there is always a valid GL context for the sf::Texture to use.


5) Defining a variable in multiple cpp files causes a linker error. If you make two separate variables named "foo" in two separate cpp files... the linker will get confused because it now has 2 vars with the same name at the same scope, and it doesn't know which of the 2 you want to use.

6) #include <someheader> is effectively a copy/paste operation. The compiler basically copy/pastes the header code into the cpp file when you do an #include. This, combined with #5, means that global variables defined in headers... which are #included in multiple files.... means each of those files are defining their own variable... which causes linker errors.

[devonrevenge]

Okay thanks Disch, I thats really helpful, I like the effect the competition has.

I might start from scratch but I dont feel bad about that, I will have to submit a baby token version of what I was doing.