I'm already using 7 bit integer encoding

Great! Unfortunately, this nullifies the only benefit of lil_string you've given:

... if you know you don't need a string of length more than 255 then by using lil_string we can marshall the length of the string in one byte.
[/quote]
[/quote]
Not only that, but his string implementation is hideously written and will be a performance black hole for any serious use-case. Yet another reason why people who don't know what they're doing shouldn't try to implement standard containers.

• You use an awful lot of magic numbers in your code. This is a very sloppy habit and makes me wary of the code quality as a whole. You should never have any magic number that isn't well documented in some way, and ideally about 95% of the numbers in your code should be removed - either to configuration settings, constants, or more robust algorithms (such as anything that touches the arguments to main).
  
  
• Naming conventions - or utter lack thereof... well, a lot's already been said on that in this thread, so I won't belabor the point. But this is a serious obstacle (IMHO) to anyone examining your code in any serious depth. It takes so much mental overhead to figure out what code is even supposed to do, because the names are useless, that I can't summon the energy at this point to try and do a higher-level analysis of the code.
  
  
• You seem to sprinkle around a lot of #ifdefs and platform-specific stuff in arbitrary places. You should be designing your code so that these concerns are totally encapsulated. Similarly, all of the socket stuff should be wrapped so you don't duplicate a bunch of logic all over the place. Logging deserves a wrapper as well. I'm sure there are more examples. It seems to me like you could benefit a lot from a few select extractions of functionality into centralized locations. There's some half-done work in this direction but it really ought to be carried to completion.
  
  
• try/catch(...) anywhere but at an extremely high level always worries me. Any instance of throw; immediately worries me even more. The combination is egregious. You should really reconsider your approach to exceptions. Also, I haven't confirmed this deeply, but I suspect that most of your code is highly unsafe in the presence of thrown exceptions.
  
  
• The machine generated code is kind of weird. I'm used to machine-genned code looking a little odd, but stuff like allocating a stack array of size 1 is just... ugh. If you're emitting that kind of code, it makes me very leery of what kind of other stuff your code generation is up to. Code generation is very hard, and it pays to make sure you're exhaustively careful with it and don't take easy shortcuts too often.
  

The range for lil_string is up to 255 and there's no need to do the math to figure out how many bytes are needed to marshall the string. I just have lil_string as an option. It isn't used by my library. It is only used in an executable. I use it to store password which have to be less than 255 characters.

• lil_string is horribly written. It exists for no purpose, and should be dropped in favor of std::string.
  
  
  
  • Your marshalling is O(3n) while std::string does it in O(n) (or less if you just memcpy blast).
    
  • The explicit constructor on lil_string takes any type and thus will produce compilation errors, or worse, WON'T produce them in some cases, introducing subtle bugs.
    
  • Construction of an empty lil_string involves a memory allocation.
    
  • Construction of a string with a C-string is O(2n).
    
  • Calculating the size of a string is O(n), std::string is O(1).
    
  • Assignment of a c-string is O(2n), std::string is O(n).
    
  • Assignment of a "lil_string" to another lil_string is flat out broken. in std::string it works as expected.
    
  • operator += runs in O(2n), std::string is O(n).
    
  • clear requires a memory allocation.
    

One advantage is the on line aspect.