Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-

String or Char*

Name: Anonymous 2010-07-19 22:24

What does /prog/ like better?

I personally like string

Name: Anonymous 2010-07-19 22:50

Obscuring pointers with typedefs considered harmful

Name: Anonymous 2010-07-19 23:11

I'm not a huge fan of C++'s std::basic_string class template.

It lacks some common routines found in many modern languages' class library string implementation. It's also a mutable string, which makes it more complex and you end up with more code bloat. There's no first-class UTF-8 or UTF8-16 support either. The meaning of wchar_t and the L string prefix vary by platform. On Windows, it maps to UCS-2, an ancestor of UTF-16. On Linux, it maps to UTF-32.

At my last place of work, we ended up rolling our own C++ string templates. We created encoding classes which captured a lot of the common traits and functions. And then we made the string template be parameterizable on an encoding class type. Our string implementation was also immutable, thread-safe reference-counted, and had modern-style operations. It also came with a string_builder class for mutable operations and you customize it to use whatever container on the backend--it was set to std::deque by default.

So we had:


class string_encoding; // ascii
class wstring_encoding; // wchar_t
class u8string_encoding; // utf8
class u16string_encoding; // utf16
class u32string_encoding; // utf32

template< class Encoding, class Allocator >
class generic_string;

template< class Encoding, class Container >
class generic_string_builder;

typedef generic_string<string_encoding, allocator> string;
typedef generic_string<wstring_encoding, allocator> wstring;
typedef generic_string<u8string_encoding, allocator> u8string;
typedef generic_string<u16string_encoding, allocator> u16string;
typedef generic_string<u32string_encoding, allocator> u32string;

// etc.


Yeah, it was over kill, but boy was it ever worth it.

Name: Anonymous 2010-07-19 23:19

>>3
How does a company of programmers look at that and not say, "Wow, using C++ is quite possibly the most retarded option available to us."

Name: Anonymous 2010-07-19 23:28

>>4
It was a game development company, and a fairly major one. We pretty much built our own version of the standard library.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

C++, despite it's flaws, is at the sweet spot when it comes to both performance, expressibility in terms of language features, multi-platform support, and programmer familiarity (at least within the game development industry).

Name: Anonymous 2010-07-19 23:30

My favorite >> part of C++ is>> these things >>

Name: Anonymous 2010-07-20 1:09

>>5
So it's like eating shit because nothing else is available.

Name: Anonymous 2010-07-20 1:25

>>7
Pretty much. C++0a/C++0b is coming soon, so we're getting an improved version of shit.

Name: Anonymous 2010-07-20 1:35

>>8
More like C++0g.

Name: Anonymous 2010-07-20 1:38

Sepplesog?

Name: Anonymous 2010-07-20 3:17

g is not a valid hexadecimal digit. You fail at life.

Name: Anonymous 2010-07-20 4:57

>>11
u

Name: Anonymous 2010-07-20 7:01

>>11
That's the joke.
Just like a and b are not valid decimal digits.

Name: Anonymous 2010-07-20 7:33

>>11
Neither is x.

Name: Anonymous 2010-07-20 8:38

>>5
Cool link bro, thanks.

Name: Anonymous 2010-07-20 9:56

>>5
You may as well have used C, then you'd only have added enough shit that amounts to how much shit the ++ adds on, instead of already having that amount of shit and then adding the same amount on again.

Name: Anonymous 2010-07-20 10:31

The thing you have to understand about game programmers is that they're all morons. What do you expect from the sort of person who becomes a programmer because he likes vidya games?

Name: Anonymous 2010-07-20 11:10

>>16
Object oriented paradigm looks terrible in C. You may as well use C++ and stick to a well defined featureset of C++

Name: Anonymous 2010-07-20 12:11

>>18
Nonsense. How is do_stuff(some_object, 1, 2, 3) significantly different than some_object.do_stuff(1, 2, 3)? You might as well use C and accomplish all the same things with less work.

Name: Anonymous 2010-07-20 12:34

>>19
Inheritance gets kind of messy. Sure, it's possible, but what's wrong with "sticking to a well defined featureset of C++" like >>18 said?

Name: Anonymous 2010-07-20 12:41

I like string panties. Is that relevant to this thread?

Name: Anonymous 2010-07-20 12:41

>>20
Inheritance is messy anyway. But with a bit of standard boilerplate it really isn't any uglier than C++.

typedef struct parent {
    int a, b, c; /* some stuff */
} parent;
typedef struct child {
    parent p;
    int d, e;
} child;
/* ... */
#define PARENT(obj) ((parent *) (obj))
#define parent_do_stuff(obj, a, b, c) _parent_do_stuff(PARENT(obj), a, b, c)


