generating strings....

Why the heck are you casting integers to const char * ?

From your other posts I''m assuming you''re using C++ and not C, so I would recommend just using std::stringstream.

std::stringstream builder;
if (size >= 1) builder << a;
if (size >= 2) builder << b;
if (size >= 3) builder << c;
if (size >= 4) builder << d;
if (size >= 5) builder << e;
if (size >= 6) builder << f;

std::string built_string = builder.str();
 

im using sendmessage api to send text to a edit box will it still work could you give me more info on how to use the namespace ? i havent used std::streamstring ever before?

i got this so far.. yet compiler errors?
std::stringstream GenString(int size)
{
std::stringstream builder;
builder+=a;
if(size >= 1)
{
builder << a;
}
if(size >= 2)
{
builder << b;
}
if(size >= 3)
{
builder << c;
}
if(size >= 4)
{
builder << d;
}
if(size >= 5)
{
builder << e;
}
if(size >= 6)
{
builder << f;
}
return builder;
}


error C2079: 'builder' uses undefined class 'std::basic_stringstream<_Elem,_Traits,_Alloc>'
with
[
_Elem=char,
_Traits=std::char_traits,
_Alloc=std::allocator
]

[edited by - DevLiquidKnight on January 10, 2004 4:58:38 PM]

It sounds like you included <strstream> instead of <sstream>.

#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include <iostream>
#include <cstdlib>
#include <cstdio>
#include <string>
#include <sstream>
using namespace std;

error C2582: 'operator =' function is unavailable in 'std::basic_stringstream<_Elem,_Traits,_Alloc>'
with
[
_Elem=char,
_Traits=std::char_traits,
_Alloc=std::allocator
]
error C2440: 'type cast' : cannot convert from 'std::stringstream' to 'LPARAM'
No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
error C2664: 'FoundMessageBox' : cannot convert parameter 1 from 'std::stringstream' to 'std::stringstream'
No copy constructor available for class 'std::basic_stringstream<_Elem,_Traits,_Alloc>' or constructor attempts to perform illegal conversion to non-__gc reference
with
[
_Elem=char,
_Traits=std::char_traits,
_Alloc=std::allocator
]
error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'std::stringstream' (or there is no acceptable conversion)
error C2520: 'std::basic_stringstream<_Elem,_Traits,_Alloc>::__ctor' : no non-explicit constructor available for implicit conversion
with
[
_Elem=char,
_Traits=std::char_traits,
_Alloc=std::allocator
]
and
[
_Elem=char,
_Traits=std::char_traits,
_Alloc=std::allocator
]
see declaration of 'std::basic_stringstream<_Elem,_Traits,_Alloc>::__ctor'
with
[
_Elem=char,
_Traits=std::char_traits,
_Alloc=std::allocator
]
and
[
_Elem=char,
_Traits=std::char_traits,
_Alloc=std::allocator
]
generate_strin_test - 5 error(s), 0 warning(s)

---------------------- Done ----------------------
Build: 0 succeeded, 1 failed, 0 skipped




[edited by - DevLiquidKnight on January 10, 2004 5:23:32 PM]

Don''t return std::stringstream objects by value. Return the std::string you get from std::stringstream::str().

Still doesn't work so I give up. This is why i hate namespaces they make it harder then it really is :/.. Its now only sending #'s not characters like I wanted it to.

[edited by - DevLiquidKnight on January 11, 2004 5:34:03 PM]

Post the latest code also.

quote:

---

Original post by DevLiquidKnight
Still doesn't work so I give up. nothing works now.. this is why i hate namespaces.

---

