Topic: Thoughts on the filesystem proposal
Author: gmisocpp@gmail.com
Date: Tue, 8 Jul 2014 05:21:39 -0700 (PDT)
Raw View
------=_Part_71_11015857.1404822099072
Content-Type: text/plain; charset=UTF-8
Hi Everyone
I'd like to encourage a little debate regarding the filesystem proposal.
I've used various C and C#/.NET API's before, but I find filesystem less
intuitive in comparison.
I'm trying to figure out why or if that's fair.
One reason might be that I'm not sure if the filesystem / the
documentation encourages me to write code that's robust:
This example came from the boost example here:
http://www.boost.org/doc/libs/1_55_0/libs/filesystem/example/simple_ls.cpp
fs::path p(fs::current_path());
p = fs::system_complete(argv[1]);
if (fs::is_directory(p)) {
for (fs::directory_iterator dir_itr(p); dir_itr != end_iter; ++dir_itr)
; // etc.
}
In the above code, the init expression of the loop looks decidedly simple
like it wouldn't throw but it can and will and we don't catch it.
Tightening that seems to mean restructuring things quite differently as far
as I can tell.
Here's it more restructured and thrown in some retry logic.as seems
reasonable to not be a toy case.
fs::recursive_directory_iterator it; // Can't be in the try, I need it
after and don't want to nest.
// Bye bye single loop. Always if you want reliability / retry-ability?
for (;;) {
try {
path = get_path_from_user();
it = fs::recursive_directory_iterator(path);
break; // Constructed / moved ok, so continue, don't retry.
}
catch(fs::filesystem_error& ex) {
if (!report_failure( path, ex ))
return; // User wants to give up.
Loop again for another / same path. Things might have changed
now..
}
}
Assuming you get an initial file, you need to know and was there a
permission error on that
first file. Did I just a file or the error?
fs::recursive_directory_iterator_fs_end;
while if (it != fs_end())
{
// So first time in, have we definitely got f file name, what if
there was no permissions for that first file?
// Is there a name even?
fs::directory_entry d = *it; // Users may question what is *it is,
should I hold a reference here, or make a copy anyway?
// If the above statement fails, invalid file permission or out of
memory or what.
do_something(d.path(), d); // Can d.path() now fail also, or did
passing first/*it mean
// I've definitely got something valid here?
// Onto the "next" file entries after the first.
try {
++it; // Might throw if there is a permission problem moving to
the item.
break;
}
catch(fs::filesystem_error& ex) {
if (!report_failure_and_ask_if_to_continue( path, ex ))
break; // User doesn't want to continue to the next file.
if ( fs::is_directory(*it) ) // No permission to drop into
directory. Try to skip over it. Not get stuck on it.
it.no_push(); // Interesting new concept.
++it; // Now should I be checking for errors again Or did I
just signal to skip it.
}
// Which file am I on, I'm not sure.
}
This all fills me with less confidence than many C API's.
*The code above is not given to be remotely correct* just to look plausibly
correct.
It hopefully demonstrates many of the fear points, uncertainty and
mistakes, that new users might have to "get" the filesystem api.
What to catch and where and what not to mask by catch(...) while
leaving things bullet proof isn't obvious to me.
I'm wondering if we can make this API cleaner to avoid all that.
Things like ++it are just too sutble because they will fail.not might fail.
++it is so simple it encourage you to be miss it or be aware it's a file
operation at all.
I'm worried that doesn't make it easy to learn, just easy to learn how to
do the wrong thing?
What do we get in return for using a ++ operator and * etc. and do we
really get it?
And if you eventually decide that try is just too, well trying, with all
the ugly try { ++it; } catch(whatever) code,
a search for the error code version of ++ might be a task.. Ok. It's:
it.increment(error_code); Of course, this is C++.
Fully spelled out, Increment wasn't the first name I thought of. It remains
unintuitive even when I know.
I'm not incrementing an atomic integer. I don't want to wade through
examples of incrementing atomic integers either trying to find examples of
directory iteration
that has robust error handling and that skips the right files or not.
I should have read the manual better, but I've been able to get away with
that more with other API's. That seems to tell me something.
I was dissapointed that my prior experience of other API's counted for
nothing in this task too.
This begs the question, are we standardizing existing practice or something
else?
I could put this down to just not embracing the C++ way, or not reading the
manual, but I'm not new to C++.
I don't mind STL iterators but the iterator vibe here feels wrong and
++/increment feels totally wrong even though I'm not new to C++.
What will new users make of all this?
Are we taking the ++ model to far here?
This experience left me with thinking I could benefit from hearing experts
debate some of these statements: Perhaps they already did.
Will people writing real software really be able to use ++it as easily as
it suggests?
I often read the view that don't make difficult things appear simple unless
they are.
Once you stick on the really required try/catch handling or start to use
increment do things get ugly or better?
Should we do something about some of this? e.g:
remove ++it for encouraging ease beyond reality.
rename increment to find_next because we are not incrementing and we don't
want to read misguided help forever more.
Do objects and scope here get in the way as much as help especially with
try etc introducing a scope and possibly wanting some results outside of
the scope.
Is the "iterator" style interface a good thing here? Why?
Would something more like the following be more intuitive and more like
existing practice to standardize:
error_code find_first(path& path, optional<search_context>& ctx,
optional<directory_entry>&ent) noexcept;
error_code find_next(optional<search_context>& ctx,
optional<directory_entry>& ent) ) noexcept;
I don't know that optional<> is the right thing here or would work, it's
just for exposition. I don't propose another interface really, I'm just
assess if the proposed one is the right one first.
I put no except in to demonstrate a feeling that the user really needs to
check tricky scenarios and having multiple error points might not be
helpful to that.
I'm not recommending that as yet, but just wanted to put the view out there
too.
Have we looked closely to make sure we get the constructs correct so we can
loop efficiently and easily with clarity?
Eric neibler had an example a while back about api's that force memory
allocation etc. That may or may not be relevant here, but I thought I'd
mention that too.
Does the C++ FS API compare well to the C API's performance wise generally?
is there sufficient "real" <filesystem> code out there now that handles
real world directory and network structures that handles alll the error
conditions, like permissions, zero length files, empty folders, etc.? Does
anyone have links to such code that might be public?
What does that code look like when compared against the C type API's it
replaces? Is the C++ code that much clearer? Is it more reliable?
Most of all, are people confident that if standards compliance wasn't the
main motivator to use this new API, would people prefer it over the other
API's they already use, at least for the example given. I'm not sure I
prefer it over the windows
wfindfirsti64, wfindnexti64,_findclose routines but maybe I will once
I've seen some good examples.
I haven't spent nearly enough time with the API to say anything with
confidence but these are my initial concerns. Hopefully the experts on this
blog will know if any of these concerns are valid. Hopefully I'm worrying
over nothing. I know the proposal is changing too, so maybe even if some of
this was a worry it might not be now.
I'm just concerned some of this might go the way of the future api's, that
now appear less shiny to me now with hindsight.
I'd really like to see a text book perfect example of filesystem used to
perform something robustly, like an interactively file backup or zip task
or something that can descend into all folders, handle all permission with
retry options, and handle empty file / folder situations or whatever, and
see how much cleaner the C++ code looks like over a C API that does the
same thing. It'd also be interesting which would be faster / more reliable
and how many "takes" it requires to get that perfect sample correct. Which
examples will new users prefer. etc.
Ultimately I'm not proposing anything here. I'm just trying to see if there
is a problem here. I look forward to reading what other people think on
these subjects and the FS proposal in general. Hopefully this is worry over
nothing and thanks to all that are working on the proposal. I am looking
forward to this feature.
Thanks
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_71_11015857.1404822099072
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Everyone</div><div><br></div><div>I'd like to =
;encourage a little debate regarding the filesystem proposal.</di=
v><div><br></div><div>I've used various C and C#/.NET API's before, but I&n=
bsp;find filesystem less intuitive in comparison. </div><div><br></div=
><div>I'm trying to figure out why or if that's fair.</div><div><br></div><=
div>One reason might be that I'm not sure if the filesystem / the=
documentation encourages me to write code that's robust:</d=
iv><div>This example came from the boost example here:<br><a href=
=3D"http://www.boost.org/doc/libs/1_55_0/libs/filesystem/example/simple_ls.=
cpp">http://www.boost.org/doc/libs/1_55_0/libs/filesystem/example/simple_ls=
..cpp</a></div><div><br></div><p>fs::path p(fs::current_path());<br>p =3D fs=
::system_complete(argv[1]);<br>if (fs::is_directory(p)) {<br> &n=
bsp; for (fs::directory_iterator dir_itr(p); dir_itr !=3D end_iter; ++dir_i=
tr)<br> ; // etc.<br>}<br></p><di=
v>In the above code, the init expression of the loop looks decide=
dly simple like it wouldn't throw but it can and will and we don't catch it=
..</div><div><br></div><div>Tightening that seems to mean restruct=
uring things quite differently as far as I can tell.</div><div>Here's it mo=
re restructured and thrown in some retry logic.as seems reasonable to not b=
e a toy case.</div><div><br></div><div> fs::recursive_directory=
_iterator it; // Can't be in the try, I need it after and don't want t=
o nest.</div><div><br></div><div> // Bye bye single loop.=
Always if you want reliability / retry-ability?</div><div><br></div><div>&=
nbsp; for (;;) {<br> =
try {<br> =
path =3D get_path_from_user();<br> &nbs=
p; it =3D fs::recursive_directory_iterator(path);<b=
r> break;=
// Constructed / moved ok, so continue, don't retry.<br> &=
nbsp; }<br> &nbs=
p; catch(fs::filesystem_error& ex) {<br> &=
nbsp; if (!report_failure( path, ex ))<br>&nb=
sp; =
return; // User wants to give up.</div><div> =
Loop again for another&nbs=
p;/ same path. Things might have changed now..<br> &=
nbsp; }<br> }</div><div><br></div><div>Assumi=
ng you get an initial file, you need to know and was there a permission&nbs=
p;error on that</div><div>first file. Did I just a file or the error?</div>=
<div><br></div><div><div>fs::recursive_directory_iterator_fs_end;</div><div=
>while if (it !=3D fs_end())</div><div>{<br><div> &nb=
sp; // So first time in, have we definitely got f f=
ile name, what if there was no permissions for that first file?</div><div>&=
nbsp; // Is there a name even?</div><di=
v><br></div> fs::directory_entry =
d =3D *it; // Users may question what is *it is, should I hold a reference =
here, or make a copy anyway?</div><div> &=
nbsp; // If the above statement fails, invalid file permission o=
r out of memory or what.</div><div><br></div></div><div> &=
nbsp; do_something(d.path(), d); // Can d.path() now fail=
also, or did passing first/*it mean</div><div> &nbs=
p; // I've definitely got something valid here=
?</div><div><br></div><div> // Ont=
o the "next" file entries after the first.<br> =
try {<br>  =
; ++it; // Might throw if there is a permission problem m=
oving to the item.<br>  =
; break;<br> }<br>&nb=
sp; catch(fs::filesystem_error& ex)=
{<br> if=
(!report_failure_and_ask_if_to_continue( path, ex ))<br> =
br=
eak; // User doesn't want to continue to the next file.<br></div><div><br><=
/div><div>  =
; if ( fs::is_directory(*it) ) // No permission to drop into directory.&nbs=
p;Try to skip over it. Not get stuck on it.<br> &nbs=
p; it.no_push()=
; // Interesting new concept.<br></div><div><br></div><div> &nbs=
p; ++it; // Now should I be=
checking for errors again Or did I just signal to skip it.</div><div> =
; }<br> &n=
bsp; // Which file am I on, I'm not sure.<br> &nb=
sp; }</div><div><br>This all fills me with less confidence than many =
C API's.</div><div>*The code above is not given to be remotely correct=
* just to look plausibly correct.</div><div>It hopefully demonstrates =
many of the fear points, uncertainty and mistakes, that new =
users might have to "get" the filesystem api.</div><div><br>=
</div><div>What to catch and where and what not to mask by catch(=
....) while leaving things bullet proof isn't obvious to me.</div><div>=
I'm wondering if we can make this API cleaner to avoid all that.</div><div>=
Things like ++it are just too sutble because they will fail.not might fail.=
<br>++it is so simple it encourage you to be miss it or be aware it's =
a file operation at all.<br></div><div><br></div><div>I'm worried that does=
n't make it easy to learn, just easy to learn how to do the wrong thin=
g?</div><div>What do we get in return for using a ++ operator and * et=
c. and do we really get it?</div><div><br>And if you eventually decide =
;that try is just too, well trying, with all the ugly try { ++it; } c=
atch(whatever) code,<br>a search for the error code version of ++ migh=
t be a task.. Ok. It's: it.increment(error_code); Of course, this is C++.</=
div><div><br></div><div>Fully spelled out, Increment wasn't the first name =
I thought of. It remains unintuitive even when I know.</div><div>I'm not in=
crementing an atomic integer. I don't want to wade through examples of=
incrementing atomic integers either trying to find examples of d=
irectory iteration</div><div>that has robust error handling and that skips =
the right files or not.</div><div><br></div><div>I should have read th=
e manual better, but I've been able to get away with that more with other A=
PI's. That seems to tell me something.<br>I was dissapointed that my prior =
experience of other API's counted for nothing in this task too.</div><div>T=
his begs the question, are we standardizing existing practice or something =
else?</div><div><br></div><div>I could put this down to just not embracing =
the C++ way, or not reading the manual, but I'm not new to C=
++.</div><div>I don't mind STL iterators but the iterator vi=
be here feels wrong and ++/increment feels totally wrong even though I'm no=
t new to C++.</div><div>What will new users make of all this?</div><di=
v>Are we taking the ++ model to far here?</div><div><br></div><div>This exp=
erience left me with thinking I could benefit from hearing expert=
s debate some of these statements: Perhaps they already did.</div><div><br>=
</div><div>Will people writing real software really be able to use ++it as =
easily as it suggests?</div><div>I often read the view that don't make diff=
icult things appear simple unless they are.<br>Once you stick on the really=
required try/catch handling or start to use increment do things get ugly o=
r better?</div><div>Should we do something about some of this? e.g:</div><d=
iv>remove ++it for encouraging ease beyond reality.</div><div>rename increm=
ent to find_next because we are not incrementing and we =
;don't want to read misguided help forever more.</div><div><br></div><div>D=
o objects and scope here get in the way as much as help especially with try=
etc introducing a scope and possibly wanting some results outside of =
the scope.<br></div><div>Is the "iterator" style interface a=
good thing here? Why?</div><div>Would something more like the followi=
ng be more intuitive and more like existing practice to standardize:</div><=
div> error_code find_first(path& path, optional<se=
arch_context>& ctx, optional<directory_entry>&ent) noexcep=
t;</div><div> error_code find_next(optional<searc=
h_context>& ctx, optional<directory_entry>& ent) ) no=
except;</div><div>I don't know that optional<> is the right thing her=
e or would work, it's just for exposition. I don't propose another interfac=
e really, I'm just assess if the proposed one is the right one first.</div>=
<div>I put no except in to demonstrate a feeling that the user really =
needs to check tricky scenarios and having multiple error points might not =
be helpful to that.</div><div>I'm not recommending that as yet, but just wa=
nted to put the view out there too.</div><div><br></div><div>Have we looked=
closely to make sure we get the constructs correct so we can loop efficien=
tly and easily with clarity?</div><div>Eric neibler had an example a w=
hile back about api's that force memory allocation etc. That may or may not=
be relevant here, but I thought I'd mention that too.</div><div>Does the C=
++ FS API compare well to the C API's performance wise generally?</div=
><div><br></div><div>is there sufficient "real" <filesystem>=
; code out there now that handles real world directory and network structur=
es that handles alll the error conditions, like permissions, zero length fi=
les, empty folders, etc.? Does anyone have links to such code that might be=
public?</div><div><br></div><div>What does that code look like when compar=
ed against the C type API's it replaces? Is the C++ code that much clearer?=
Is it more reliable?</div><div><br></div><div>Most of all, are people conf=
ident that if standards compliance wasn't the main motivator to use this ne=
w API, would people prefer it over the other API's they already use, a=
t least for the example given. I'm not sure I prefer it over the windows</d=
iv><div> wfindfirsti64, wfindnexti64,_findclose rou=
tines but maybe I will once I've seen some good examples.</div><div><br></d=
iv><div><div><div>I haven't spent nearly enough time with the API to say an=
ything with confidence but these are my initial concerns. Hopefully the exp=
erts on this blog will know if any of these concerns are valid. Hopefu=
lly I'm worrying over nothing. I know the proposal is changing too, so mayb=
e even if some of this was a worry it might not be now.</div><div>I'm just =
concerned some of this might go the way of the future api's, that now appea=
r less shiny to me now with hindsight.</div></div><div><br></div></div><div=
>I'd really like to see a text book perfect example of filesystem used =
;to perform something robustly, like an interactively f=
ile backup or zip task or something that can descend into all fol=
ders, handle all permission with retry options, and handle empty file =
/ folder situations or whatever, and see how much cleaner the C++ code look=
s like over a C API that does the same thing. It'd also be interesting whic=
h would be faster / more reliable and how many "takes" it requires to get t=
hat perfect sample correct. Which examples will new users prefer. etc.</div=
><div><br></div><div>Ultimately I'm not proposing anything here. I'm j=
ust trying to see if there is a problem here. I look forward to reading wha=
t other people think on these subjects and the FS proposal in general. Hope=
fully this is worry over nothing and thanks to all that are working on the =
proposal. I am looking forward to this feature.</div><div><br></div><div>Th=
anks</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_71_11015857.1404822099072--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 14 Jul 2014 11:15:23 -0500
Raw View
--047d7bacc66486646204fe299b05
Content-Type: text/plain; charset=UTF-8
On 8 July 2014 07:21, <gmisocpp@gmail.com> wrote:
> is there sufficient "real" <filesystem> code out there now that handles
> real world directory and network structures that handles alll the error
> conditions, like permissions, zero length files, empty folders, etc.? Does
> anyone have links to such code that might be public?
>
You'd probably get better answers on the Boost mailing lists, considering
that the filesystem library has been there for over a decade.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bacc66486646204fe299b05
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 8 July 2014 07:21, <span dir=3D"ltr"><<a href=3D"ma=
ilto:gmisocpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>></span=
> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
<div dir=3D"ltr"><div>is there=C2=A0sufficient=C2=A0"real" <fi=
lesystem> code out there now that handles real world directory and netwo=
rk structures that handles alll the error conditions, like permissions, zer=
o length files, empty folders, etc.? Does anyone have links to such code th=
at might be public?<br>
</div></div></blockquote><div><br></div><div>You'd probably get better =
answers on the Boost mailing lists, considering that the filesystem library=
has been there for over a decade.</div></div>-- <br>=C2=A0Nevin ":-)&=
quot; Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" targ=
et=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bacc66486646204fe299b05--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 14 Jul 2014 10:33:47 -0700 (PDT)
Raw View
------=_Part_201_14109285.1405359227739
Content-Type: text/plain; charset=UTF-8
I've used <filesystem> in one real-world project. Main looks like this:
int main()
{
try
{
....
}
catch (fs::filesystem_error& e)
{
cerr << e.what() << endl;
}
catch (exception& e)
{
cerr << e.what() << endl;
}
return 1;
}
I think exception-based handling of expected errors is wrong and doesn't
result in clean code. Trying to handle individual errors results in lots of
ugly try / catch combos. I don't feel confident I'd properly handle all
errors, the only sane option appears to be to bail out.
Returning errors via a out parameter seems plain wrong too, do we have more
parts of C++ do that?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_201_14109285.1405359227739
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I've used <filesystem> in one real-world projec=
t. Main looks like this:<div><div>int main()</div><div>{</div><div><span cl=
ass=3D"Apple-tab-span" style=3D"white-space:pre"> </span>try</div><div><spa=
n class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>{</div><div><s=
pan class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>...</div><d=
iv><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>}</div>=
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>catch=
(fs::filesystem_error& e)</div><div><span class=3D"Apple-tab-span" sty=
le=3D"white-space:pre"> </span>{</div><div><span class=3D"Apple-tab-span" s=
tyle=3D"white-space:pre"> </span>cerr << e.what() << endl;</di=
v><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>}</=
div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>c=
atch (exception& e)</div><div><span class=3D"Apple-tab-span" style=3D"w=
hite-space:pre"> </span>{</div><div><span class=3D"Apple-tab-span" style=3D=
"white-space:pre"> </span>cerr << e.what() << endl;</div><div>=
<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>}</div><di=
v><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>return 1=
;</div><div>}</div></div><div><br></div><div>I think exception-based handli=
ng of expected errors is wrong and doesn't result in clean code. Trying to =
handle individual errors results in lots of ugly try / catch combos. I don'=
t feel confident I'd properly handle all errors, the only sane option appea=
rs to be to bail out.</div><div>Returning errors via a out parameter seems =
plain wrong too, do we have more parts of C++ do that?</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_201_14109285.1405359227739--
.
Author: gmisocpp@gmail.com
Date: Mon, 14 Jul 2014 18:47:55 -0700 (PDT)
Raw View
------=_Part_1322_4771710.1405388875629
Content-Type: text/plain; charset=UTF-8
On Tuesday, July 15, 2014 5:33:48 AM UTC+12, Olaf van der Spek wrote:
>
> I've used <filesystem> in one real-world project. Main looks like this:
> int main()
> {
> try
> {
> ...
> }
> catch (fs::filesystem_error& e)
> {
> cerr << e.what() << endl;
> }
> catch (exception& e)
> {
> cerr << e.what() << endl;
> }
> return 1;
> }
>
> I think exception-based handling of expected errors is wrong and doesn't
> result in clean code. Trying to handle individual errors results in lots of
> ugly try / catch combos. I don't feel confident I'd properly handle all
> errors, the only sane option appears to be to bail out.
>
Yes this exactly the type of problem I'm concerned about. But also the
naming etc. Quite a lot of things concern me here really.
I'm very unsold that the "C++ way" of using ++/Increment and
* and recursive_directory_iterator etc. will lead to better/fast/reliable
code more than using the non standard code we use today such as the C style
findfirst type functions I mentioned from Windows?
I'm sure Linux will have it's own API too that may well compare a little
too favourably here too?
It may be that filesystem proposal just needs some basic restructuring to
make everything I worry about here all well and good; or maybe I'm wrong in
this analysis and the API is fine, but I want to draw some analysis to it
from people with better API design experience than me.
I don't feel as warm and fuzzy about these aspects of the filesystem API as
I think I should. More specifically:
I think that things that can and will in all likelihood fail, should expose
that reality in a way that makes that both obvious and easy to handle,
since in my opinion you almost always will want to handle it. I think
Bjarne has some design theory about not trying to surface over things that
shouldn't be. I don't a link for that, but that's the vibe of the thing
I feel might being violated here.
Perhaps another way of saying that is that an API that does something
significant should look significant and not look like something else. The
use of ++ here is a standout example of that and Increment falls short
there too IMHO.
The filesystem proposal doesn't satisfy me in any of these regards. I am
assuming this is because it's trying to model the C++ iterator way of doing
things?
But bluntly, perhaps it shouldn't?
I don't see what I get out of this for what I pay for in obscurity. I can't
see how I can abstractly iterate over a file list as I can a vector and not
be aware of the difference, since I have to handle the exceptions that come
from that. I don't see what using ++ for iteration or * gives me here at
all except obscurity.
++ just invites an exception while looking like a simple pointer increment.
and Increment looks like it's doing something atomic but simple, while it
isn't that either and it isn't that searchable. None of these easily and
simple return me something I can use or an error.
The use of exceptions feel like they are not helping me but hindering me.
Something like:
file_or_error = find_next_file(seach_context);// noexcept perhaps.
seems much more readable to me.
These are the questions I'd like to see some experts debate. If I'm wrong
about all of this, I will be more than happy. I just feel the filesystem
API needs to improve on the usability of the C API's it is proposing to
replace and I'm not seeing that it does in this particular area yet.
I am appreciative of the efforts behind the proposal, I just hope through a
conversation about these elements the proposal can be improved or I people
can help me to see that the things I'm worrying about aren't a concern.
> Returning errors via a out parameter seems plain wrong too, do we have
> more parts of C++ do that?
>
Thanks
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1322_4771710.1405388875629
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, July 15, 2014 5:33:48 AM UTC+12, Olaf =
van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">I've used&=
nbsp;<filesystem> in one real-world project. Main looks like this:<di=
v><div>int main()</div><div>{</div><div><span style=3D"white-space: pre;"> =
</span>try</div><div><span style=3D"white-space: pre;"> </span>{</div><div>=
<span style=3D"white-space: pre;"> </span>...</div><div><span style=3D"whi=
te-space: pre;"> </span>}</div><div><span style=3D"white-space: pre;"> </sp=
an>catch (fs::filesystem_error& e)</div><div><span style=3D"white-space=
: pre;"> </span>{</div><div><span style=3D"white-space: pre;"> </span>cerr=
<< e.what() << endl;</div><div><span style=3D"white-space: pre=
;"> </span>}</div><div><span style=3D"white-space: pre;"> </span>catch (exc=
eption& e)</div><div><span style=3D"white-space: pre;"> </span>{</div><=
div><span style=3D"white-space: pre;"> </span>cerr << e.what() <&=
lt; endl;</div><div><span style=3D"white-space: pre;"> </span>}</div><div><=
span style=3D"white-space: pre;"> </span>return 1;</div><div>}</div></div><=
div><br></div><div>I think exception-based handling of expected errors is w=
rong and doesn't result in clean code. Trying to handle individual errors r=
esults in lots of ugly try / catch combos. I don't feel confident I'd prope=
rly handle all errors, the only sane option appears to be to bail out.</div=
></div></blockquote><div><br></div><div>Yes this exactly the type of proble=
m I'm concerned about. But also the naming etc. Quite a lot of things conce=
rn me here really.</div><div><br></div><div>I'm very unsold that the "=
C++ way" of using ++/Increment and * and recursive_directory_iter=
ator etc. will lead to better/fast/reliable code more than u=
sing the non standard code we use today such as the C style findfirst type =
functions I mentioned from Windows?</div><div><br></div><div>I'm sure Linux=
will have it's own API too that may well compare a little too favourably h=
ere too?</div><div><br></div><div>It may be that filesystem proposal j=
ust needs some basic restructuring to make everything I worry about he=
re all well and good; or maybe I'm wrong in this analysis and the API is fi=
ne, but I want to draw some analysis to it from people with better API desi=
gn experience than me.</div><div><br></div><div>I don't feel as warm a=
nd fuzzy about these aspects of the filesystem API as I think I should=
.. More specifically:</div><div><br></div><div>I think that things that=
can and will in all likelihood fail, should expose that reality in a way t=
hat makes that both obvious and easy to handle, since in my opinion you alm=
ost always will want to handle it. I think Bjarne has some design theory ab=
out not trying to surface over things that shouldn't be. I don't a lin=
k for that, but that's the vibe of the thing I feel might being v=
iolated here.</div><div><br></div><div>Perhaps another way of saying that i=
s that an API that does something significant should look significant =
and not look like something else. The use of ++ here is a standout exa=
mple of that and Increment falls short there too IMHO.</div><div><br></div>=
<div>The filesystem proposal doesn't satisfy me in any of these regards. I =
am assuming this is because it's trying to model the C++ iterator way =
of doing things?</div><div><br></div><div>But bluntly, perhaps it shouldn't=
?</div><div><br></div><div>I don't see what I get out of this for what=
I pay for in obscurity. I can't see how I can abstractly iterate over a fi=
le list as I can a vector and not be aware of the difference, since I have =
to handle the exceptions that come from that. I don't see what using&n=
bsp;++ for iteration or * gives me here at all except obscurity.</div>=
<div><br></div><div>++ just invites an exception while looking like a simpl=
e pointer increment.</div><div>and Increment looks like it's doing somethin=
g atomic but simple, while it isn't that either and it isn't that searchabl=
e. None of these easily and simple return me something I can use or an erro=
r.</div><div><br></div><div><div>The use of exceptions feel like they =
are not helping me but hindering me. </div><div><br></div></div><=
div>Something like:</div><div>file_or_error =3D find_next_file(seach_contex=
t);// noexcept perhaps.</div><div>seems much more readable to me.</div><div=
><br></div><div>These are the questions I'd like to see some experts debate=
.. If I'm wrong about all of this, I will be more than happy. I just feel th=
e filesystem API needs to improve on the usability of the C API's it i=
s proposing to replace and I'm not seeing that it does in this particular a=
rea yet.</div><div><br></div><div>I am appreciative of the efforts behind t=
he proposal, I just hope through a conversation about these elements the pr=
oposal can be improved or I people can help me to see that the things I'm w=
orrying about aren't a concern.</div><div> </div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-=
left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: =
solid;"><div dir=3D"ltr"><div>Returning errors via a out parameter seems pl=
ain wrong too, do we have more parts of C++ do that?</div></div></blockquot=
e><div><br></div><div><div>Thanks</div> </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1322_4771710.1405388875629--
.