Re: Re: api tutorial rewrite (grammer)
Wesley Leggette <[email protected]>
| Newsgroups | gmane.comp.sysutils.backup.dar.general |
|---|---|
| Message-ID | <1108297970.23632.1.camel@localhost> |
On Sat, 2005-02-12 at 12:10 +0100, Denis Corbin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello Wesley,
>
> Wesley Leggette wrote:
> | I've done a small rewrite to the libdar api tutorial. If you'd like you
> | can take a look at my patch (attached).
>
> Thanks, I will have a look at it of course.
>
> | However, I do have a few
> | questions:
> |
> | -----------------
> |
> |
> |
> | Questions regarding tutorial:
> |
> |
> |
> |
> | - Part 3: user interaction
> |
> | void pause (const std::string &message);
> |
> | Here the comments say that
> |
> | Don't worry about thowing an exception in your code; it will be trapped
> | by libdar if you don't want to manage exceptions, and are using libdar
> | in the "no exception" method.
> |
> | Is this to say that you can return "false" in no exception mode, or that
> | you HAVE to
> | throw some type of exception? What exactly would some sample code look
> | like here?
>
> No, it means that whatever you use exception or not in your code, the
> method "pause" MUST throw an exception of type Euser_abort to mean a
> "no" answer to the question and return normally to mean a "yes" answer
> to the question.
>
> This is for historical reason, but it seems that a boolean return for
> this method would be more appropiated for user not wanting to deal with
> exceptions. So I will add an alternative method "pause2" that returns a
> boolean value in place of relying on exceptions, the user will have the
> choice to redifine either pause() or pause2() but not both.
>
>
> |
> |
> | - Part 5: creating simple archive,
> |
> | // my_arch should have been an object instead of a
> | // pointer to an archive object.
> |
> | Is this to say that
> |
> | libdar::archive *my_arch =
> |
> | should be
> |
> | libdar::archive my_arch =
> |
> | and is a typo, or is the first example correct?
> | Does the first comment just mean that *my_arch refers
> | to an archive object?
>
> What is meant is that here in the example we will use pointers to objects
>
> libdar::archive *my_arch = new archive(...)
>
> but you can also use plain objects:
>
> libdar::archive my_archive = archive(...)
>
> the difference is that the pointer must be deleted when no more needed
> while the memory used by the plain object is freed automatically when
> exiting from the current block.
Ah, that makes sense. Thanks.
>
>
> |
> |
> | - Part 7: listing archive contents
> |
> |
> | The user_interaction class has a listing() method which provides
> | seperate arguments for each piece of information that can be displayed:
> |
> | ...
> |
> | file type
> |
> | ...
> |
> | void listing(const std::string & flag,
> | const std::string & perm,
> | const std::string & uid,
> | const std::string & gid,
> | const std::string & size,
> | const std::string & date,
> | const std::string & filename,
> | bool is_dir,
> | bool has_children);
> |
> | Which argument is responsible for telling us what type of file a
> | particular listing is?
> | Is it the flag argument?
>
> if "is_dir" is true, the returned file is a directory
> if "has_children" is true, this is a non empty directory
>
> the "flag" is a string telling whether the file's data is saved
> in the archive (differential archive), if it's EA are saved, and if
> compression is used for that file. If I don't make any mistake, the
> compression ratio is then given.
>
> The type of file is given in the "permission" argument this is the first
> byte ('d' for directory, '-' for plain files, 'b' for block devices, 'c'
> for char devices, 's' for unix socket, 'p' for named pipes, and 'h' for
> plain files linked several times in the directory tree (hard links)
>
> OK, a more detailed call could be added. For now and for historical
> reasons too, it seems to cover all the needs. What particular need do
> you have for that ?
No no, that's perfect. I just wasn't sure. That seems more than simple
enough of course.
>
>
> Thanks for your feedback,
>
> Cheers,
> Denis.
>
> |
> |
> |
> |
> |
> |[...]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFCDeQUpC5CI8gYGlIRAlTVAKC8KmYPicplYa8hRyMM6jFpUIs/UwCeMgrQ
> 21A+a1Bqt7mOyizU9Rv15ww=
> =WTu2
> -----END PGP SIGNATURE-----
>
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> Dar-discussions mailing list
> Dar-discussions-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/dar-discussions
--
Wesley Leggette <[email protected]>
-------------------------------------------------------
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