Namespaces have nothing to do with the problem. They are just organisational tools. As for hating the standard library because you can't get it to work, well, it only shows you have still quite a lot to learn (including what namespaces actually are). Actually sitting down and reading the docs could prove a worthwhile experience. I'd be much more willing to help you understand the library's and the documentation's internal logic than to explain one more time how string streams work (search gamedev for std::stringstream and you'll see what I mean).

---

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan (C programming language co-inventor)

[edited by - Fruny on January 11, 2004 5:35:59 PM]

Assuming you did want to use C:

char genString[256] = "";
int vals[] = {a, b, c, d, e, f};
for (int i=0; i < 6; i++)
{
    if (size >= (i + 1))
        sprintf(genString, "%s%i", genString, vals[i]);
}

That should append a through f to the string genString based on the variable size. The main thing to watch is the length of the string, since sprintf won''t do that for you, but you can probably manage that.

Hopefully that is what you were trying to do in the first place. Good luck.

---

"Back to the code mines... ka-chink... ka-chink..."
Tachyon Digital - Down for the summer, be back in the fall.

I only don''t like namespaces because they make my code look sugar coated 0.o. If that makes any sense, its not as "solid" as using just the stanard data types you might say?

Sense your using a namespace as a object that handels all the solid code for you. Its not I don''t like them its more that they make me not able to see everything going on inside them, unless I view the headers of the namespaces or look in the sdk, or go through debugging which can be a pain.

However I don''t use them often so its hard for me to judge how useful they are. I''ve used them with the Irrlicht game engine so I kinda know how to use them I just don''t perfer them.

a namespace is NOT an object in any sense of the word ... a namspace has NO EXISTENCE except at compile time ... and namespace is just a way for a compiler to allow 2 library vendors to use things with the same name, and not be in comflict ...

IN C - if the compiler vendor wrote a function called

int get_int(void);

I could not do the same - or i could, but only WHEN i wasn''t including their header files ... (which might change during the writing of a project) ..

IN C++ with namespaces:

compiler vendor does this:

namespace borland {

int get_int(void);

};

then i can still write my own:

int get_int(void);

or

namespace me {

int get_int(void);

};

and NOT ONLY IS THAT POSSIBLE ... but i don''t have to know what names the library or vendor has used anymore (EXCEPT the ones i need to call of course) ... cause they won''t cause problems now ... IF you qualify your items ... and WHEN they DO cause problems, like this case:

#include "their.h"
#include "my.h"

using borland;
using me;

int x = get_int();

the fix is simply to change the line to:

int x = me::get_int();

NO NEED TO CHANGE AND RECOMPILE LIBRARIES ...

these are JUST NAMES ... they are not objects ... you can think of borland::get_int(void) and something like __borlandns__get_int(void) and me::get_int(void) as __mens__get_int(void) .. cause that''s all it does ... MANGLE THE NAME in the library so they won''t overlap ... of course the method of name mangling is different than just adding __ and ns__ about the namespace (and compiler specific) ... but it is FUNCTIONALLY equivelent ...

as for converting ints (or ANY builting type) to strings or character pointers ... I use the C++ method with stringstreams, but you can also use sprintf just as well ... it''s very simple too ...

here''s a buffer:

char *buffer[MAX_SIZE]; // having to have a max size is the main weakness of all of C''s versions of IO.

then all you do is:

sprintf(buffer, "%d", myInt);

and buffer will have the decimal version of myint ... you could do - %x for hex output, %6d to specify a coloumn size of 6 ... etc .. it is 100% identical to printf() in every way except that it goes into your string instead of out to the standard output.

Namespaces are not types. Namespaces are not objects. Namespaces are organisational tools meant to avoid name collisions. No more, no less. You can think about them, if you will, as classes that cannot be instanciated and only have public, static members

The C++ standard library happens to be entirely contained in the std namespace, so that you wouldn''t get conflicts with other names. This is why you are allowed to create a type named string even though you #include <string>. The standard string class is in the std namespace. Code placed within that namespace can refer to it as string (just like class members). Code placed outside that namespace must refer to it as std::string.

Yet, by using a using-directive like using namespace std you are telling the compiler that all names placed in the std namespace should be imported in the global namespace. Thus plain string (which ordinarily refers to ::string) becomes a synonym for std::string. Of course, if you already had a string symbol, the compiler will tell you you can''t do that. Which is OK.

You can also import only part of a namespace with a using declaration. If you write using foo::bar, bar becomes an alias for foo::bar, but no other name placed within the foo namespace is affected. Code outside the namespace will still need to refer to foo::quux using the foo:: qualifier. Note that this is also possible with classes, to some extent.

Additionally unlike a class, a namespace can be split in several pieces.

namespace foo { int x; }
namespace foo { int y; } 

is equivalent to

namespace foo { int x; int y; } 

Since namespaces are not variables, but really only affect the names it contains (the compiler will see foo::x instead of ::x), it is not surprising, and quite useful.

Finally, an unnamed namespace will make any name it contains local to the current translation unit, like static at file scope in C.

foo.cpp

namespace { int x; }
int foo() { return x; } 

bar.cpp

namespace { int x; }
int bar() { return x; } 

The x variable declared in foo.cpp cannot be seen in bar.cpp, and conversely.

quote:

---

Original post by DevLiquidKnight
I only don''t like namespaces because they make my code look sugar coated 0.o. If that makes any sense, its not as "solid" as using just the stanard data types you might say?

---

Now that I''ve explained what namespaces are about, I''ll assume you''re talking about libraries. And I''ll tell you you are wrong, and that this is the mark of a noob. Unless you become a library programmer, programming is not about rewriting the standard library, but about solving problems, right? (Just look on gamedev, how many people are writing and rewriting and polishing their ''engine'' without ever moving on to actually writing a freaking game with it. An engine doesn''t have to be perfect to be usable.) And I would argue that the standard library is likely to be orders of magnitude more "solid" than any equivalent code you might write - the fact that you admitted not being able to even use it reveals that you certainly are not ready to rewrite it. Truth be told, neither am I.

Additionally, I''m not even talking about downloading a third-party library. I''m talking about something that comes with every (standard compliant) C++ compiler. You might as well go on and rewrite your 3D library, your OS, and your CPU''s microcode in order to make them feel ''solid'' enough that you could write a game on them.

As for standard data types, for all intent and purposes, things like std::stringstream are standard data types. They are described in the specification for the C++ language (ISO/IEC 14882-1998 a.k.a. "The C++ Standard"). Ergo, they are standard. They are not basic data types, I''ll grant you that much, but they could very well be built-in data types, understood natively by the compiler. Take the typeid operator, for example. It is built into the compiler. However, its return type is described in the header <typeinfo> and is treated by the programmer as a library component. This doesn''t change the fact that, regardless of what the header file says, that type must be built into the compiler.

quote:

---

Sense your using a namespace as a object that handels all the solid code for you. Its not I don''t like them its more that they make me not able to see everything going on inside them, unless I view the headers of the namespaces or look in the sdk, or go through debugging which can be a pain.

---

You know what they say: "no pain, no gain". How are you going to make any progress if you don''t try to understand how they work. There are hundreds of books written on data structures, and even more on algorithms. You definitely need to learn about all that. Yes, it is a lot of work. No, you won''t be able to know everything. But you will be able to learn and understand the common techniques (Binary trees are all nice and well ... so long as they are balanced. Do you know how it is done ?) You should consider you lucky that the standard library code is available. So many people claim "I don''t like C++, it does things behind my back", while not even trying to find it what it does. Talk about hypocrisy...

Even without reading the code, the specifications for each and every component of the library (i.e. What it does) is available. There even are books on it. Sure, I''ll grant you they may not make you dream like game programming books can, but in the long term, they''ll probably prove more beneficial. Assuming you even become a professional programmer (which, from your defeatist and I-can''t-be-bothered attitude, I doubt), you are much more likely to need knowing about general techniques, tools, data structures, algorithms, than anything game specific.

quote:

---

However I don''t use them often so its hard for me to judge how useful they are. I''ve used them with the Irrlicht game engine so I kinda know how to use them I just don''t perfer them.

---

You don''t use them. You are not able to use them. You gave up on using them. You don''t know if they are useful. You don''t understand them. You don''t like them. I think I see a recurring theme here.

Like so many others here, you appear to have reached a plateau in your skills, and don''t have either the imagination nor the knowledge necessary to solve the problems you are faced with. And, like many others, you fail to realize that these problems have been solved before, and are in fact so common that your compiler ships with a canned solution to them.

*sigh* Enough ranting. Not everything above may be applicable to you directly (I get carried away sometimes), but I hope you understand what I meant.

---

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan (C programming language co-inventor)