EBCDIC to ASCII
7
The modus operandi for this is similar to that taken by PHP's implementation of such functions. It's comparitively memory-intensive, but is much faster than running a whole bunch of tests.
Basically, you set a mask -- an array of 256 null bytes -- and set those that correspond to characters you wish to trim. Then, rather than having to test if a character is in the set of characters to trim(O(n), or linear time on *ws), you just test once (O(1), or unit time) to see if the byte in question is set.
And of course, to trim(), you just wrap trim() around both ltrim() and rtrim().
One point of caution: these functions trim in place, so copy strings before trimming them. (Of course, if you usually want access to both pre- and post-trimmed strings, you could always make these malloc() a new string and return a pointer to it . . . )
Basically, you set a mask -- an array of 256 null bytes -- and set those that correspond to characters you wish to trim. Then, rather than having to test if a character is in the set of characters to trim(O(n), or linear time on *ws), you just test once (O(1), or unit time) to see if the byte in question is set.
And of course, to trim(), you just wrap trim() around both ltrim() and rtrim().
One point of caution: these functions trim in place, so copy strings before trimming them. (Of course, if you usually want access to both pre- and post-trimmed strings, you could always make these malloc() a new string and return a pointer to it . . . )
6
Another pull from my growing-towards-beta CGI library: sgcgi_url_unescape().
Note the use strcpy, which is faster than the equivalent memmove()ing. To ensure 64-bit safety, I plan to rename this function and then conditionally compile it to point to either strcpy or a 64-bit-safe memmove() implementation of strcpy.
However, even though copy order isn't guaranteed for strcpy, on 16-bit and 32-bit systems, all known implementations copy byte-by-byte from lower addresses to higher addresses. Some 64-bit optimized compilers may copy 8-byte chunks, making the assumption of full linearity unstable at best.
I know it sounds like I'm justifying use of nonstandard code for convenience . . . *blush* . . . it's just something that putting in a -DPEDANTIC type of preprocessor flag could fix if broken, and its SO much faster!
Note the use strcpy, which is faster than the equivalent memmove()ing. To ensure 64-bit safety, I plan to rename this function and then conditionally compile it to point to either strcpy or a 64-bit-safe memmove() implementation of strcpy.
However, even though copy order isn't guaranteed for strcpy, on 16-bit and 32-bit systems, all known implementations copy byte-by-byte from lower addresses to higher addresses. Some 64-bit optimized compilers may copy 8-byte chunks, making the assumption of full linearity unstable at best.
I know it sounds like I'm justifying use of nonstandard code for convenience . . . *blush* . . . it's just something that putting in a -DPEDANTIC type of preprocessor flag could fix if broken, and its SO much faster!
8
The best way I've found to keep a suite of CGI environment variables in my C CGI programs is actually just to read them as name-value pairs into a stack. It simplifies parsing and makes the code cleaner and less fragile than using a specialized structure or an ordered array of strings (as well, empty variables are simply not push()ed onto the stack, so memory doesn't have to be allocated for empty strings). Plus, since there are never a huge number of environment variables, and they are all unique (by definition), a search through the stack for a given name takes minimal time. In fact, retrieval of environment variables beats a PHP-like hash-table implementation by a good deal.
In the code below, all you have to keep in mind is that the NVStk is a name/value pair stack (implemented as a singly-linked list with each node containing two char*s). Variable retrieval times can be minimized by adjusting the order of variable names in the char**s passed to sgcgi_getenv(). In fact, the ones below are just about backwards from how they ought to be, since I forgot I was using a stack instead of a queue . . . *blush*
Of course, there are more environment variables you can get, but you have to draw the line between exhaustion and efficiency, and that depends on the project. The variables included here are pretty much overkill for any program you're likely to need.
A nice way to use these types of functions is to wrap them in an accessor function that gets the environment once and keeps it as a static variable, and then on subsequent calls just looks up values in its stack. (If you want to see the NVStk, I can put it up, but it's pretty much a basic linked list.)
In the code below, all you have to keep in mind is that the NVStk is a name/value pair stack (implemented as a singly-linked list with each node containing two char*s). Variable retrieval times can be minimized by adjusting the order of variable names in the char**s passed to sgcgi_getenv(). In fact, the ones below are just about backwards from how they ought to be, since I forgot I was using a stack instead of a queue . . . *blush*
Of course, there are more environment variables you can get, but you have to draw the line between exhaustion and efficiency, and that depends on the project. The variables included here are pretty much overkill for any program you're likely to need.
A nice way to use these types of functions is to wrap them in an accessor function that gets the environment once and keeps it as a static variable, and then on subsequent calls just looks up values in its stack. (If you want to see the NVStk, I can put it up, but it's pretty much a basic linked list.)
5
jpereira1
Find binary, malformed or non ascii characters in a file.
9
Below is a bit of code which sets up drag and drop in a treeview. This is handy for if you have a list of items that can be sorted by the user.
Here is a bit of code to demonstrate how to do this. First create a new Windows executable project. Drop a TreeView component on the form, and let's name it 'myTree' for this demonstration. Go ahead and populate it with some dummy data; enough data to see the dragging and dropping in action. You will need a variable global to the form's scope.
private TreeNode sourceNode;
This is used to track the item we are dragging in our TreeView. Then define the event handlers listed below.
Here is a bit of code to demonstrate how to do this. First create a new Windows executable project. Drop a TreeView component on the form, and let's name it 'myTree' for this demonstration. Go ahead and populate it with some dummy data; enough data to see the dragging and dropping in action. You will need a variable global to the form's scope.
private TreeNode sourceNode;
This is used to track the item we are dragging in our TreeView. Then define the event handlers listed below.
8
Converts a string representation of a number with any base(binary, octal, decimal, hexadecimal, up to base 36) to a long int.
10
Transform any basic type to string. Very handy for log messages
Usage:
int i(12);
float j(3.14);
cout
Usage:
int i(12);
float j(3.14);
cout
7
Simple tests for dir and file existance. Path creation and removal.
6
boost::format gives you the ablility to safely use printf like formatting as well as positional format specifiers ala .NET.
10
template function to create a boost::shared_ptr in the form
boost::shared_ptr classPtr = new_ptr(Arg1, Arg2);
You can also make new_ptr_access a friend of className and make the constructor and destructor private.
This keeps the end user from:
Creating an instance manually on the heap
Creating an instance manually on the stack
Deleting a shared_ptr manually using "delete get()"
boost::shared_ptr classPtr = new_ptr(Arg1, Arg2);
You can also make new_ptr_access a friend of className and make the constructor and destructor private.
This keeps the end user from:
Creating an instance manually on the heap
Creating an instance manually on the stack
Deleting a shared_ptr manually using "delete get()"









