nebmods API

[Ben]

On Thu, 10 Feb 2005, Andreas Ericsson wrote:

> > 3. If there's anything the history of programming should tell us, it's 
> > that making fixed-length buffers for strings is a bad idea. There will 
> > always be an exception. I don't see anything wrong with prefixing the 
> > strings with their length. This takes care of the networking issues 
> > quite well. At least, it always has for my projects.
> 
> Yes, but it would mean sending several times for a single object, as 
> opposed to send(sock, &host, sizeof(host), <flags>);

Not true. Well, at least, no more true than sending more than 1 byte 
across a network always is..... write() always has the chance of sending 
less than the expected number of bytes. All you have to do is marshal your 
message into a contiguous block of memory and then walk through a loop 
until it's all been written.

> > I'm not exactly 
> > sure what you mean by "deep memory management",
> 
> That you have to enter the struct itself to be able to manage it as a 
> whole, or memory will leak. Look in the code and you'll see what I mean
> free(host->name); free(host->alias); free(host->this_and_that); free(host);

Yeah, that's what I thought you mean. Like I said, constructors and
destructors are your friend. I personally don't agree with a lot of the OO 
programing mindset, but *those* are a really useful concept.

> True, but they are notorious for causing memory leaks.

So is C. :) People that make long-running programs in languages without 
garbage collection should be checking for memory leaks anyway. I 
understand that's just one more thing to do (and fail to do right) but 
that doesn't make it wrong.

> Quite simple really, although the code isn't exactly "Programming 101". 
> Each configuration directive has a function handling it and an arbitrary 
> amount of flags associated with it. As such, it's trivial to add 
> keywords to the list and the keyword handling functions could look at 
> one of the flags to get the variable and then at another flag (cfg_var 
> offset?) to look up what variable to assign to the value. A simple way 
> of getting rid of redundant code-snippets and if() else if() in 
> cfg-parsing. It also inspires better exception handling, since it 
> doesn't have to be duplicated ad nauseum.

Oh, I get it. Well, like your first and second ideas, I don't really care
one way or the other. I'm happy as things are in terms of configuration,
but I could see how this would add more flexibility without taking
anything away.

Stupid question, though.... why not just go straight to a flex/bison
approach? If maintainence of the config parsing code is a concern, it
seems that this might solve it pretty well.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click