01 Sep, 2009, Silenus wrote in the 1st comment:
Votes: 0
I am trying to make some changes to an existing server and replace the current C style string handling with some other type (cords). The string in question are typically initialized via a single function.

The question I have is how typically is it best to do this. My first thought is to compile the code with g++ (since this is possible) and replace the cstring stuff with a class wrapper for the cords library (since it needs/has custom concat,substr and indexing) making the calls to the standard c library string handling stuff illegal. I.e. have the function in question return some other type and use that as a method to detect the presence of manipulations to the string which would need to be fixed(like identifying which [index] stuff is relevant).

Is this typically the sort of method that is used or are there easier ways?
01 Sep, 2009, Davion wrote in the 2nd comment:
Votes: 0
http://www.mudbytes.net/pastebin-2289

That is probably my favourite shared string replacement.
01 Sep, 2009, Silenus wrote in the 3rd comment:
Votes: 0
Hi Davion,

Thanks I did however have some code in mind already since it pairs up well with something else I am sticking into the system. The system already has shared strings but the allocation patterns may not work well with this additional code so I am sticking in the cords library which is a sister lib to this code in order to handle this task. The question goes towards how to handle this sort of subtitution i.e. since the code is written in C the type system itself may not trap the errors in a nice way. I believe the CORD "type" is just a char* and alot of currently legal but illegal constructs when used with CORD will not be flagged by the compiler and end up in strange crashes. I guess this is the problem I am wrestling with.
01 Sep, 2009, Erok wrote in the 4th comment:
Votes: 0
Check out the performance results for the Boost flyweight library, and note GCC 3.4.4 in particular. It's built in copy-on-write optimization for strings gives performance on par with external libraries. Link…

http://www.boost.org/doc/libs/1_39_0/lib...
01 Sep, 2009, Silenus wrote in the 5th comment:
Votes: 0
The thing is given that the current project I am hacking into is in C I am trying to stick to a C implementation. The trick w.r.t. using an user defined class to substitute is kind of a stop gap thing just to assess where the possible problems might be. I am trying to avoid C++ atm.
01 Sep, 2009, David Haley wrote in the 6th comment:
Votes: 0
I would have pointed you to my shared string library, which uses objects that manage themselves as opposed to needing an explicit manager with ref/unref commands, but since you don't want C++…

I'm not sure how you expect to be overriding subscripting, though, if you want to stick to C. But, you would indeed have to return something other than a char* if you wanted to prevent it from being sent to the standard functions.
01 Sep, 2009, elanthis wrote in the 7th comment:
Votes: 0
You cannot get easy string handling in C no matter what you try to do, unless you write some kind of preprocessor, at which point you might as well just use C++. It is not possible to get any kind of automatic memory management in pure C, so you either need to use C++ or use a non-pure-C addon GC library (like the ever-popular Boehm-Demer-Weiss GC library). It is not possible to override built-in C operator behavior. These are just simple facts, no way around them without switching to a different language.

If your only big complaint with your cords library is that the cords are pretending to be a char*, then wrap them in a simple struct. That will at the very least give you compiler errors when code tries to misuse the cord as a regular C string. It will not in any way solve the issues of still needing to manually manage references to the memory or of being unable to use basic C operators with the custom type.

I don't know what your qualms are with switching to C++, but unless you're targeting some off-the-wall embedded platform that has no C++ compiler, I'm going to argue that your reasons for avoiding C++ are flat out silly given the benefits C++ will obviously bring you. You don't have to use C++ like it's Java and turn everything into an object-oriented mess (in fact, good C++ programmers would recommend highly against doing that). You can use it where it helps and not use it where it doesn't. Strings are one place where C++ _really really really_ helps over regular C.

Not only would C++ solve the problems you raised, but it would solve them _better_ than you were trying to solve them. For example, just having a wrapper class that convers cords into C strings for standard C library calls is very inefficient. You pretty much lose the benefits of using cords in the first place. You clearly don't want to replace all the existing C string code, though, or perhaps you have a need to use both C strings and your cords in various places and don't want to have to remember two sets of functions. Thankfully, C++ has long had this problem solved via function overloading. You can just define a custom strchr() function that takes a cord object instead of a string and then you still have a single API that works on both types of strings, and the cord version can directly work on cords without needing to create temporary C strings all over the place.

