Talk About Network

Google


Register and Login
Nick
Password
Register create new account Sign up is FREE and you can post replies, new topics, bookmark posts and more!
Recover lost password


Programming > C++ > Re: Compressing...
Latest [ Topics | Posts ] Archive Post A New Topic Post a Reply
<< Topic < Post Post 4 of 6 Topic 45779 of 46738
Post > Topic >>

Re: Compressing syntax/code, a testcase

by James Kanze <james.kanze@[EMAIL PROTECTED] > May 7, 2008 at 03:09 AM

On May 6, 5:22 pm, dizzy <di...@[EMAIL PROTECTED]
> wrote:

> I've started lately to run more often than not into situations
> where I need a function to perform several duties, but the
> duties to perform (although decided at the point of call, at
> compile time) are not controlled by the signature (the
> arguments are the same) so overloading normally won't help
> (unless abused like new-expression does with std::nothrow).
> There is also a need to remove any redudant or duplicated
> code. I will take a "real world" example, supose I want to
> "beautify" and extend/wrap the mkdir(2) POSIX call.
> Requirements (acording to the code that will use it):

> 1. beautify:

> 1.1 it will take not only char const* for pathname but also
> std::string const& (most likely to be used alot more oftenthan
> the char const* version) 1.2 also, mkdir(2) takes 2 arguments,
> a path and a second argument which represents the privileges
> to be created with for that directory; beautification asks us
> to make this second argument a default argument of value 0755

That's just overloading and a default argument.  (For that
matter, you could argue that the overloading isn't necessary,
since a char const* converts implicitly to an std::string.)

On the other hand, you don't want to tie the modes down that
much to the underlying OS.  I use symbolic constants, open and
closed: the default is closed (which maps to 0700 under Posix).
open maps to 0775, but you could easily define more (probably
accepting that some will end up mapping to the same thing on
some other systems).

> 2. extend/changed semantics:

> 2.1 there must be a nothrow version that returns with bool if
> it succeeded 2.2 there must be a throw version that throws in
> case of error 2.3 there must be a version where the code
> should NOT consider an error if mkdir(2) returns -1 and errno
> =3D=3D EEXIST and there is a directory already 2.4 there must be a
> version to be used when the caller does not care about any
> possible failure (best effort version, this version is needed
> because in order to properly solve requirement 2.3 one needs
> to use an expensive (l)stat because EEXIST is also returned in
> case of non directories existing at the same path and as such,
> some users may just want a best effort mkdir without the cost
> of doing stat in case of EEXIST failure)

> Sounds simple and straightforward :)

There are really only two options: you re****t an error if the
creation fails, or you don't, if the directory already exists.
Logically, it's two different operations: createDirectory(), and
ensurePath().  With two different names: the first creates the
named directory, and fails if it can't; the second ensures that
the path exists, and fails if the path doesn't exist (when it
has finished).  (Note that ensurePath behaves like 'mkdir -p'
under Posix---it also creates any intermediate directories that
might be needed.)

You might also want to consider a more elaborate error code,
with different types of error conditions.

For something this low level, the only really appropriate way to
re****t an error is with a return code.  If the client code wants
an exception, it can wrap the function (and if it really wants
to ignore any errors, it can do that as well).

--
James Kanze (GABI Software)             email:james.kanze@[EMAIL PROTECTED]
 en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
 




 6 Posts in Topic:
Compressing syntax/code, a testcase
dizzy <dizzy@[EMAIL PR  2008-05-06 18:22:49 
Re: Compressing syntax/code, a testcase
Christopher <cpisz@[EM  2008-05-06 12:47:08 
Re: Compressing syntax/code, a testcase
dizzy <dizzy@[EMAIL PR  2008-05-07 10:48:15 
Re: Compressing syntax/code, a testcase
James Kanze <james.kan  2008-05-07 03:09:24 
Re: Compressing syntax/code, a testcase
dizzy <dizzy@[EMAIL PR  2008-05-07 15:39:35 
Re: Compressing syntax/code, a testcase
James Kanze <james.kan  2008-05-09 02:24:34 

Post A Reply:
  Go here to Signup

AddThis Feed Button


About - Advertising - Contact - Frequently Asked Questions - Privacy Policy - Terms of Use - Signup

Contact
tan12V112 Wed Jul 9 0:04:27 CDT 2008.