nebmods API

[Andreas Ericsson]

Ben wrote:
> 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.
> 

write() not always sending the full length is a simple issue. Telling 
the receiving end the length and the offset of the various kinds of data 
is not. Still, perhaps this can be done that way, if I tweak the 
receiving end to use the receiving buffer to keep it all and modify the 
values of the variables to be calculated from the start of the object 
instead. It means implementing a two-step protocol, where the header is 
sent first and is of fixed length, and the body of the message is sent 
later with variable length. It might work.

> 
>>>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.
> 

Indeed. The problem with implementing garbage collection in C is that it 
  requires an abstraction layer between the calling functions and the 
actual malloc()-or-something. Also, the more need you have of garbage 
collecting the more it will slow the program down (more calls through 
the abstraction layer), which sort of robs compiled languages of some of 
their speed benefits over perl and the likes.

> 
>>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.
> 

Maintenance of source-code isn't a concern. Maintenance and logic 
alteration of running code is.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer


-------------------------------------------------------
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