Then your actual code looks something like:
child *c = new_child();
parent_do_stuff(c, 1, 2, 3);

No nasty casts all over the place like Gtk has. Note that you can toss something like int rtti in your parent object and contrive some sort of isa() to verify that the pointed object is of the appropriate type.

Name: Anonymous 2010-07-20 12:43

>>18
Oh yeah, I forgot. In your world, macros are A Bad Thing, this is a keyword, and classes, objects and operator overloading aren't just syntactic sugar.

Name: Anonymous 2010-07-20 14:38

>>23
It's almost as if nobody like Java!

No seriously, is there anyone in the entire world that likes this language?

Is it the language, the marketing or the retarded programmers that cause this?

Name: Anonymous 2010-07-20 14:49

>>24
No seriously, is there anyone in the entire world that likes this language?
The answer to that question is always yes.

Name: Anonymous 2010-07-20 16:41

>>3,5
That is really interesting stuff. I'm very surprised that you were using an immutable string class for C++ game development though because of the allocator stress and fragmentation it would cause (your link suspiciously mentions none of this.) Also if it's game development, why do you need to worry about encoding at all? Why not just use UTF-8 for everything (with a couple of helper functions to dump it into a native format where necessary)?

I've often wanted to write a string implementation like that, except with indirection built in so that the string data could be allocated from a special zone that compacts memory. Of course getting that right with multi-threading is extremely difficult/impossible. As far as I know there isn't a way to 'stop the world' in C++ the way a collector in a managed language can do. This means you're stuck using arbitrary memory barriers whenever you access strings in case their memory has been moved around by a different thread, which makes the whole thing so slow as to be useless.

Name: Anonymous 2010-07-20 17:02

>>26
Implying game developers give a shit about performance :)

Name: Anonymous 2010-07-20 17:06

>>27
They kind of have to.

Name: Anonymous 2010-07-20 17:08

>>26
Of course getting that right with multi-threading is extremely difficult/impossible.
In the contexts of games, you're not really generating a ton of strings on the fly. Immutability and multithreading are bffs.

Name: Anonymous 2010-07-20 19:23

>>16,19,22
The thing is, trying to force object-oriented design with C on a code base with over a couple of million lines of code is hell. It's also dangerous because people who do it tend to cram function pointers into instance objects directly, which has a larger memory footprint over how virtual functions are usually implemented in C++. Plus, C++ has generic programming with templates (external code generation is more brittle), RAII, and various other things that make development more pleasant. C++ isn't perfect, but if used correctly, it's helpful.

Yes, games and game engines are up there in terms LoC.

Name: Anonymous 2010-07-20 19:49

>>26
[quote]I'm very surprised that you were using an immutable string class for C++ game development though because of the allocator stress and fragmentation it would cause[/quote]

It was no more stressful on the allocator than std::string, in fact, it was generally less stressful. When you're modifying a std::string and inserting characters, with the implementations I've seen, when you reach the capacity of it's buffer, it'll allocate a new buffer twice the size of it's current buffer, copy all of the characters over to the new one, and release the old buffer. It generally has O(2^ceil(log2(N))) memory complexity.

With our string_builder, you could use whatever container for storage on the backend, which by default was a deque, which allocates fixed-sized slices or blocks: O(m*ceil(N/m)) memory complexity where m = block size (typically 256 bytes). Used with a non-blocking stack-based allocator on the backend, it's pretty decent.

We also employed strict memory budgeting, where we'd be like, okay, we can use a 256KB set of pages for various random strings, and 2MB of pages for text assets for the current level/map.

[quote]Why not just use UTF-8 for everything[/quote]

Asiatic character sets tend to use up less memory when in UTF-16 encoding, and a lot of games usually end up getting localized for Japan and Korea at some point.

[quote]except with indirection built in so that the string data could be allocated from a special zone that compacts memory[/quote]
That's what the Allocator template parameter is for!

[quote]multi-threading is extremely difficult[/quote]
It can be difficult, but you can build your own threading library on top of pthreads or windows threading apis.


class allocator
{
    static bool const is_thread_safe = true;
    /* ... */
};

enum memory_order
{
    memory_order_relaxed,
    memory_order_consume,
    memory_order_acquire,
    memory_order_release,
    memory_order_acq_rel,
    memory_order_seq_cst
}

template< typename T >
class atomic
{
    inline void add< memory_order >(T value) {
       // magic
    }
};