There is no reason to use inferior tools when you not only need that a better tool exists but when you even have a real need for the improved tool. Use C++.
02 Sep, 2009, Silenus wrote in the 8th comment:
Votes: 0
The problem is that the project I am sort of fiddling with atm is a C project and I am not sure the current user base wants to see that changed. Cords has cord specific calls that displace alot of standard cstring operations. The problem for me is more of identification. Since CORD is essentially char* (I think) finding where all the instances of [] might be a bit problematic so I am thinking of compiling the code in C++ mode (since the current maintainer has made it g++ compatible) rigging it with some pseudo_string class to find where all the direct manipulations are taking place since they arent valid under cords.
02 Sep, 2009, David Haley wrote in the 9th comment:
Votes: 0
I'm not sure what exactly you're trying to do although it sounds like you're trying to have the cake and eat it too. Are you trying to find at compile-time all instances of indexing a "corded" char*? How do you plan on accomplishing that short of changing every single instance of char* to a truly different type? (C++ or not?) Why is the suggestion of wrapping the cord in a struct a bad one? No matter what you do, it's sounding like you will either make the existing cord routines inconvenient to use and will have to rewrite a lot of code, or you won't be accomplishing your goals.

I think you're trying to do something that is inherently extremely difficult to do in C, as elanthis has explained extensively.
02 Sep, 2009, Silenus wrote in the 10th comment:
Votes: 0
I guess in this case the shared strings arent used throughout the system. There is a int_new_string call which is used to construct a string which is shared. The plan for me is to somehow pass back something other than char* from this (compiling using g++ perhaps) and rely on this to figure out how exactly the int_new_string shared strings are being used (this might sound exceptionally obtuse but it's the only thing I can think of). Once I identify these points in the code I can then step down to C again and replace all the relevant calls using the "CORD" type and replace all the stdlib c string stuff with CORD style calls as appropriate.

Basically the wrapping idea is similar to mine though I was thinking more abstractly. I.e. i was thinking of just inserting a different "type" as a signal to trigger the compiler to generate errors but also to perhaps do so somewhat selectively. I guess I was essentially wondering if this was the correct approach to ferreting out all the usages which = potentially illegal. I.e. in general does one just feed some strange type into the system in order to trigger compiler errors then do the modification. C++ would yes solve alot of problems but it really isnt my call and would potentially make the code incompatible with alot of ppl using this code base perhaps on old systems which dont have fully upgraded compilers.
02 Sep, 2009, David Haley wrote in the 11th comment:
Votes: 0
You can't pass back things that aren't char* and then pass them into things that demand char*. By changing the type of the shared string allocator return value, you will cause mass havoc and break basically every instance that these things are used, not just indexing.

Incidentally, unless you override operator[] for a C++ object, it is always legal to subscript a pointer.

A better way to approach this problem might actually be to write some kind of simple C parser that finds variables of type char*, and finds indexing, and then you go manually inspect occurrences of indexing into char*.

BTW, there are extremely few systems that don't have C++ compilers, so the argument that people wouldn't be able to compile it doesn't hold much water (even though C dinosaurs – people who use C because they're scared of C++, and don't have legitimate reasons for not using it – will tell you all kinds of crazy stuff about how C++ won't compile, will break things, will melt the processor, etc.).

Anyhow, I think you have a number of options to choose from at this point, you just have to figure out which one you dislike most. There shouldn't be a quest of finding the "optimal canonical" solution; just pick something that works and gets your goal accomplished and go with it.
02 Sep, 2009, elanthis wrote in the 12th comment:
Votes: 0
Such a parser exists, and can be used for such purposes. It's called sparse.

I would still just recommend using C++. If users complain, the users are stupid.
02 Sep, 2009, Silenus wrote in the 13th comment:
Votes: 0
Thanks guys. I found the sparse webpage but I didnt find any documentation for it. What are the capabilities of this tool? As for the problem w.r.t. C/C++. I might just contribute some C++ code to the project and see if it gets accepted but I suspect it would be easier to do this with C code at present.
0.0/13