Forwarding this back to the list, somehow we dropped the list by accident. Sander
-----Original Message----- From: Sander Striker [mailto:[EMAIL PROTECTED] Sent: 10 May 2001 12:48 To: William A. Rowe, Jr. Subject: RE: Memory code... > > David Reid wrote... > > > > [...] > > >> When you find the time could you please change these comments to do > > >> as they say? :-) I didn't know what your error/warning > logging functions > > >> look like (I reckon it is not fprintf(stderr, "some warning"); ), so > > >> I didn't actually implement it. > > > > > > Hmm, again we're a library, not an app... It's not really > our job to log > > > errors is it? We should simply report the problem and let > the app decide > > > what to do about it. > > > > The trouble is that it is ok to use this code in this way. It will also > > succeed. It is just not needed, and therefor overhead. I would just like > > the users to know this so they can remove this call if they want. Maybe > > something like APR_VERBOSE as a compile flagg?? > > If you look at apr_errno, you will notice we finally admit more > than one value > can represent a status result. That even goes for APR_SUCCESS > (APR_IS_SUCCESS()) > so we could add additional success codes. I'd suggest an > APR_NOOP result (also > a success code) that tells the developer, "Hey, you didn't need > this call!". Ok, ack. How would one set this? I'm a bit buried too and at quick glance this looked an amazing lot of info to swallow :-) Please, a <5 line example :-) > But look, if this is a flexible memory system, and the developer > several layers > deep doesn't know _which_ kind of memory they are working with, > then they better > be calling the entire semantic, no? And if parts of that > semantic have no effect > this time around, you still don't want them coding around it, no? Right, agreed. > If they are failures, and you need new APR_Efailure codes, then > add them. If you > want more success (or partial success) codes, add them. But > don't harrass the > developer for using the calls the way they 'ought' to, because we > don't argue over > the call setup/teardown around here for the sake of a few ms of > cpu, we would > rather concentrate on correctness of code. *grin* Ok, maybe I get carried away sometimes, but in memory management cycles count heavy. I wrote a smart memory allocator that does exponential growth on reallocs. It is really quick. I'll see if I can port it to a memory system (actually, I know I can, I have to find the time to do it). [...] >> If you always enforce the '== APR_SUCCESS' it is ok. I'm just pointing >> out that for the users this might be confusing. >> >> Maybe a stupid question, but why not introduce an apr_bool_t? > > apr_bool_t wouldn't hurt or hinder anything, but it's not a > legitimate result from > an apr_function. The reason is pretty simple. _Today_ you > figure, it either worked > or it didn't, and that's all she wrote. But _tommorow_ we > realize that failure is > actually one of three colors of failure, so we are changing the > API every few hours > to keep up with these. And of course, it's an unneccesary > inconsistantcy. Every > time we have that 'one exception' that 'absolutely' shouldn't be > an apr_status_t, > it ends up being an apr_status_t later on :-) Valid reason :-) > All result codes are apr_status_t results > > BTW ... although I'm buried, it's looking really good from here! > Please please please, > agree on the 'shortened names/filenames' and I will be very happy. I already did, so did Luke and Elrond. Actually I explicitly asked for it when handing the code over. The long names were just for clarity when discussing/developing the last couple of weeks (yes, it took that long, for so little code, because there are some things that are really tricky ;-). > Bill Sander