template< class Encoding, class Allocator >
{
private:
 
    // intrusive reference counted instance
    struct instance
    {
        atomic< int32_t > use_count;
        typename Encoding::size_type size;
        typename Encoding::char_type data[];
    };

    void acquire() {
        instance_->use_count.add< Allocator::is_thread_safe ? memory_order_consume : memory_order_relaxed >(1);
    }
};


Essentially, you can make your string template work with both thread-safe and non-blocking allocators and emit the most efficient code for reference counting in both cases.

Name: Anonymous 2010-07-20 19:54

>>29
Yeah you're absolutely right, the only strings you're generally generating on the fly are for various things in the game HUD, especially in networked games. On current consoles, you just use a non-blocking fixed sized memory allocator for that as the logic for it usually in a single thread.

Name: Anonymous 2010-07-20 20:21

>>23
You do realize that you use C++ because you want to make use of an OO design? You use OO when the system requirements happen to solved well in such a design - like many computer games, for example.

Name: Anonymous 2010-07-20 20:58

Asiatic character sets tend to use up less memory when in UTF-16 encoding, and a lot of games usually end up getting localized for Japan and Korea at some point.
Let's make the game take up twice as much space for 75% of the world, just so it can take up half as much space for the other 25%!

Name: Anonymous 2010-07-20 21:09

>>34
You're assuming that if you have to use UTF-16 to support asian character sets that you also have to use UTF-16 for everything else. I did not say that.

Typically, you either have some preprocessor definitions set up to allow you to conditionally compile in what text encoding to use, or you can support multiple code-paths allowing you to dynamically switch between UTF-8 and UTF-16 for text assets. This is generally done with interfaces--polymorphic classes and virtual methods.

And just because the game text is using u16string doesn't mean you can't be using u8string for internal developer strings, string based identifiers, etc.

Text assets are then run through a preprocessor to convert it to the target encoding when building the gold master. It's all automated.

Name: Anonymous 2010-07-20 21:54

>>31
Back to /pr/ please.

Name: Anonymous 2010-07-20 21:59

>>36
I think you should leave, /prog/ has been shit as of late probably because of you, at least this thread has real programming discussion in it.

Name: Anonymous 2010-07-20 22:11

>>37
Bullshitting about Sepples does not count as ``real programming discussion''. It's even less interesting than anus spam and Java homework threads.

Name: Anonymous 2010-07-20 22:34

>>34
Text. How many resources do current games consume with all their high def models, textures and sounds? UTF-16 support should be no problem within this context.

Name: 26 2010-07-20 22:48

>>29
I didn't say immutability is hard, I said memory compaction is hard. That is extremely difficult in C++ because you pretty much need a stop-the-world or memory barriers everywhere, not to mention pointer indirection and various other restrictions on raw string access.

>>31
except with indirection built in so that the string data could be allocated from a special zone that compacts memory
That's what the Allocator template parameter is for!
What the fuck. Does no one know what compacting memory means? You can't use a regular string implementation because you can't use regular pointers; they have to be indirect so you can move memory.

By the way, thanks for misunderstanding my post and giving me a completely pedestrian explanation for a ref-counted immutable string class. Please learn how the JVM compacts memory, then re-read >>26 and tell me how you are going to implement that in C++. Go ahead and implement it for me and I'll give you one free internet. Honest.

>>31
Asiatic character sets tend to use up less memory when in UTF-16 encoding, and a lot of games usually end up getting localized for Japan and Korea at some point.
Who cares? It's a video game. I bet a single texture in your game uses more memory than all the text for a level. Two whole megabytes for a level's strings; yeah that's something all right!

A custom string library makes sense for applications that deal primarily with text (think word processors, browsers, etc.) I've always just used std::string with UTF-8 for games because text is such a minor part of modern games.

>>35
And just because the game text is using u16string doesn't mean you can't be using u8string for internal developer strings, string based identifiers, etc.
That's a horrible idea. You've now got two different string types to deal with for no reason at all.

Name: Anonymous 2010-07-21 4:29

For my next game I'm going to write my own string functions and have them work on global string objects of fixed size and fixed number.  Who the hell needs to keep strings around.

Name: Anonymous 2010-07-21 6:19

>>40
/prog/ is too busy pretending to know Lisp to learn anything about memory and its management.

Name: Anonymous 2010-07-21 6:41

>>24
There is a guy called NoobFukaire on freenode #gamedev who is a big fan of the Java

Name: Anonymous 2010-07-21 9:25

>>42
This may surprise you, but a number of /prog/riders are actually regular Lisp users.

Name: Anonymous 2010-07-21 9:55

>>44
The plausibility of your statement is inversely proportional to the value of that number.

Name: Anonymous 2010-07-21 14:07

>>44 likes to pretend that a number of /prog/riders are actually regular Lisp users.

