> > 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), );
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 withoutgarbage 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.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]