Name: Anonymous 2010-07-21 15:23

>>46
Well, you can Greenspun up a lisp for every app you write, or you can just use a lisp in the first place.

Name: air max shoes 2010-07-23 10:56

http://www.cheapairmaxs.com air max
http://www.cheapairmaxs.com air max shoes
http://www.cheapairmaxs.com/nike-air-max-2012-c-111.html nike air max 2012
http://www.cheapairmaxs.com/mens-air-max-2010-c-93.html mens nike air max 2010
http://www.cheapairmaxs.com/womens-air-max-2010-c-96.html womens nike air max 2010
http://www.cheapairmaxs.com/mens-air-max-2009-c-95.html mens nike air max 2009
http://www.cheapairmaxs.com/womens-air-max-2009-c-98.html womens nike air max 2009
http://www.cheapairmaxs.com/nike-air-max-2003-c-101.html nike air max 2003
http://www.cheapairmaxs.com/nike-air-max-97-c-94.html nike air max 97
http://www.cheapairmaxs.com/mens-air-max-95-c-102.html mens nike air max 95
http://www.cheapairmaxs.com/womens-air-max-95-c-103.html womens nike air max 95
http://www.cheapairmaxs.com/nike-air-max-93-c-106.html nike air max 93
http://www.cheapairmaxs.com/mens-air-max-91-c-104.html mens nike air max 91
http://www.cheapairmaxs.com/womens-air-max-91-c-105.html womens nike air max 91
http://www.cheapairmaxs.com/nike-air-max-89-c-121.html nike air max 89
http://www.cheapairmaxs.com/nike-air-max-88-c-112.html nike air max 88
http://www.cheapairmaxs.com/mens-air-max-87-c-108.html mens nike air max 87
http://www.cheapairmaxs.com/womens-air-max-87-c-109.html womens nike air max 87
http://www.cheapairmaxs.com/nike-air-max-180-c-123.html nike air max 180
http://www.cheapairmaxs.com/nike-air-max-360-c-124.html nike air max 360
http://www.cheapairmaxs.com/mens-air-max-ltd-c-122.html mens air max ltd
http://www.cheapairmaxs.com/womens-air-max-ltd-c-116.html womens air max ltd
http://www.cheapairmaxs.com/nike-air-max-bw-c-117.html nike air max bw
http://www.cheapairmaxs.com/air-max-premium-c-118.html air max premium
http://www.cheapairmaxs.com/air-max-skyline-c-114.html air max skyline
http://www.cheapairmaxs.com/air-max-zenyth-c-125.html air max zenyth
http://www.cheapairmaxs.com/nike-air-max-tn-c-115.html nike air max tn
http://www.cheapairmaxs.com/kids-air-max-90-c-119.html kids air max 90
http://www.cheapairmaxs.com/kids-air-max-bw-c-120.html kids air max bw

Name: Anonymous 2010-07-23 14:36

>>40
Expert Enterprise Java™ Programmer right there.

>Please learn how the JVM compacts memory
Now let's see it compact that memory in a real time application (such as a video game [no, that tetris you wrote in CS101 or whatever does not count as a video game]) without killing performance.

>Two whole megabytes for a level's strings; yeah that's something all right!
Two megabytes *is* a lot on a console.

Name: Anonymous 2010-07-23 15:57

>>49
Now let's see it compact that memory in a real time application (such as a video game
I explicitly said in the very post you quoted that it's useless for games. I explicitly said I use std::string for games.

Not only that, but in my previous post (>>26), I express surprise at the fact that someone else uses immutable strings in a video game.

Do you not understand the concept that different data structures are useful for different tasks? Is this a completely foreign and alien idea to you?

Name: Anonymous 2010-07-23 16:24

>>1
whats a Char*?

Name: Anonymous 2010-07-23 17:10

>>51
I think he meant char[*]

Name: Anonymous 2010-07-23 17:12

>>51
A glob pattern that matches Charmander, Charmelion, and Charizard. Whether it matches Chimchar depends on your implementation, but it shouldn't.

Name: Anonymous 2010-07-23 17:18

>>53

I feel like /prog/ should have more Pok&eacute;mon content.

Name: Anonymous 2010-07-23 17:19

>>54
Oh well that's acute.

Name: Anonymous 2010-07-23 17:44

>>53
No, it's a regex that matches Cha, Char, or Charrrrrrrrrrrrrr!!!!

Name: Anonymous 2010-07-23 18:17

>>55
Stop joking, this is a grave matter.

Name: ​​​​​​​​​​ 2010-10-21 22:48

Don't change these.
Name: Email:
Entire Thread Thread List