------=_Part_822_15662801.1366488702920
Content-Type: text/plain; charset=ISO-8859-1

The filesystem library proposal
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html#hard_link_count>uses
the plain uintmax_t for representing the file size. In my opinion it would
be better to define types similiar to the ones used by
std::chrono::duratation, that represents information about used units. What
are your thought about this idea?

--

---
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/?hl=en.



------=_Part_822_15662801.1366488702920
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n350=
5.html#hard_link_count">filesystem library proposal </a>uses the plain uint=
max_t for representing the file size. In my opinion it would be better to d=
efine types similiar to the ones used by std::chrono::duratation, that repr=
esents information about used units. What are your thought about this idea?=
<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_822_15662801.1366488702920--

.

------=_Part_692_21347653.1366489619575
Content-Type: text/plain; charset=ISO-8859-1

On Saturday, April 20, 2013 1:11:42 PM UTC-7, toma...@gmail.com wrote:
>
> The filesystem library proposal
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html#hard_link_count>uses
> the plain uintmax_t for representing the file size. In my opinion it would
> be better to define types similiar to the ones used by
> std::chrono::duratation, that represents information about used units. What
> are your thought about this idea?
>

Why? There's only one unit of interest here: bytes. With times, users will
have different needs for different timescales. Sometimes you only need
second accuracy. Other times, you need milliseconds or nanoseconds. So you
need some flexibility.

The filesystem only has bytes. So everyone uses bytes. Yes, you may want to
*display* the information in different forms, but the data from the
filesystem should be in bytes.

--

---
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/?hl=en.



------=_Part_692_21347653.1366489619575
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Saturday, April 20, 2013 1:11:42 PM UTC-7, toma...@gmail.com wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">The <a href=3D"http://www.open-std.=
org/jtc1/sc22/wg21/docs/papers/2013/n3505.html#hard_link_count" target=3D"_=
blank">filesystem library proposal </a>uses the plain uintmax_t for represe=
nting the file size. In my opinion it would be better to define types simil=
iar to the ones used by std::chrono::duratation, that represents informatio=
n about used units. What are your thought about this idea?<br></blockquote>=
<div><br>Why? There's only one unit of interest here: bytes. With times, us=
ers will have different needs for different timescales. Sometimes you only =
need second accuracy. Other times, you need milliseconds or nanoseconds. So=
 you need some flexibility.<br><br>The filesystem only has bytes. So everyo=
ne uses bytes. Yes, you may want to <i>display</i> the information in diffe=
rent forms, but the data from the filesystem should be in bytes.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_692_21347653.1366489619575--

.

------=_Part_351_13814058.1366495672397
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu sobota, 20 kwietnia 2013 22:26:59 UTC+2 u=BFytkownik Nicol Bolas=20
napisa=B3:
>
> On Saturday, April 20, 2013 1:11:42 PM UTC-7, toma...@gmail.com wrote:
>>
>> The filesystem library proposal=20
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html#hard=
_link_count>uses=20
>> the plain uintmax_t for representing the file size. In my opinion it wou=
ld=20
>> be better to define types similiar to the ones used by=20
>> std::chrono::duratation, that represents information about used units. W=
hat=20
>> are your thought about this idea?
>>
>
> Why? There's only one unit of interest here: bytes. With times, users wil=
l=20
> have different needs for different timescales. Sometimes you only need=20
> second accuracy. Other times, you need milliseconds or nanoseconds. So yo=
u=20
> need some flexibility.
>
> The filesystem only has bytes. So everyone uses bytes. Yes, you may want=
=20
> to *display* the information in different forms, but the data from the=20
> filesystem should be in bytes.
>


For the same reason that minutes and hours are definied in the standard -=
=20
the user convenience. If the resize_file will use byte (ratio<1,1>) and=20
define additional units instead of plain uintmax_t, then the user will be=
=20
able to say:
resize_file(path, megabytes(n));
instead of:
resize_file(path, n * 1024 * 1024);
or:
resize_file(path, n* 1048576);

--=20

---=20
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 e=
mail 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-proposa=
ls/?hl=3Den.



------=_Part_351_13814058.1366495672397
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu sobota, 20 kwietnia 2013 22:26:59 UTC+2 u=BFytkownik Nicol B=
olas napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Saturday, Ap=
ril 20, 2013 1:11:42 PM UTC-7, <a>toma...@gmail.com</a> wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex">The <a href=3D"http://www.open-std.org/jtc1/sc22=
/wg21/docs/papers/2013/n3505.html#hard_link_count" target=3D"_blank">filesy=
stem library proposal </a>uses the plain uintmax_t for representing the fil=
e size. In my opinion it would be better to define types similiar to the on=
es used by std::chrono::duratation, that represents information about used =
units. What are your thought about this idea?<br></blockquote><div><br>Why?=
 There's only one unit of interest here: bytes. With times, users will have=
 different needs for different timescales. Sometimes you only need second a=
ccuracy. Other times, you need milliseconds or nanoseconds. So you need som=
e flexibility.<br><br>The filesystem only has bytes. So everyone uses bytes=
.. Yes, you may want to <i>display</i> the information in different forms, b=
ut the data from the filesystem should be in bytes.<br></div></blockquote><=
div><br><br>For the same reason that minutes and hours are definied in the =
standard - the user convenience. If the resize_file will use byte (ratio&lt=
;1,1&gt;) and define additional units instead of plain uintmax_t, then the =
user will be able to say:<br>resize_file(path, megabytes(n));<br>instead of=
:<br>resize_file(path, n * 1024 * 1024);<br>or:<br>resize_file(path, n* 104=
8576);<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_351_13814058.1366495672397--

.

--089e013a0a1eb110ca04dad231b3
Content-Type: text/plain; charset=ISO-8859-1

On 21 April 2013 01:07, <tomaszkam@gmail.com> wrote:

> For the same reason that minutes and hours are definied in the standard -
> the user convenience. If the resize_file will use byte (ratio<1,1>) and
> define additional units instead of plain uintmax_t, then the user will be
> able to say:
> resize_file(path, megabytes(n));
> instead of:
> resize_file(path, n * 1024 * 1024);
> or:
> resize_file(path, n* 1048576);
>
>
>
>
I think that is an excellent idea.

--

---
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/?hl=en.



--089e013a0a1eb110ca04dad231b3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 21 April 2013 01:07,  <span dir=3D"ltr">&lt;<a href=3D"mailto:to=
maszkam@gmail.com" target=3D"_blank">tomaszkam@gmail.com</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
For the same reason that minutes and hours are definied in the standard - t=
he user convenience. If the resize_file will use byte (ratio&lt;1,1&gt;) an=
d define additional units instead of plain uintmax_t, then the user will be=
 able to say:<br>
<div>resize_file(path, megabytes(n));<br>instead of:<br>resize_file(path, n=
 * 1024 * 1024);<br>or:<br>resize_file(path, n* 1048576);<br></div><div cla=
ss=3D"HOEnZb"><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>I think that is an exc=
ellent idea. <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e013a0a1eb110ca04dad231b3--

.

------=_Part_916_27549516.1366524813471
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le samedi 20 avril 2013 22:11:42 UTC+2, toma...@gmail.com a =E9crit :
>
> The filesystem library proposal=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html#hard_=
link_count>uses=20
> the plain uintmax_t for representing the file size. In my opinion it woul=
d=20
> be better to define types similiar to the ones used by=20
> std::chrono::duratation, that represents information about used units. Wh=
at=20
> are your thought about this idea?
>

I am also against returning uintmax_t, for the simple reason that almost=20
nothing should return uintmax_t. If you need a big enough integral type,=20
call it off_t or something. In order to guide the use of uintmax_t, imagine=
=20
an implementation that provides extended integer types of 128 bits, 256=20
bits, up to 1048576 bits (the standard forces me to pick a limit and call=
=20
that one uintmax_t). Do we really want to return a million bit long integer=
=20
for the size of a file? uintmax_t makes more sense as an argument type,=20
where you don't control what users might throw at you.

--=20

---=20
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 e=
mail 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-proposa=
ls/?hl=3Den.



------=_Part_916_27549516.1366524813471
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le samedi 20 avril 2013 22:11:42 UTC+2, toma...@gmail.com a =E9crit&nbsp;:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">The <a href=3D"http://www.open-=
std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html#hard_link_count" target=
=3D"_blank">filesystem library proposal </a>uses the plain uintmax_t for re=
presenting the file size. In my opinion it would be better to define types =
similiar to the ones used by std::chrono::duratation, that represents infor=
mation about used units. What are your thought about this idea?<br></blockq=
uote><div><br>I am also against returning uintmax_t, for the simple reason =
that almost nothing should return uintmax_t. If you need a big enough integ=
ral type, call it off_t or something. In order to guide the use of uintmax_=
t, imagine an implementation that provides extended integer types of 128 bi=
ts, 256 bits, up to 1048576 bits (the standard forces me to pick a limit an=
d call that one uintmax_t). Do we really want to return a million bit long =
integer for the size of a file? uintmax_t makes more sense as an argument t=
ype, where you don't control what users might throw at you.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_916_27549516.1366524813471--

.

------=_Part_14_8197459.1366529490861
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

On Saturday, April 20, 2013 3:07:52 PM UTC-7, toma...@gmail.com wrote:
>
> W dniu sobota, 20 kwietnia 2013 22:26:59 UTC+2 u=BFytkownik Nicol Bolas=
=20
> napisa=B3:
>>
>> On Saturday, April 20, 2013 1:11:42 PM UTC-7, toma...@gmail.com wrote:
>>>
>>> The filesystem library proposal=20
>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html#har=
d_link_count>uses=20
>>> the plain uintmax_t for representing the file size. In my opinion it wo=
uld=20
>>> be better to define types similiar to the ones used by=20
>>> std::chrono::duratation, that represents information about used units. =
What=20
>>> are your thought about this idea?
>>>
>>
>> Why? There's only one unit of interest here: bytes. With times, users=20
>> will have different needs for different timescales. Sometimes you only n=
eed=20
>> second accuracy. Other times, you need milliseconds or nanoseconds. So y=
ou=20
>> need some flexibility.
>>
>> The filesystem only has bytes. So everyone uses bytes. Yes, you may want=
=20
>> to *display* the information in different forms, but the data from the=
=20
>> filesystem should be in bytes.
>>
>
>
> For the same reason that minutes and hours are definied in the standard -=
=20
> the user convenience. If the resize_file will use byte (ratio<1,1>) and=
=20
> define additional units instead of plain uintmax_t, then the user will be=
=20
> able to say:
> resize_file(path, megabytes(n));
> instead of:
> resize_file(path, n * 1024 * 1024);
> or:
> resize_file(path, n* 1048576);
>

I don't see what's stopping you from being able to use ratios and such to=
=20
implement such a `megabytes` function yourself. How would `resize_file`=20
taking a different parameter help or hinder you from doing this?

--=20

---=20
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 e=
mail 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-proposa=
ls/?hl=3Den.



------=_Part_14_8197459.1366529490861
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

On Saturday, April 20, 2013 3:07:52 PM UTC-7, toma...@gmail.com wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">W dniu sobota, 20 kwietnia 2013 22:=
26:59 UTC+2 u=BFytkownik Nicol Bolas napisa=B3:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex">On Saturday, April 20, 2013 1:11:42 PM UTC-7, <a>toma...@gmail.=
com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">The <a href=3D"http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html#hard_link_coun=
t" target=3D"_blank">filesystem library proposal </a>uses the plain uintmax=
_t for representing the file size. In my opinion it would be better to defi=
ne types similiar to the ones used by std::chrono::duratation, that represe=
nts information about used units. What are your thought about this idea?<br=
></blockquote><div><br>Why? There's only one unit of interest here: bytes. =
With times, users will have different needs for different timescales. Somet=
imes you only need second accuracy. Other times, you need milliseconds or n=
anoseconds. So you need some flexibility.<br><br>The filesystem only has by=
tes. So everyone uses bytes. Yes, you may want to <i>display</i> the inform=
ation in different forms, but the data from the filesystem should be in byt=
es.<br></div></blockquote><div><br><br>For the same reason that minutes and=
 hours are definied in the standard - the user convenience. If the resize_f=
ile will use byte (ratio&lt;1,1&gt;) and define additional units instead of=
 plain uintmax_t, then the user will be able to say:<br>resize_file(path, m=
egabytes(n));<br>instead of:<br>resize_file(path, n * 1024 * 1024);<br>or:<=
br>resize_file(path, n* 1048576);<br></div></blockquote><div><br>I don't se=
e what's stopping you from being able to use ratios and such to implement s=
uch a `megabytes` function yourself. How would `resize_file` taking a diffe=
rent parameter help or hinder you from doing this?<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_14_8197459.1366529490861--

.

------=_Part_1161_20664955.1366538001909
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu niedziela, 21 kwietnia 2013 09:31:30 UTC+2 u=BFytkownik Nicol Bolas=
=20
napisa=B3:
>
> On Saturday, April 20, 2013 3:07:52 PM UTC-7, toma...@gmail.com wrote:
>>
>> W dniu sobota, 20 kwietnia 2013 22:26:59 UTC+2 u=BFytkownik Nicol Bolas=
=20
>> napisa=B3:
>>>
>>> On Saturday, April 20, 2013 1:11:42 PM UTC-7, toma...@gmail.com wrote:
>>>>
>>>> The filesystem library proposal=20
>>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html#ha=
rd_link_count>uses=20
>>>> the plain uintmax_t for representing the file size. In my opinion it w=
ould=20
>>>> be better to define types similiar to the ones used by=20
>>>> std::chrono::duratation, that represents information about used units.=
 What=20
>>>> are your thought about this idea?
>>>>
>>>
>>> Why? There's only one unit of interest here: bytes. With times, users=
=20
>>> will have different needs for different timescales. Sometimes you only =
need=20
>>> second accuracy. Other times, you need milliseconds or nanoseconds. So =
you=20
>>> need some flexibility.
>>>
>>> The filesystem only has bytes. So everyone uses bytes. Yes, you may wan=
t=20
>>> to *display* the information in different forms, but the data from the=
=20
>>> filesystem should be in bytes.
>>>
>>
>>
>> For the same reason that minutes and hours are definied in the standard =
-=20
>> the user convenience. If the resize_file will use byte (ratio<1,1>) and=
=20
>> define additional units instead of plain uintmax_t, then the user will b=
e=20
>> able to say:
>> resize_file(path, megabytes(n));
>> instead of:
>> resize_file(path, n * 1024 * 1024);
>> or:
>> resize_file(path, n* 1048576);
>>
>
> I don't see what's stopping you from being able to use ratios and such to=
=20
> implement such a `megabytes` function yourself. How would `resize_file`=
=20
> taking a different parameter help or hinder you from doing this?
>

megabtyes was not assumed to be a function, Lets assume that there will be=
=20
similiar typedefs to duration in file system.
typedef file_size<uintmax_t, ration<1> > bytes;
typedef file_size<uintmax_t, ration<1024, 1> > kilobytes; //propably using=
=20
std::kibi
typedef file_size<uintmax_t, ration<1048576, 1> > megabytes; //propably=20
using std::mega
....and so on
The should be implicit conversions from the smaller units to the greater=20
units. The file system functions should be definied as retunring/accepting=
=20
bytes.

Then if the user has a code has a code similiar to this:
inline uintmat_t megabytes(uintmax_t m)
{
  return m * 1048576;
}

/* some code */
std::size_t minimal_file_size =3D 5; //minimal file size in megabytes, or=
=20
function parameters

/* some other code with uses of file_size, example:
if (file_size(path) < megabytes(minimal_file_size))
or=20
resize_file(path, megabytes(minimal_file_size)).

Lets then assume that the user wants specify the minimal file size in=20
kilobytes (because more accuracy is needed), then he must find and change=
=20
all of the uses of minimal_file size to conform this change.
But if the libarry will use types that represents both amount and the=20
units, then the first line will look like:

std::megabytes minimal_file_size(5)
/*no conversions between units will be handled in conversions between=20
types, so the example will look like:
if (file_size(path) < minimal_file_size)
or=20
resize_file(path, minimal_file_size).

So if the user decide to change the minimal file size to kilobytes then=20
only one change will be needed:
std::kilobytes minimal_file_size =3D std::megabytes(5) + std::kilobytes(200=
);

It is all about using meaningull types instead of build ins.

--=20

---=20
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 e=
mail 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-proposa=
ls/?hl=3Den.



------=_Part_1161_20664955.1366538001909
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu niedziela, 21 kwietnia 2013 09:31:30 UTC+2 u=BFytkownik Nico=
l Bolas napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Saturday,=
 April 20, 2013 3:07:52 PM UTC-7, <a>toma...@gmail.com</a> wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex">W dniu sobota, 20 kwietnia 2013 22:26:59 UTC+=
2 u=BFytkownik Nicol Bolas napisa=B3:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
">On Saturday, April 20, 2013 1:11:42 PM UTC-7, <a>toma...@gmail.com</a> wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">The <a href=3D"http://www.open-=
std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html#hard_link_count" target=
=3D"_blank">filesystem library proposal </a>uses the plain uintmax_t for re=
presenting the file size. In my opinion it would be better to define types =
similiar to the ones used by std::chrono::duratation, that represents infor=
mation about used units. What are your thought about this idea?<br></blockq=
uote><div><br>Why? There's only one unit of interest here: bytes. With time=
s, users will have different needs for different timescales. Sometimes you =
only need second accuracy. Other times, you need milliseconds or nanosecond=
s. So you need some flexibility.<br><br>The filesystem only has bytes. So e=
veryone uses bytes. Yes, you may want to <i>display</i> the information in =
different forms, but the data from the filesystem should be in bytes.<br></=
div></blockquote><div><br><br>For the same reason that minutes and hours ar=
e definied in the standard - the user convenience. If the resize_file will =
use byte (ratio&lt;1,1&gt;) and define additional units instead of plain ui=
ntmax_t, then the user will be able to say:<br>resize_file(path, megabytes(=
n));<br>instead of:<br>resize_file(path, n * 1024 * 1024);<br>or:<br>resize=
_file(path, n* 1048576);<br></div></blockquote><div><br>I don't see what's =
stopping you from being able to use ratios and such to implement such a `me=
gabytes` function yourself. How would `resize_file` taking a different para=
meter help or hinder you from doing this?<br></div></blockquote><div><br>me=
gabtyes was not assumed to be a function, Lets assume that there will be si=
miliar typedefs to duration in file system.<br>typedef file_size&lt;uintmax=
_t, ration&lt;1&gt; &gt; bytes;<br>typedef file_size&lt;uintmax_t, ration&l=
t;1024, 1&gt; &gt; kilobytes; //propably using std::kibi<br>typedef file_si=
ze&lt;uintmax_t, ration&lt;1048576, 1&gt; &gt; megabytes; //propably using =
std::mega<br>...and so on<br>The should be implicit conversions from the sm=
aller units to the greater units. The file system functions should be defin=
ied as retunring/accepting bytes.<br><br>Then if the user has a code has a =
code similiar to this:<br>inline uintmat_t megabytes(uintmax_t m)<br>{<br>&=
nbsp; return m * 1048576;<br>}<br><br>/* some code */<br>std::size_t minima=
l_file_size =3D 5; //minimal file size in megabytes, or function parameters=
<br><br>/* some other code with uses of file_size, example:<br>if (file_siz=
e(path) &lt; megabytes(minimal_file_size))<br>or <br>resize_file(path, mega=
bytes(minimal_file_size)).<br><br>Lets then assume that the user wants spec=
ify the minimal file size in kilobytes (because more accuracy is needed), t=
hen he must find and change all of the uses of minimal_file size to conform=
 this change.<br>But if the libarry will use types that represents both amo=
unt and the units, then the first line will look like:<br><br>std::megabyte=
s minimal_file_size(5)<br>/*no conversions between units will be handled in=
 conversions between types, so the example will look like:<br>if (file_size=
(path) &lt; minimal_file_size)<br>or <br>resize_file(path, minimal_file_siz=
e).<br><br>So if the user decide to change the minimal file size to kilobyt=
es then only one change will be needed:<br>std::kilobytes minimal_file_size=
 =3D std::megabytes(5) + std::kilobytes(200);<br><br>It is all about using =
meaningull types instead of build ins.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1161_20664955.1366538001909--

.

------=_Part_1201_23900734.1366539978343
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



On Sunday, April 21, 2013 2:53:21 AM UTC-7, toma...@gmail.com wrote:
>
>
>
> W dniu niedziela, 21 kwietnia 2013 09:31:30 UTC+2 u=BFytkownik Nicol Bola=
s=20
> napisa=B3:
>>
>> On Saturday, April 20, 2013 3:07:52 PM UTC-7, toma...@gmail.com wrote:
>>>
>>> W dniu sobota, 20 kwietnia 2013 22:26:59 UTC+2 u=BFytkownik Nicol Bolas=
=20
>>> napisa=B3:
>>>>
>>>> On Saturday, April 20, 2013 1:11:42 PM UTC-7, toma...@gmail.com wrote:
>>>>>
>>>>> The filesystem library proposal=20
>>>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html#h=
ard_link_count>uses=20
>>>>> the plain uintmax_t for representing the file size. In my opinion it =
would=20
>>>>> be better to define types similiar to the ones used by=20
>>>>> std::chrono::duratation, that represents information about used units=
.. What=20
>>>>> are your thought about this idea?
>>>>>
>>>>
>>>> Why? There's only one unit of interest here: bytes. With times, users=
=20
>>>> will have different needs for different timescales. Sometimes you only=
 need=20
>>>> second accuracy. Other times, you need milliseconds or nanoseconds. So=
 you=20
>>>> need some flexibility.
>>>>
>>>> The filesystem only has bytes. So everyone uses bytes. Yes, you may=20
>>>> want to *display* the information in different forms, but the data=20
>>>> from the filesystem should be in bytes.
>>>>
>>>
>>>
>>> For the same reason that minutes and hours are definied in the standard=
=20
>>> - the user convenience. If the resize_file will use byte (ratio<1,1>) a=
nd=20
>>> define additional units instead of plain uintmax_t, then the user will =
be=20
>>> able to say:
>>> resize_file(path, megabytes(n));
>>> instead of:
>>> resize_file(path, n * 1024 * 1024);
>>> or:
>>> resize_file(path, n* 1048576);
>>>
>>
>> I don't see what's stopping you from being able to use ratios and such t=
o=20
>> implement such a `megabytes` function yourself. How would `resize_file`=
=20
>> taking a different parameter help or hinder you from doing this?
>>
>
> megabtyes was not assumed to be a function, Lets assume that there will b=
e=20
> similiar typedefs to duration in file system.
> typedef file_size<uintmax_t, ration<1> > bytes;
> typedef file_size<uintmax_t, ration<1024, 1> > kilobytes; //propably usin=
g=20
> std::kibi
> typedef file_size<uintmax_t, ration<1048576, 1> > megabytes; //propably=
=20
> using std::mega
> ...and so on
>

There are likely going to be other things that have sizes you might want to=
=20
measure in bytes. Why restrict it to a file size? No reason the networking=
=20
layer and so forth shouldn't be able to have byte sizes measured in=20
kilobytes or megabytes, right?

If you're going to do it, then it should be *comprehensive* within the=20
standard, not piecemeal.
=20

> The should be implicit conversions from the smaller units to the greater=
=20
> units. The file system functions should be definied as retunring/acceptin=
g=20
> bytes.
>
> Then if the user has a code has a code similiar to this:
> inline uintmat_t megabytes(uintmax_t m)
> {
>   return m * 1048576;
> }
>
> /* some code */
> std::size_t minimal_file_size =3D 5; //minimal file size in megabytes, or=
=20
> function parameters
>
> /* some other code with uses of file_size, example:
> if (file_size(path) < megabytes(minimal_file_size))
> or=20
> resize_file(path, megabytes(minimal_file_size)).
>

These could just as easily be `megabytes(...).count()`. Or you could just=
=20
have an `operator uintmax_t` to convert to the actual byte size.

I see no reason why the filesystem API itself needs to be dealing in these=
=20
objects directly.

--=20

---=20
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 e=
mail 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-proposa=
ls/?hl=3Den.



------=_Part_1201_23900734.1366539978343
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>On Sunday, April 21, 2013 2:53:21 AM UTC-7, toma...@gmail.com wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><br><br>W dniu niedziela, 21 =
kwietnia 2013 09:31:30 UTC+2 u=BFytkownik Nicol Bolas napisa=B3:<blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex">On Saturday, April 20, 2013 3:07:52 PM UTC-7, =
<a>toma...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">W dn=
iu sobota, 20 kwietnia 2013 22:26:59 UTC+2 u=BFytkownik Nicol Bolas napisa=
=B3:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">On Saturday, April 20, 2013 1:1=
1:42 PM UTC-7, <a>toma...@gmail.com</a> wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">The <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/paper=
s/2013/n3505.html#hard_link_count" target=3D"_blank">filesystem library pro=
posal </a>uses the plain uintmax_t for representing the file size. In my op=
inion it would be better to define types similiar to the ones used by std::=
chrono::duratation, that represents information about used units. What are =
your thought about this idea?<br></blockquote><div><br>Why? There's only on=
e unit of interest here: bytes. With times, users will have different needs=
 for different timescales. Sometimes you only need second accuracy. Other t=
imes, you need milliseconds or nanoseconds. So you need some flexibility.<b=
r><br>The filesystem only has bytes. So everyone uses bytes. Yes, you may w=
ant to <i>display</i> the information in different forms, but the data from=
 the filesystem should be in bytes.<br></div></blockquote><div><br><br>For =
the same reason that minutes and hours are definied in the standard - the u=
ser convenience. If the resize_file will use byte (ratio&lt;1,1&gt;) and de=
fine additional units instead of plain uintmax_t, then the user will be abl=
e to say:<br>resize_file(path, megabytes(n));<br>instead of:<br>resize_file=
(path, n * 1024 * 1024);<br>or:<br>resize_file(path, n* 1048576);<br></div>=
</blockquote><div><br>I don't see what's stopping you from being able to us=
e ratios and such to implement such a `megabytes` function yourself. How wo=
uld `resize_file` taking a different parameter help or hinder you from doin=
g this?<br></div></blockquote><div><br>megabtyes was not assumed to be a fu=
nction, Lets assume that there will be similiar typedefs to duration in fil=
e system.<br>typedef file_size&lt;uintmax_t, ration&lt;1&gt; &gt; bytes;<br=
>typedef file_size&lt;uintmax_t, ration&lt;1024, 1&gt; &gt; kilobytes; //pr=
opably using std::kibi<br>typedef file_size&lt;uintmax_t, ration&lt;1048576=
, 1&gt; &gt; megabytes; //propably using std::mega<br>...and so on<br></div=
></blockquote><div><br>There are likely going to be other things that have =
sizes you might want to measure in bytes. Why restrict it to a file size? N=
o reason the networking layer and so forth shouldn't be able to have byte s=
izes measured in kilobytes or megabytes, right?<br><br>If you're going to d=
o it, then it should be <i>comprehensive</i> within the standard, not piece=
meal.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>The =
should be implicit conversions from the smaller units to the greater units.=
 The file system functions should be definied as retunring/accepting bytes.=
<br><br>Then if the user has a code has a code similiar to this:<br>inline =
uintmat_t megabytes(uintmax_t m)<br>{<br>&nbsp; return m * 1048576;<br>}<br=
><br>/* some code */<br>std::size_t minimal_file_size =3D 5; //minimal file=
 size in megabytes, or function parameters<br><br>/* some other code with u=
ses of file_size, example:<br>if (file_size(path) &lt; megabytes(minimal_fi=
le_size))<br>or <br>resize_file(path, megabytes(minimal_file_size)).<br></d=
iv></blockquote><div><br>These could just as easily be `megabytes(...).coun=
t()`. Or you could just have an `operator uintmax_t` to convert to the actu=
al byte size.<br><br>I see no reason why the filesystem API itself needs to=
 be dealing in these objects directly.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1201_23900734.1366539978343--

.

------=_Part_99_20106131.1366541690644
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu niedziela, 21 kwietnia 2013 12:26:18 UTC+2 u=BFytkownik Nicol Bolas=
=20
napisa=B3:
>
>
>
> On Sunday, April 21, 2013 2:53:21 AM UTC-7, toma...@gmail.com wrote:
>>
>>
>>
>> W dniu niedziela, 21 kwietnia 2013 09:31:30 UTC+2 u=BFytkownik Nicol Bol=
as=20
>> napisa=B3:
>>>
>>> On Saturday, April 20, 2013 3:07:52 PM UTC-7, toma...@gmail.com wrote:
>>>>
>>>> W dniu sobota, 20 kwietnia 2013 22:26:59 UTC+2 u=BFytkownik Nicol Bola=
s=20
>>>> napisa=B3:
>>>>>
>>>>> On Saturday, April 20, 2013 1:11:42 PM UTC-7, toma...@gmail.com wrote=
:
>>>>>>
>>>>>> The filesystem library proposal=20
>>>>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html#=
hard_link_count>uses=20
>>>>>> the plain uintmax_t for representing the file size. In my opinion it=
 would=20
>>>>>> be better to define types similiar to the ones used by=20
>>>>>> std::chrono::duratation, that represents information about used unit=
s. What=20
>>>>>> are your thought about this idea?
>>>>>>
>>>>>
>>>>> Why? There's only one unit of interest here: bytes. With times, users=
=20
>>>>> will have different needs for different timescales. Sometimes you onl=
y need=20
>>>>> second accuracy. Other times, you need milliseconds or nanoseconds. S=
o you=20
>>>>> need some flexibility.
>>>>>
>>>>> The filesystem only has bytes. So everyone uses bytes. Yes, you may=
=20
>>>>> want to *display* the information in different forms, but the data=20
>>>>> from the filesystem should be in bytes.
>>>>>
>>>>
>>>>
>>>> For the same reason that minutes and hours are definied in the standar=
d=20
>>>> - the user convenience. If the resize_file will use byte (ratio<1,1>) =
and=20
>>>> define additional units instead of plain uintmax_t, then the user will=
 be=20
>>>> able to say:
>>>> resize_file(path, megabytes(n));
>>>> instead of:
>>>> resize_file(path, n * 1024 * 1024);
>>>> or:
>>>> resize_file(path, n* 1048576);
>>>>
>>>
>>> I don't see what's stopping you from being able to use ratios and such=
=20
>>> to implement such a `megabytes` function yourself. How would `resize_fi=
le`=20
>>> taking a different parameter help or hinder you from doing this?
>>>
>>
>> megabtyes was not assumed to be a function, Lets assume that there will=
=20
>> be similiar typedefs to duration in file system.
>> typedef file_size<uintmax_t, ration<1> > bytes;
>> typedef file_size<uintmax_t, ration<1024, 1> > kilobytes; //propably=20
>> using std::kibi
>> typedef file_size<uintmax_t, ration<1048576, 1> > megabytes; //propably=
=20
>> using std::mega
>> ...and so on
>>
>
> There are likely going to be other things that have sizes you might want=
=20
> to measure in bytes. Why restrict it to a file size? No reason the=20
> networking layer and so forth shouldn't be able to have byte sizes measur=
ed=20
> in kilobytes or megabytes, right?
>
> If you're going to do it, then it should be *comprehensive* within the=20
> standard, not piecemeal.
> =20
>
>> The should be implicit conversions from the smaller units to the greater=
=20
>> units. The file system functions should be definied as retunring/accepti=
ng=20
>> bytes.
>>
>> Then if the user has a code has a code similiar to this:
>> inline uintmat_t megabytes(uintmax_t m)
>> {
>>   return m * 1048576;
>> }
>>
>> /* some code */
>> std::size_t minimal_file_size =3D 5; //minimal file size in megabytes, o=
r=20
>> function parameters
>>
>> /* some other code with uses of file_size, example:
>> if (file_size(path) < megabytes(minimal_file_size))
>> or=20
>> resize_file(path, megabytes(minimal_file_size)).
>>
>
> These could just as easily be `megabytes(...).count()`. Or you could just=
=20
> have an `operator uintmax_t` to convert to the actual byte size.
>
> I see no reason why the filesystem API itself needs to be dealing in thes=
e=20
> objects directly.
>
=20
Because dealing with the file size is a part of the filesystem API, so the=
=20
classes to represent it propertly (in a type-safe, less error prone meaner)=
=20
should be part of the library and then well integrated with rest of it.

--=20

---=20
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 e=
mail 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-proposa=
ls/?hl=3Den.



------=_Part_99_20106131.1366541690644
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu niedziela, 21 kwietnia 2013 12:26:18 UTC+2 u=BFytkownik Nico=
l Bolas napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On S=
unday, April 21, 2013 2:53:21 AM UTC-7, <a>toma...@gmail.com</a> wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><br><br>W dniu niedziela, 21 kwietnia 2=
013 09:31:30 UTC+2 u=BFytkownik Nicol Bolas napisa=B3:<blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex">On Saturday, April 20, 2013 3:07:52 PM UTC-7, <a>toma...=
@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">W dniu sobota,=
 20 kwietnia 2013 22:26:59 UTC+2 u=BFytkownik Nicol Bolas napisa=B3:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex">On Saturday, April 20, 2013 1:11:42 PM UTC=
-7, <a>toma...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>The <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n35=
05.html#hard_link_count" target=3D"_blank">filesystem library proposal </a>=
uses the plain uintmax_t for representing the file size. In my opinion it w=
ould be better to define types similiar to the ones used by std::chrono::du=
ratation, that represents information about used units. What are your thoug=
ht about this idea?<br></blockquote><div><br>Why? There's only one unit of =
interest here: bytes. With times, users will have different needs for diffe=
rent timescales. Sometimes you only need second accuracy. Other times, you =
need milliseconds or nanoseconds. So you need some flexibility.<br><br>The =
filesystem only has bytes. So everyone uses bytes. Yes, you may want to <i>=
display</i> the information in different forms, but the data from the files=
ystem should be in bytes.<br></div></blockquote><div><br><br>For the same r=
eason that minutes and hours are definied in the standard - the user conven=
ience. If the resize_file will use byte (ratio&lt;1,1&gt;) and define addit=
ional units instead of plain uintmax_t, then the user will be able to say:<=
br>resize_file(path, megabytes(n));<br>instead of:<br>resize_file(path, n *=
 1024 * 1024);<br>or:<br>resize_file(path, n* 1048576);<br></div></blockquo=
te><div><br>I don't see what's stopping you from being able to use ratios a=
nd such to implement such a `megabytes` function yourself. How would `resiz=
e_file` taking a different parameter help or hinder you from doing this?<br=
></div></blockquote><div><br>megabtyes was not assumed to be a function, Le=
ts assume that there will be similiar typedefs to duration in file system.<=
br>typedef file_size&lt;uintmax_t, ration&lt;1&gt; &gt; bytes;<br>typedef f=
ile_size&lt;uintmax_t, ration&lt;1024, 1&gt; &gt; kilobytes; //propably usi=
ng std::kibi<br>typedef file_size&lt;uintmax_t, ration&lt;1048576, 1&gt; &g=
t; megabytes; //propably using std::mega<br>...and so on<br></div></blockqu=
ote><div><br>There are likely going to be other things that have sizes you =
might want to measure in bytes. Why restrict it to a file size? No reason t=
he networking layer and so forth shouldn't be able to have byte sizes measu=
red in kilobytes or megabytes, right?<br><br>If you're going to do it, then=
 it should be <i>comprehensive</i> within the standard, not piecemeal.<br>&=
nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>The should be impli=
cit conversions from the smaller units to the greater units. The file syste=
m functions should be definied as retunring/accepting bytes.<br><br>Then if=
 the user has a code has a code similiar to this:<br>inline uintmat_t megab=
ytes(uintmax_t m)<br>{<br>&nbsp; return m * 1048576;<br>}<br><br>/* some co=
de */<br>std::size_t minimal_file_size =3D 5; //minimal file size in megaby=
tes, or function parameters<br><br>/* some other code with uses of file_siz=
e, example:<br>if (file_size(path) &lt; megabytes(minimal_file_size))<br>or=
 <br>resize_file(path, megabytes(minimal_file_size)).<br></div></blockquote=
><div><br>These could just as easily be `megabytes(...).count()`. Or you co=
uld just have an `operator uintmax_t` to convert to the actual byte size.<b=
r><br>I see no reason why the filesystem API itself needs to be dealing in =
these objects directly.<br></div></blockquote><div>&nbsp;<br>Because dealin=
g with the file size is a part of the filesystem API, so the classes to rep=
resent it propertly (in a type-safe, less error prone meaner) should be par=
t of the library and then well integrated with rest of it.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_99_20106131.1366541690644--

.

------=_Part_2087_31370058.1366618887107
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

On Sunday, April 21, 2013 3:54:50 AM UTC-7, toma...@gmail.com wrote:
>
>
>
> W dniu niedziela, 21 kwietnia 2013 12:26:18 UTC+2 u=BFytkownik Nicol Bola=
s=20
> napisa=B3:
>>
>>
>>
>> On Sunday, April 21, 2013 2:53:21 AM UTC-7, toma...@gmail.com wrote:
>>>
>>>
>>>
>>> W dniu niedziela, 21 kwietnia 2013 09:31:30 UTC+2 u=BFytkownik Nicol Bo=
las=20
>>> napisa=B3:
>>>>
>>>> On Saturday, April 20, 2013 3:07:52 PM UTC-7, toma...@gmail.com wrote:
>>>>>
>>>>> W dniu sobota, 20 kwietnia 2013 22:26:59 UTC+2 u=BFytkownik Nicol Bol=
as=20
>>>>> napisa=B3:
>>>>>>
>>>>>> On Saturday, April 20, 2013 1:11:42 PM UTC-7, toma...@gmail.comwrote=
:
>>>>>>>
>>>>>>> The filesystem library proposal=20
>>>>>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html=
#hard_link_count>uses=20
>>>>>>> the plain uintmax_t for representing the file size. In my opinion i=
t would=20
>>>>>>> be better to define types similiar to the ones used by=20
>>>>>>> std::chrono::duratation, that represents information about used uni=
ts. What=20
>>>>>>> are your thought about this idea?
>>>>>>>
>>>>>>
>>>>>> Why? There's only one unit of interest here: bytes. With times, user=
s=20
>>>>>> will have different needs for different timescales. Sometimes you on=
ly need=20
>>>>>> second accuracy. Other times, you need milliseconds or nanoseconds. =
So you=20
>>>>>> need some flexibility.
>>>>>>
>>>>>> The filesystem only has bytes. So everyone uses bytes. Yes, you may=
=20
>>>>>> want to *display* the information in different forms, but the data=
=20
>>>>>> from the filesystem should be in bytes.
>>>>>>
>>>>>
>>>>>
>>>>> For the same reason that minutes and hours are definied in the=20
>>>>> standard - the user convenience. If the resize_file will use byte=20
>>>>> (ratio<1,1>) and define additional units instead of plain uintmax_t, =
then=20
>>>>> the user will be able to say:
>>>>> resize_file(path, megabytes(n));
>>>>> instead of:
>>>>> resize_file(path, n * 1024 * 1024);
>>>>> or:
>>>>> resize_file(path, n* 1048576);
>>>>>
>>>>
>>>> I don't see what's stopping you from being able to use ratios and such=
=20
>>>> to implement such a `megabytes` function yourself. How would `resize_f=
ile`=20
>>>> taking a different parameter help or hinder you from doing this?
>>>>
>>>
>>> megabtyes was not assumed to be a function, Lets assume that there will=
=20
>>> be similiar typedefs to duration in file system.
>>> typedef file_size<uintmax_t, ration<1> > bytes;
>>> typedef file_size<uintmax_t, ration<1024, 1> > kilobytes; //propably=20
>>> using std::kibi
>>> typedef file_size<uintmax_t, ration<1048576, 1> > megabytes; //propably=
=20
>>> using std::mega
>>> ...and so on
>>>
>>
>> There are likely going to be other things that have sizes you might want=
=20
>> to measure in bytes. Why restrict it to a file size? No reason the=20
>> networking layer and so forth shouldn't be able to have byte sizes measu=
red=20
>> in kilobytes or megabytes, right?
>>
>> If you're going to do it, then it should be *comprehensive* within the=
=20
>> standard, not piecemeal.
>> =20
>>
>>> The should be implicit conversions from the smaller units to the greate=
r=20
>>> units. The file system functions should be definied as retunring/accept=
ing=20
>>> bytes.
>>>
>>> Then if the user has a code has a code similiar to this:
>>> inline uintmat_t megabytes(uintmax_t m)
>>> {
>>>   return m * 1048576;
>>> }
>>>
>>> /* some code */
>>> std::size_t minimal_file_size =3D 5; //minimal file size in megabytes, =
or=20
>>> function parameters
>>>
>>> /* some other code with uses of file_size, example:
>>> if (file_size(path) < megabytes(minimal_file_size))
>>> or=20
>>> resize_file(path, megabytes(minimal_file_size)).
>>>
>>
>> These could just as easily be `megabytes(...).count()`. Or you could jus=
t=20
>> have an `operator uintmax_t` to convert to the actual byte size.
>>
>> I see no reason why the filesystem API itself needs to be dealing in=20
>> these objects directly.
>>
> =20
> Because dealing with the file size is a part of the filesystem API, so th=
e=20
> classes to represent it propertly (in a type-safe, less error prone meane=
r)=20
> should be part of the library and then well integrated with rest of it.
>

Why should the *networking* library use something called "file_size"? It=20
doesn't necessarily deal in files at all. Furthermore, the filesystem=20
proposal may live in its own namespace; we don't want to have networking=20
use stuff from the filesystem namespace.

Byte counts like this are something that networking, files, and other=20
things share. It shouldn't be part of the filesystem; it's a utility that=
=20
both use.

To the extent that the filesystem API should be taking such a thing instead=
=20
of just an integer at all, of course...

--=20

---=20
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 e=
mail 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-proposa=
ls/?hl=3Den.



------=_Part_2087_31370058.1366618887107
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

On Sunday, April 21, 2013 3:54:50 AM UTC-7, toma...@gmail.com wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><br><br>W dniu niedziela, 21 kwietnia=
 2013 12:26:18 UTC+2 u=BFytkownik Nicol Bolas napisa=B3:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><br><br>On Sunday, April 21, 2013 2:53:21 AM UTC-7, =
<a>toma...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>=
<br>W dniu niedziela, 21 kwietnia 2013 09:31:30 UTC+2 u=BFytkownik Nicol Bo=
las napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Saturday, April 20=
, 2013 3:07:52 PM UTC-7, <a>toma...@gmail.com</a> wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">W dniu sobota, 20 kwietnia 2013 22:26:59 UTC+2 u=BFy=
tkownik Nicol Bolas napisa=B3:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Sa=
turday, April 20, 2013 1:11:42 PM UTC-7, <a>toma...@gmail.com</a> wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">The <a href=3D"http://www.open-std.org=
/jtc1/sc22/wg21/docs/papers/2013/n3505.html#hard_link_count" target=3D"_bla=
nk">filesystem library proposal </a>uses the plain uintmax_t for representi=
ng the file size. In my opinion it would be better to define types similiar=
 to the ones used by std::chrono::duratation, that represents information a=
bout used units. What are your thought about this idea?<br></blockquote><di=
v><br>Why? There's only one unit of interest here: bytes. With times, users=
 will have different needs for different timescales. Sometimes you only nee=
d second accuracy. Other times, you need milliseconds or nanoseconds. So yo=
u need some flexibility.<br><br>The filesystem only has bytes. So everyone =
uses bytes. Yes, you may want to <i>display</i> the information in differen=
t forms, but the data from the filesystem should be in bytes.<br></div></bl=
ockquote><div><br><br>For the same reason that minutes and hours are defini=
ed in the standard - the user convenience. If the resize_file will use byte=
 (ratio&lt;1,1&gt;) and define additional units instead of plain uintmax_t,=
 then the user will be able to say:<br>resize_file(path, megabytes(n));<br>=
instead of:<br>resize_file(path, n * 1024 * 1024);<br>or:<br>resize_file(pa=
th, n* 1048576);<br></div></blockquote><div><br>I don't see what's stopping=
 you from being able to use ratios and such to implement such a `megabytes`=
 function yourself. How would `resize_file` taking a different parameter he=
lp or hinder you from doing this?<br></div></blockquote><div><br>megabtyes =
was not assumed to be a function, Lets assume that there will be similiar t=
ypedefs to duration in file system.<br>typedef file_size&lt;uintmax_t, rati=
on&lt;1&gt; &gt; bytes;<br>typedef file_size&lt;uintmax_t, ration&lt;1024, =
1&gt; &gt; kilobytes; //propably using std::kibi<br>typedef file_size&lt;ui=
ntmax_t, ration&lt;1048576, 1&gt; &gt; megabytes; //propably using std::meg=
a<br>...and so on<br></div></blockquote><div><br>There are likely going to =
be other things that have sizes you might want to measure in bytes. Why res=
trict it to a file size? No reason the networking layer and so forth should=
n't be able to have byte sizes measured in kilobytes or megabytes, right?<b=
r><br>If you're going to do it, then it should be <i>comprehensive</i> with=
in the standard, not piecemeal.<br>&nbsp;</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div>The should be implicit conversions from the smaller units =
to the greater units. The file system functions should be definied as retun=
ring/accepting bytes.<br><br>Then if the user has a code has a code similia=
r to this:<br>inline uintmat_t megabytes(uintmax_t m)<br>{<br>&nbsp; return=
 m * 1048576;<br>}<br><br>/* some code */<br>std::size_t minimal_file_size =
=3D 5; //minimal file size in megabytes, or function parameters<br><br>/* s=
ome other code with uses of file_size, example:<br>if (file_size(path) &lt;=
 megabytes(minimal_file_size))<br>or <br>resize_file(path, megabytes(minima=
l_file_size)).<br></div></blockquote><div><br>These could just as easily be=
 `megabytes(...).count()`. Or you could just have an `operator uintmax_t` t=
o convert to the actual byte size.<br><br>I see no reason why the filesyste=
m API itself needs to be dealing in these objects directly.<br></div></bloc=
kquote><div>&nbsp;<br>Because dealing with the file size is a part of the f=
ilesystem API, so the classes to represent it propertly (in a type-safe, le=
ss error prone meaner) should be part of the library and then well integrat=
ed with rest of it.<br></div></blockquote><div><br>Why should the <i>networ=
king</i> library use something called "file_size"? It doesn't necessarily d=
eal in files at all. Furthermore, the filesystem proposal may live in its o=
wn namespace; we don't want to have networking use stuff from the filesyste=
m namespace.<br><br>Byte counts like this are something that networking, fi=
les, and other things share. It shouldn't be part of the filesystem; it's a=
 utility that both use.<br><br>To the extent that the filesystem API should=
 be taking such a thing instead of just an integer at all, of course...<br>=
</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2087_31370058.1366618887107--

.

------=_Part_427_16317225.1366644008422
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I was thinking about that last week with the same idea: providing a class=
=20
based on the std::chrono::duration model to represent a file size.
I think that it's currently missing and that could be very useful.
I've suggested to include the binary prefixes in the standard library too:=
=20
https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/binar=
y/std-proposals/dQg-Jlghw9U/XHRIkf7GT7gJ
If people thinks it could be a good idea, I would be happy to help you to=
=20
design/write such a proposal if you need help.


Le samedi 20 avril 2013 22:11:42 UTC+2, toma...@gmail.com a =E9crit :
>
> The filesystem library proposal=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html#hard_=
link_count>uses=20
> the plain uintmax_t for representing the file size. In my opinion it woul=
d=20
> be better to define types similiar to the ones used by=20
> std::chrono::duratation, that represents information about used units. Wh=
at=20
> are your thought about this idea?
>

--=20

---=20
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 e=
mail 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-proposa=
ls/?hl=3Den.



------=_Part_427_16317225.1366644008422
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I was thinking about that last week with the same idea: providing a class b=
ased on the std::chrono::duration model to represent a file size.<br>I thin=
k that it's currently missing and that could be very useful.<br>I've sugges=
ted to include the binary prefixes in the standard library too: https://gro=
ups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/binary/std-propo=
sals/dQg-Jlghw9U/XHRIkf7GT7gJ<br>If people thinks it could be a good idea, =
I would be happy to help you to design/write such a proposal if you need he=
lp.<br><br><br>Le samedi 20 avril 2013 22:11:42 UTC+2, toma...@gmail.com a =
=E9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The <a href=3D"h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html#hard_link=
_count" target=3D"_blank">filesystem library proposal </a>uses the plain ui=
ntmax_t for representing the file size. In my opinion it would be better to=
 define types similiar to the ones used by std::chrono::duratation, that re=
presents information about used units. What are your thought about this ide=
a?<br></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_427_16317225.1366644008422--

.

--047d7b10c81b3afd9304daf62ede
Content-Type: text/plain; charset=ISO-8859-1

+1.
I like the idea a lot.


On Sat, Apr 20, 2013 at 11:16 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 21 April 2013 01:07, <tomaszkam@gmail.com> wrote:
>
>> For the same reason that minutes and hours are definied in the standard -
>> the user convenience. If the resize_file will use byte (ratio<1,1>) and
>> define additional units instead of plain uintmax_t, then the user will be
>> able to say:
>> resize_file(path, megabytes(n));
>> instead of:
>> resize_file(path, n * 1024 * 1024);
>> or:
>> resize_file(path, n* 1048576);
>>
>>
>>
>>
> I think that is an excellent idea.
>
>  --
>
> ---
> 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/?hl=en.
>
>
>



--
Prof. J. Daniel Garcia
Associate Professor - Profesor Titular de Universidad
Computer Architecture Group
University Carlos III of Madrid
Avda. Universidad Carlos III, 22
28270 Colmenarejo, Madrid. Spain
Tel: +34 918561316
Fax: +34 91 856 1270
e-mail: josedaniel.garcia@uc3m.es
Web: http://www.arcos.inf.uc3m.es/~jdaniel

Linked-In: http://es.linkedin.com/in/jdanielgarcia
Twitter: http://www.twitter.com/jdgarciauc3m

--

---
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/?hl=en.



--047d7b10c81b3afd9304daf62ede
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">+1.<div style>I like the idea a lot.</div></div><div class=
=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, Apr 20, 2013 at=
 11:16 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.=
voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt=
;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 21 April 2013 0=
1:07,  <span dir=3D"ltr">&lt;<a href=3D"mailto:tomaszkam@gmail.com" target=
=3D"_blank">tomaszkam@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
For the same reason that minutes and hours are definied in the standard - t=
he user convenience. If the resize_file will use byte (ratio&lt;1,1&gt;) an=
d define additional units instead of plain uintmax_t, then the user will be=
 able to say:<br>


<div>resize_file(path, megabytes(n));<br>instead of:<br>resize_file(path, n=
 * 1024 * 1024);<br>or:<br>resize_file(path, n* 1048576);<br></div><div><di=
v>

<p></p>

<br><br></div></div></blockquote><div><br></div></div><div>I think that is =
an excellent idea. <br></div></div><br></div></div><div class=3D"HOEnZb"><d=
iv class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
Prof. J. Daniel Garcia<br>Associate Professor - Profesor Titular de Univers=
idad<br>Computer Architecture Group<br>University Carlos III of Madrid<br>

Avda. Universidad Carlos III, 22<br>28270 Colmenarejo, Madrid. Spain<br>Tel=
: +34 918561316<br>Fax: +34 91 856 1270<br>e-mail: <a href=3D"mailto:joseda=
niel.garcia@uc3m.es" target=3D"_blank">josedaniel.garcia@uc3m.es</a><br>Web=
: <a href=3D"http://www.arcos.inf.uc3m.es/~jdaniel" target=3D"_blank">http:=
//www.arcos.inf.uc3m.es/~jdaniel</a><br>

=A0<br>Linked-In: <a href=3D"http://es.linkedin.com/in/jdanielgarcia" targe=
t=3D"_blank">http://es.linkedin.com/in/jdanielgarcia</a><br>Twitter:=A0<a h=
ref=3D"http://www.twitter.com/jdgarciauc3m" target=3D"_blank">http://www.tw=
itter.com/jdgarciauc3m</a>
</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b10c81b3afd9304daf62ede--

.

------=_Part_1466_19576920.1366741973393
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

So just rename it to bytes_count and define in namespace std, but I think=
=20
that it should go then to separate proposla,

Also after reading the (http://isocpp.org/files/papers/N3642.pdf) i think=
=20
that there should be operators B, KiB, MiB, GiB, TiB definied in=20
std::literals::byte_literals that it will be possible to write 10MiB=20
instead of std::megabytes(10). Also the names may be futer discussed.

W dniu poniedzia=B3ek, 22 kwietnia 2013 10:21:27 UTC+2 u=BFytkownik Nicol B=
olas=20
napisa=B3:
>
> On Sunday, April 21, 2013 3:54:50 AM UTC-7, toma...@gmail.com wrote:
>>
>>
>>
>> W dniu niedziela, 21 kwietnia 2013 12:26:18 UTC+2 u=BFytkownik Nicol Bol=
as=20
>> napisa=B3:
>>>
>>>
>>>
>>> On Sunday, April 21, 2013 2:53:21 AM UTC-7, toma...@gmail.com wrote:
>>>>
>>>>
>>>>
>>>> W dniu niedziela, 21 kwietnia 2013 09:31:30 UTC+2 u=BFytkownik Nicol=
=20
>>>> Bolas napisa=B3:
>>>>>
>>>>> On Saturday, April 20, 2013 3:07:52 PM UTC-7, toma...@gmail.com wrote=
:
>>>>>>
>>>>>> W dniu sobota, 20 kwietnia 2013 22:26:59 UTC+2 u=BFytkownik Nicol Bo=
las=20
>>>>>> napisa=B3:
>>>>>>>
>>>>>>> On Saturday, April 20, 2013 1:11:42 PM UTC-7, toma...@gmail.comwrot=
e:
>>>>>>>>
>>>>>>>> The filesystem library proposal=20
>>>>>>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.htm=
l#hard_link_count>uses=20
>>>>>>>> the plain uintmax_t for representing the file size. In my opinion =
it would=20
>>>>>>>> be better to define types similiar to the ones used by=20
>>>>>>>> std::chrono::duratation, that represents information about used un=
its. What=20
>>>>>>>> are your thought about this idea?
>>>>>>>>
>>>>>>>
>>>>>>> Why? There's only one unit of interest here: bytes. With times,=20
>>>>>>> users will have different needs for different timescales. Sometimes=
 you=20
>>>>>>> only need second accuracy. Other times, you need milliseconds or=20
>>>>>>> nanoseconds. So you need some flexibility.
>>>>>>>
>>>>>>> The filesystem only has bytes. So everyone uses bytes. Yes, you may=
=20
>>>>>>> want to *display* the information in different forms, but the data=
=20
>>>>>>> from the filesystem should be in bytes.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> For the same reason that minutes and hours are definied in the=20
>>>>>> standard - the user convenience. If the resize_file will use byte=20
>>>>>> (ratio<1,1>) and define additional units instead of plain uintmax_t,=
 then=20
>>>>>> the user will be able to say:
>>>>>> resize_file(path, megabytes(n));
>>>>>> instead of:
>>>>>> resize_file(path, n * 1024 * 1024);
>>>>>> or:
>>>>>> resize_file(path, n* 1048576);
>>>>>>
>>>>>
>>>>> I don't see what's stopping you from being able to use ratios and suc=
h=20
>>>>> to implement such a `megabytes` function yourself. How would `resize_=
file`=20
>>>>> taking a different parameter help or hinder you from doing this?
>>>>>
>>>>
>>>> megabtyes was not assumed to be a function, Lets assume that there wil=
l=20
>>>> be similiar typedefs to duration in file system.
>>>> typedef file_size<uintmax_t, ration<1> > bytes;
>>>> typedef file_size<uintmax_t, ration<1024, 1> > kilobytes; //propably=
=20
>>>> using std::kibi
>>>> typedef file_size<uintmax_t, ration<1048576, 1> > megabytes; //propabl=
y=20
>>>> using std::mega
>>>> ...and so on
>>>>
>>>
>>> There are likely going to be other things that have sizes you might wan=
t=20
>>> to measure in bytes. Why restrict it to a file size? No reason the=20
>>> networking layer and so forth shouldn't be able to have byte sizes meas=
ured=20
>>> in kilobytes or megabytes, right?
>>>
>>> If you're going to do it, then it should be *comprehensive* within the=
=20
>>> standard, not piecemeal.
>>> =20
>>>
>>>> The should be implicit conversions from the smaller units to the=20
>>>> greater units. The file system functions should be definied as=20
>>>> retunring/accepting bytes.
>>>>
>>>> Then if the user has a code has a code similiar to this:
>>>> inline uintmat_t megabytes(uintmax_t m)
>>>> {
>>>>   return m * 1048576;
>>>> }
>>>>
>>>> /* some code */
>>>> std::size_t minimal_file_size =3D 5; //minimal file size in megabytes,=
 or=20
>>>> function parameters
>>>>
>>>> /* some other code with uses of file_size, example:
>>>> if (file_size(path) < megabytes(minimal_file_size))
>>>> or=20
>>>> resize_file(path, megabytes(minimal_file_size)).
>>>>
>>>
>>> These could just as easily be `megabytes(...).count()`. Or you could=20
>>> just have an `operator uintmax_t` to convert to the actual byte size.
>>>
>>> I see no reason why the filesystem API itself needs to be dealing in=20
>>> these objects directly.
>>>
>> =20
>> Because dealing with the file size is a part of the filesystem API, so=
=20
>> the classes to represent it propertly (in a type-safe, less error prone=
=20
>> meaner) should be part of the library and then well integrated with rest=
 of=20
>> it.
>>
>
> Why should the *networking* library use something called "file_size"? It=
=20
> doesn't necessarily deal in files at all. Furthermore, the filesystem=20
> proposal may live in its own namespace; we don't want to have networking=
=20
> use stuff from the filesystem namespace.
>
> Byte counts like this are something that networking, files, and other=20
> things share. It shouldn't be part of the filesystem; it's a utility that=
=20
> both use.
>
> To the extent that the filesystem API should be taking such a thing=20
> instead of just an integer at all, of course...
>

--=20

---=20
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 e=
mail 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-proposa=
ls/?hl=3Den.



------=_Part_1466_19576920.1366741973393
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

So just rename it to bytes_count and define in namespace std, but I think t=
hat it should go then to separate proposla,<br><br>Also after reading the (=
http://isocpp.org/files/papers/N3642.pdf) i think that there should be oper=
ators B, KiB, MiB, GiB, TiB definied in std::literals::byte_literals that i=
t will be possible to write 10MiB instead of std::megabytes(10). Also the n=
ames may be futer discussed.<br><br>W dniu poniedzia=B3ek, 22 kwietnia 2013=
 10:21:27 UTC+2 u=BFytkownik Nicol Bolas napisa=B3:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">On Sunday, April 21, 2013 3:54:50 AM UTC-7, <a>toma...=
@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>W dniu=
 niedziela, 21 kwietnia 2013 12:26:18 UTC+2 u=BFytkownik Nicol Bolas napisa=
=B3:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><br><br>On Sunday, April 21, 20=
13 2:53:21 AM UTC-7, <a>toma...@gmail.com</a> wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><br><br>W dniu niedziela, 21 kwietnia 2013 09:31:30 UTC+2 =
u=BFytkownik Nicol Bolas napisa=B3:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>On Saturday, April 20, 2013 3:07:52 PM UTC-7, <a>toma...@gmail.com</a> wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">W dniu sobota, 20 kwietnia 2013 =
22:26:59 UTC+2 u=BFytkownik Nicol Bolas napisa=B3:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">On Saturday, April 20, 2013 1:11:42 PM UTC-7, <a>toma...@gma=
il.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">The <a href=3D"htt=
p://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html#hard_link_c=
ount" target=3D"_blank">filesystem library proposal </a>uses the plain uint=
max_t for representing the file size. In my opinion it would be better to d=
efine types similiar to the ones used by std::chrono::duratation, that repr=
esents information about used units. What are your thought about this idea?=
<br></blockquote><div><br>Why? There's only one unit of interest here: byte=
s. With times, users will have different needs for different timescales. So=
metimes you only need second accuracy. Other times, you need milliseconds o=
r nanoseconds. So you need some flexibility.<br><br>The filesystem only has=
 bytes. So everyone uses bytes. Yes, you may want to <i>display</i> the inf=
ormation in different forms, but the data from the filesystem should be in =
bytes.<br></div></blockquote><div><br><br>For the same reason that minutes =
and hours are definied in the standard - the user convenience. If the resiz=
e_file will use byte (ratio&lt;1,1&gt;) and define additional units instead=
 of plain uintmax_t, then the user will be able to say:<br>resize_file(path=
, megabytes(n));<br>instead of:<br>resize_file(path, n * 1024 * 1024);<br>o=
r:<br>resize_file(path, n* 1048576);<br></div></blockquote><div><br>I don't=
 see what's stopping you from being able to use ratios and such to implemen=
t such a `megabytes` function yourself. How would `resize_file` taking a di=
fferent parameter help or hinder you from doing this?<br></div></blockquote=
><div><br>megabtyes was not assumed to be a function, Lets assume that ther=
e will be similiar typedefs to duration in file system.<br>typedef file_siz=
e&lt;uintmax_t, ration&lt;1&gt; &gt; bytes;<br>typedef file_size&lt;uintmax=
_t, ration&lt;1024, 1&gt; &gt; kilobytes; //propably using std::kibi<br>typ=
edef file_size&lt;uintmax_t, ration&lt;1048576, 1&gt; &gt; megabytes; //pro=
pably using std::mega<br>...and so on<br></div></blockquote><div><br>There =
are likely going to be other things that have sizes you might want to measu=
re in bytes. Why restrict it to a file size? No reason the networking layer=
 and so forth shouldn't be able to have byte sizes measured in kilobytes or=
 megabytes, right?<br><br>If you're going to do it, then it should be <i>co=
mprehensive</i> within the standard, not piecemeal.<br>&nbsp;</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div>The should be implicit conversions fro=
m the smaller units to the greater units. The file system functions should =
be definied as retunring/accepting bytes.<br><br>Then if the user has a cod=
e has a code similiar to this:<br>inline uintmat_t megabytes(uintmax_t m)<b=
r>{<br>&nbsp; return m * 1048576;<br>}<br><br>/* some code */<br>std::size_=
t minimal_file_size =3D 5; //minimal file size in megabytes, or function pa=
rameters<br><br>/* some other code with uses of file_size, example:<br>if (=
file_size(path) &lt; megabytes(minimal_file_size))<br>or <br>resize_file(pa=
th, megabytes(minimal_file_size)).<br></div></blockquote><div><br>These cou=
ld just as easily be `megabytes(...).count()`. Or you could just have an `o=
perator uintmax_t` to convert to the actual byte size.<br><br>I see no reas=
on why the filesystem API itself needs to be dealing in these objects direc=
tly.<br></div></blockquote><div>&nbsp;<br>Because dealing with the file siz=
e is a part of the filesystem API, so the classes to represent it propertly=
 (in a type-safe, less error prone meaner) should be part of the library an=
d then well integrated with rest of it.<br></div></blockquote><div><br>Why =
should the <i>networking</i> library use something called "file_size"? It d=
oesn't necessarily deal in files at all. Furthermore, the filesystem propos=
al may live in its own namespace; we don't want to have networking use stuf=
f from the filesystem namespace.<br><br>Byte counts like this are something=
 that networking, files, and other things share. It shouldn't be part of th=
e filesystem; it's a utility that both use.<br><br>To the extent that the f=
ilesystem API should be taking such a thing instead of just an integer at a=
ll, of course...<br></div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1466_19576920.1366741973393--

.

------=_Part_438_29310125.1372165990376
Content-Type: text/plain; charset=ISO-8859-1

Hi. I would like to know whether you plan to effectively write a proposal
related to file size or byte count for the Chicago or the Rapperswill
meeting. If you need some help, as I am very interested into such a thing,
just ask me.
--
Vincent Reverdy*
Phd Student @ Laboratory Universe and Theories**
Cosmology and General Relativity Group
Observatory of Paris-Meudon, France*

--

---
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_438_29310125.1372165990376
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi. I would like to know whether you plan to effectively write a proposal r=
elated to file size or byte count for the Chicago or the Rapperswill meetin=
g. If you need some help, as I am very interested into such a thing, just a=
sk me.<br>-- <br>Vincent Reverdy<i><br>Phd Student @ Laboratory Universe an=
d Theories</i><i><br>Cosmology and General Relativity Group<br>Observatory =
of Paris-Meudon, France</i><br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_438_29310125.1372165990376--

.

------=_Part_639_10086563.1372173817969
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, April 23, 2013 7:32:53 PM UTC+1, toma...@gmail.com wrote:
>
> So just rename it to bytes_count and define in namespace std, but I think
> that it should go then to separate proposla,
>
> Also after reading the (http://isocpp.org/files/papers/N3642.pdf) i think
> that there should be operators B, KiB, MiB, GiB, TiB definied in
> std::literals::byte_literals that it will be possible to write 10MiB
> instead of std::megabytes(10). Also the names may be futer discussed.
>

While I like the idea (and I liked it when VinceRev suggested it recently)
you should get the values correct:  10MiB is 10 mebibytes, not 10 megabytes.

Names should not be discussed, there is an international standard (ISO/IEC
80000) that says 1 Megabyte is 10e6 bytes, and ISO/IEC 14882 says std::mega
is a typedef for std::ratio<1e6, 1> not std::ratio<1048576,1>, so it would
be unacceptable to define std::megabytes as anything but 1e6 bytes.


--

---
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_639_10086563.1372173817969
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, April 23, 2013 7:32:53 PM UTC+1, toma...@gmail.com wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">So just rename it to bytes_c=
ount and define in namespace std, but I think that it should go then to sep=
arate proposla,<br><br>Also after reading the (<a href=3D"http://isocpp.org=
/files/papers/N3642.pdf" target=3D"_blank">http://isocpp.org/files/<wbr>pap=
ers/N3642.pdf</a>) i think that there should be operators B, KiB, MiB, GiB,=
 TiB definied in std::literals::byte_literals that it will be possible to w=
rite 10MiB instead of std::megabytes(10). Also the names may be futer discu=
ssed.<br></blockquote><div><br>While I like the idea (and I liked it when V=
inceRev suggested it recently) you should get the values correct:&nbsp; 10M=
iB is 10 mebibytes, not 10 megabytes.<br><br>Names should not be discussed,=
 there is an international standard (ISO/IEC 80000) that says 1 Megabyte is=
 10e6 bytes, and ISO/IEC 14882 says std::mega is a typedef for std::ratio&l=
t;1e6, 1&gt; not std::ratio&lt;<span style=3D"white-space: nowrap">1048576,=
1&gt;</span>, so it would be unacceptable to define std::megabytes as anyth=
ing but 1e6 bytes.<br></div><br><br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_639_10086563.1372173817969--

.

------=_Part_370_5866711.1372174113826
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, June 25, 2013 4:23:37 PM UTC+1, Jonathan Wakely wrote:
>
>
>
> On Tuesday, April 23, 2013 7:32:53 PM UTC+1, toma...@gmail.com wrote:
>>
>> So just rename it to bytes_count and define in namespace std, but I think
>> that it should go then to separate proposla,
>>
>> Also after reading the (http://isocpp.org/files/papers/N3642.pdf) i
>> think that there should be operators B, KiB, MiB, GiB, TiB definied in
>> std::literals::byte_literals that it will be possible to write 10MiB
>> instead of std::megabytes(10). Also the names may be futer discussed.
>>
>
> While I like the idea (and I liked it when VinceRev suggested it recently)
> you should get the values correct:  10MiB is 10 mebibytes, not 10 megabytes.
>
> Names should not be discussed, there is an international standard (ISO/IEC
> 80000) that says 1 Megabyte is 10e6 bytes,
>

Oops, that's not what it says! 1 megabyte is *1e6* bytes.


> and ISO/IEC 14882 says std::mega is a typedef for std::ratio<1e6, 1> not
> std::ratio<1048576,1>, so it would be unacceptable to define
> std::megabytes as anything but 1e6 bytes.
>
>
>

--

---
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_370_5866711.1372174113826
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, June 25, 2013 4:23:37 PM UTC+1, Jonathan Wakely wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Tuesday, April 23, 2=
013 7:32:53 PM UTC+1, <a>toma...@gmail.com</a> wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">So just rename it to bytes_count and define in namespace =
std, but I think that it should go then to separate proposla,<br><br>Also a=
fter reading the (<a href=3D"http://isocpp.org/files/papers/N3642.pdf" targ=
et=3D"_blank">http://isocpp.org/files/<wbr>papers/N3642.pdf</a>) i think th=
at there should be operators B, KiB, MiB, GiB, TiB definied in std::literal=
s::byte_literals that it will be possible to write 10MiB instead of std::me=
gabytes(10). Also the names may be futer discussed.<br></blockquote><div><b=
r>While I like the idea (and I liked it when VinceRev suggested it recently=
) you should get the values correct:&nbsp; 10MiB is 10 mebibytes, not 10 me=
gabytes.<br><br>Names should not be discussed, there is an international st=
andard (ISO/IEC 80000) that says 1 Megabyte is 10e6 bytes,</div></blockquot=
e><div><br>Oops, that's not what it says! 1 megabyte is <b>1e6</b> bytes.<b=
r>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div> and ISO/IE=
C 14882 says std::mega is a typedef for std::ratio&lt;1e6, 1&gt; not std::r=
atio&lt;<span style=3D"white-space:nowrap">1048576,1&gt;</span>, so it woul=
d be unacceptable to define std::megabytes as anything but 1e6 bytes.<br></=
div><br><br></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_370_5866711.1372174113826--

.

------=_Part_632_22326730.1372175569228
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Of, course 1MB is 1000^2 bytes and 1MiB is 1024^2 bytes and this is=20
completely standardized in ISO 80000 as Jonathan said.

I wanted to add a remark about a file_size or byte_count class. I think=20
that this class should have operator bool() that returns whether the size=
=20
is valid or not. Having a file of size 0 is not the same thing as not=20
having a file at all (and in the first case, operator bool() returns true,=
=20
and in the second case, it returns false).

Le mardi 25 juin 2013 17:28:33 UTC+2, Jonathan Wakely a =E9crit :
>
>
>
> On Tuesday, June 25, 2013 4:23:37 PM UTC+1, Jonathan Wakely wrote:
>>
>>
>>
>> On Tuesday, April 23, 2013 7:32:53 PM UTC+1, toma...@gmail.com wrote:
>>>
>>> So just rename it to bytes_count and define in namespace std, but I=20
>>> think that it should go then to separate proposla,
>>>
>>> Also after reading the (http://isocpp.org/files/papers/N3642.pdf) i=20
>>> think that there should be operators B, KiB, MiB, GiB, TiB definied in=
=20
>>> std::literals::byte_literals that it will be possible to write 10MiB=20
>>> instead of std::megabytes(10). Also the names may be futer discussed.
>>>
>>
>> While I like the idea (and I liked it when VinceRev suggested it=20
>> recently) you should get the values correct:  10MiB is 10 mebibytes, not=
 10=20
>> megabytes.
>>
>> Names should not be discussed, there is an international standard=20
>> (ISO/IEC 80000) that says 1 Megabyte is 10e6 bytes,
>>
>
> Oops, that's not what it says! 1 megabyte is *1e6* bytes.
> =20
>
>> and ISO/IEC 14882 says std::mega is a typedef for std::ratio<1e6, 1> not=
=20
>> std::ratio<1048576,1>, so it would be unacceptable to define=20
>> std::megabytes as anything but 1e6 bytes.
>>
>>
>>

--=20

---=20
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 e=
mail 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-proposa=
ls/.



------=_Part_632_22326730.1372175569228
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>Of, course 1MB is 1000^2 bytes and 1MiB is 1024^2 bytes and this is com=
pletely standardized in ISO 80000 as Jonathan said.<br><br>I wanted to add =
a remark about a file_size or byte_count class. I think that this class sho=
uld have <span style=3D"font-family: courier new,monospace;">operator bool(=
)</span> that returns whether the size is valid or not. Having a file of si=
ze 0 is not the same thing as not having a file at all (and in the first ca=
se, <span style=3D"font-family: courier new,monospace;">operator bool()</sp=
an> returns <span style=3D"font-family: courier new,monospace;">true</span>=
, and in the second case, it returns <span style=3D"font-family: courier ne=
w,monospace;">false</span>).<br><br>Le mardi 25 juin 2013 17:28:33 UTC+2, J=
onathan Wakely a =E9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><br><br>On Tuesday, June 25, 2013 4:23:37 PM UTC+1, Jonathan Wakely wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><br><br>On Tuesday, April 23, 2013 =
7:32:53 PM UTC+1, <a>toma...@gmail.com</a> wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">So just rename it to bytes_count and define in namespace std,=
 but I think that it should go then to separate proposla,<br><br>Also after=
 reading the (<a href=3D"http://isocpp.org/files/papers/N3642.pdf" target=
=3D"_blank">http://isocpp.org/files/<wbr>papers/N3642.pdf</a>) i think that=
 there should be operators B, KiB, MiB, GiB, TiB definied in std::literals:=
:byte_literals that it will be possible to write 10MiB instead of std::mega=
bytes(10). Also the names may be futer discussed.<br></blockquote><div><br>=
While I like the idea (and I liked it when VinceRev suggested it recently) =
you should get the values correct:&nbsp; 10MiB is 10 mebibytes, not 10 mega=
bytes.<br><br>Names should not be discussed, there is an international stan=
dard (ISO/IEC 80000) that says 1 Megabyte is 10e6 bytes,</div></blockquote>=
<div><br>Oops, that's not what it says! 1 megabyte is <b>1e6</b> bytes.<br>=
&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div> and ISO/IEC 14882=
 says std::mega is a typedef for std::ratio&lt;1e6, 1&gt; not std::ratio&lt=
;<span style=3D"white-space:nowrap">1048576,1&gt;</span>, so it would be un=
acceptable to define std::megabytes as anything but 1e6 bytes.<br></div><br=
><br></blockquote></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_632_22326730.1372175569228--

.

------=_Part_422_19549778.1372177474709
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu wtorek, 25 czerwca 2013 17:52:49 UTC+2 u=BFytkownik VinceRev napisa=
=B3:
>
>
> Of, course 1MB is 1000^2 bytes and 1MiB is 1024^2 bytes and this is=20
> completely standardized in ISO 80000 as Jonathan said.
>
> I wanted to add a remark about a file_size or byte_count class. I think=
=20
> that this class should have operator bool() that returns whether the size=
=20
> is valid or not. Having a file of size 0 is not the same thing as not=20
> having a file at all (and in the first case, operator bool() returns true=
,=20
> and in the second case, it returns false).
>
> I think the invalid state should not be part of the bytes_count class and=
=20
std::optional may be used in such situations. Secondly the filesystem=20
proposal is returning error in such situations.

To summarize, I would like to see:
  1) bytes_count structure simliar to the one used by chrono::duration
  2) bits definied as bytes_count<uintmax_t,=20
implementation_definied_fration> (I think the standard is not defining=20
amount of bits in byte). This may be especially useful for networking,
  3) except of count() method, the bytes_count<T, R> should have:
        bytes() method returning bytes_count<T, ratio<1>>(*this).count() if=
=20
the second expressions is well specified
        bits() method returning bytes_count<T,=20
mplementation_definied_fration>(*this).count() if the second expressions is=
=20
well specified
  4) define both 10-based (mega-, kilo-) and 2-based (megi-, kibi-)=20
typedefs for bytes and bits.
  5) user definied literals for each typedef in=20
std::literals::byte_literals and std::literals::bit_literals
=20

--=20

---=20
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 e=
mail 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-proposa=
ls/.



------=_Part_422_19549778.1372177474709
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu wtorek, 25 czerwca 2013 17:52:49 UTC+2 u=BFytkownik VinceRev=
 napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Of, course 1MB =
is 1000^2 bytes and 1MiB is 1024^2 bytes and this is completely standardize=
d in ISO 80000 as Jonathan said.<br><br>I wanted to add a remark about a fi=
le_size or byte_count class. I think that this class should have <span styl=
e=3D"font-family:courier new,monospace">operator bool()</span> that returns=
 whether the size is valid or not. Having a file of size 0 is not the same =
thing as not having a file at all (and in the first case, <span style=3D"fo=
nt-family:courier new,monospace">operator bool()</span> returns <span style=
=3D"font-family:courier new,monospace">true</span>, and in the second case,=
 it returns <span style=3D"font-family:courier new,monospace">false</span>)=
..<br><br></blockquote><div>I think the invalid state should not be part of =
the bytes_count class and std::optional may be used in such situations. Sec=
ondly the filesystem proposal is returning error in such situations.<br><br=
>To summarize, I would like to see:<br>&nbsp; 1) bytes_count structure siml=
iar to the one used by chrono::duration<br>&nbsp; 2) bits definied as  byte=
s_count&lt;uintmax_t, implementation_definied_fration&gt; (I think the stan=
dard is not defining amount of bits in byte). This may be especially useful=
 for networking,<br>&nbsp; 3) except of count() method, the bytes_count&lt;=
T, R&gt; should have:<br>&nbsp; &nbsp; &nbsp; &nbsp; bytes() method returni=
ng  bytes_count&lt;T, ratio&lt;1&gt;&gt;(*this).count() if the second expre=
ssions is well specified<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bits=
() method returning  bytes_count&lt;T, mplementation_definied_fration&gt;(*=
this).count() if the second expressions is well specified<br>&nbsp; 4) defi=
ne both  10-based (mega-, kilo-) and 2-based (megi-, kibi-) typedefs for by=
tes and bits.<br>&nbsp; 5) user definied literals for each typedef in std::=
literals::byte_literals and std::literals::bit_literals<br>&nbsp;<br><br></=
div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_422_19549778.1372177474709--

.

------=_Part_354_4729857.1372177934774
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, June 25, 2013 5:24:34 PM UTC+1, toma...@gmail.com wrote:
>
>
> 2) bits definied as bytes_count<uintmax_t,
> implementation_definied_fration> (I think the standard is not defining
> amount of bits in byte).
>

It doesn't define it, but it defines a macro to obtain it.  See CHAR_BIT in
<climits>



--

---
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_354_4729857.1372177934774
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, June 25, 2013 5:24:34 PM UTC+1, toma...@gmail.com wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><br><div>2) bits definied as =
 bytes_count&lt;uintmax_t, implementation_definied_<wbr>fration&gt; (I thin=
k the standard is not defining amount of bits in byte).</div></blockquote><=
div><br>It doesn't define it, but it defines a macro to obtain it.&nbsp; Se=
e CHAR_BIT in &lt;climits&gt;<br><br>&nbsp;<br><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_354_4729857.1372177934774--

.

2013/6/25 VinceRev <vince.rev@gmail.com>:
>
> Of, course 1MB is 1000^2 bytes and 1MiB is 1024^2 bytes and this is
> completely standardized in ISO 80000 as Jonathan said.
>
> I wanted to add a remark about a file_size or byte_count class. I think that
> this class should have operator bool() that returns whether the size is
> valid or not. Having a file of size 0 is not the same thing as not having a
> file at all (and in the first case, operator bool() returns true, and in the
> second case, it returns false).

I think this is a bad idea, because it will become hard for the user
to see the difference between a value of 0 and a value that is not
defined. operator bool() in the sense of signalling the latter is only
useful/save for types that are smart-pointers or smart-pointer-like
(such as optional), because in those cases access to the actual value
always requires an indirection.

- Daniel

--

---
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_513_10785898.1372252343641
Content-Type: text/plain; charset=ISO-8859-1

I would like to ask about your opinion about the approach to the
std::chrono::treat_as_floating_point and std::chrono::duration_values in
case when similar functionalities will be used by byte_count.

For sure i would like to define in the header <numeric>:
namespace std
{
  template <class Rep> struct treat_as_floating_point;
  template <class Rep> struct numeric_values;
}
With then same implementation as current chrono versions.

Then the chrono versions should be redefined:
namespace std { namespace chrono {
{
  template <class Rep> struct treat_as_floating_point
       : ::std::treat_as_floating_point<Rep>
    {}

  template <class Rep> struct duration_values
       :  ::std::numeric_values<Rep>
    {}
}}

Then we can go with 2 approach:
  1) Unify the interface for all unit representing types - remove chrono
members and change duration to use members of numeric or at least deprecate
it.
  2) Define one place to define common types for all unit representing
types (proposed struct in <numeric>) and then create a pair of specific
traits for each unit. So the chrono will have it own traits pair defaulting
to std members and there will be 2 more additional for byte_count. This
will allow greater flexibility, but I think that there is no need to define
types that will work with duration and do not work with byte_size.

--

---
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_513_10785898.1372252343641
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I would like to ask about your opinion about the approach to the <font face=
=3D"courier new,monospace">std::chrono::treat_as_floating_point<font face=
=3D"arial,sans-serif"> and <span style=3D"font-family: courier new,monospac=
e;">std::</span></font>chrono::duration_values <font face=3D"arial,sans-ser=
if">in case when similar functionalities will be used by byte_count.<br><br=
>For sure i would like to define in the header <span style=3D"font-family: =
courier new,monospace;">&lt;numeric&gt;</span>:<br><span style=3D"font-fami=
ly: courier new,monospace;">namespace std<br>{<br>&nbsp; template &lt;class=
 Rep&gt; struct treat_as_floating_point;<br>&nbsp; template &lt;class Rep&g=
t; struct numeric_values;<br>}</span><br>With then same implementation as c=
urrent </font>chrono</font> versions. <br><br>Then the <font face=3D"courie=
r new,monospace">chrono<span style=3D"font-family: arial,sans-serif;"> vers=
ions should be <font face=3D"courier new,monospace">redefined</font></span>=
:<br>namespace std { namespace chrono {<br>{<br>&nbsp; template &lt;class R=
ep&gt; struct treat_as_floating_point <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; : ::std::treat_as_floating_point&lt;Rep&gt;<br>&nbsp; &nbsp; {}<br><br>=
&nbsp; template &lt;class Rep&gt; struct duration_values<br>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; :&nbsp; ::std::<font face=3D"arial,sans-serif"><span =
style=3D"font-family: courier new,monospace;">numeric_values&lt;<font face=
=3D"arial,sans-serif"><span style=3D"font-family: courier new,monospace;">R=
ep&gt;<br>&nbsp;&nbsp;&nbsp; {}<br>}}</span><br></font></span></font></font=
><br>Then we can go with 2 approach:<br>&nbsp; 1) Unify the interface for a=
ll unit representing types - remove chrono members and change duration to u=
se members of numeric or at least deprecate it.<br>&nbsp; 2) Define one pla=
ce to define common types for all unit representing types (proposed struct =
in &lt;numeric&gt;) and then create a pair of specific traits for each unit=
.. So the chrono will have it own traits pair defaulting to std members and =
there will be 2 more additional for byte_count. This will allow greater fle=
xibility, but I think that there is no need to define types that will work =
with duration and do not work with byte_size.<br><br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_513_10785898.1372252343641--

.

------=_Part_669_21343672.1372271589840
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


--------------------------------------------
I think this is a bad idea, because it will become hard for the user=20
to see the difference between a value of 0 and a value that is not=20
defined. operator bool() in the sense of signalling the latter is only=20
useful/save for types that are smart-pointers or smart-pointer-like=20
(such as optional), because in those cases access to the actual value=20
always requires an indirection.=20
--------------------------------------------
Ok, it makes sense. However, I think that having a kind of "NaN" value=20
(with the same kind of operation/comparison behaviour as NaN) for undefined=
=20
byte counts could be useful to distinguish between a file size that is=20
null, and a result of a counting operation that failed. =20

Le mercredi 26 juin 2013 07:09:04 UTC+2, Daniel Kr=FCgler a =E9crit :
>
> 2013/6/25 VinceRev <vinc...@gmail.com <javascript:>>:=20
> >=20
> > Of, course 1MB is 1000^2 bytes and 1MiB is 1024^2 bytes and this is=20
> > completely standardized in ISO 80000 as Jonathan said.=20
> >=20
> > I wanted to add a remark about a file_size or byte_count class. I think=
=20
> that=20
> > this class should have operator bool() that returns whether the size is=
=20
> > valid or not. Having a file of size 0 is not the same thing as not=20
> having a=20
> > file at all (and in the first case, operator bool() returns true, and i=
n=20
> the=20
> > second case, it returns false).=20
>
> I think this is a bad idea, because it will become hard for the user=20
> to see the difference between a value of 0 and a value that is not=20
> defined. operator bool() in the sense of signalling the latter is only=20
> useful/save for types that are smart-pointers or smart-pointer-like=20
> (such as optional), because in those cases access to the actual value=20
> always requires an indirection.=20
>
> - Daniel=20
>

--=20

---=20
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 e=
mail 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-proposa=
ls/.



------=_Part_669_21343672.1372271589840
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>--------------------------------------------<br>I think this is a bad i=
dea, because it will become hard for the user
<br>to see the difference between a value of 0 and a value that is not
<br>defined. operator bool() in the sense of signalling the latter is only
<br>useful/save for types that are smart-pointers or smart-pointer-like
<br>(such as optional), because in those cases access to the actual value
<br>always requires an indirection.
<br>--------------------------------------------<br>Ok, it makes sense. How=
ever, I think that having a kind of "NaN" value (with the same kind of oper=
ation/comparison behaviour as NaN) for undefined byte counts could be usefu=
l to distinguish between a file size that is null, and a result of a counti=
ng operation that failed.&nbsp; <br><br>Le mercredi 26 juin 2013 07:09:04 U=
TC+2, Daniel Kr=FCgler a =E9crit&nbsp;:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;">2013/6/25 VinceRev &lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"ijRowkc_etoJ">vinc...@gmail.com</a>&gt;:
<br>&gt;
<br>&gt; Of, course 1MB is 1000^2 bytes and 1MiB is 1024^2 bytes and this i=
s
<br>&gt; completely standardized in ISO 80000 as Jonathan said.
<br>&gt;
<br>&gt; I wanted to add a remark about a file_size or byte_count class. I =
think that
<br>&gt; this class should have operator bool() that returns whether the si=
ze is
<br>&gt; valid or not. Having a file of size 0 is not the same thing as not=
 having a
<br>&gt; file at all (and in the first case, operator bool() returns true, =
and in the
<br>&gt; second case, it returns false).
<br>
<br>I think this is a bad idea, because it will become hard for the user
<br>to see the difference between a value of 0 and a value that is not
<br>defined. operator bool() in the sense of signalling the latter is only
<br>useful/save for types that are smart-pointers or smart-pointer-like
<br>(such as optional), because in those cases access to the actual value
<br>always requires an indirection.
<br>
<br>- Daniel
<br></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_669_21343672.1372271589840--

.

--089e01493cee332ab304e012ffd4
Content-Type: text/plain; charset=ISO-8859-1

On 26 June 2013 13:33, VinceRev <vince.rev@gmail.com> wrote:

>
> Ok, it makes sense. However, I think that having a kind of "NaN" value
> (with the same kind of operation/comparison behaviour as NaN) for undefined
> byte counts could be useful to distinguish between a file size that is
> null, and a result of a counting operation that failed.


-1.  Please don't break regularity.  Do you really want another value that
you cannot use as a key in a map?
--
 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/.



--089e01493cee332ab304e012ffd4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 26 June 2013 13:33, VinceRev <span dir=3D"ltr">&lt;<a href=3D"mailto:vin=
ce.rev@gmail.com" target=3D"_blank">vince.rev@gmail.com</a>&gt;</span> wrot=
e:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>Ok, it makes sense. However, I think that having a kind of &quot;NaN&qu=
ot; value (with the same kind of operation/comparison behaviour as NaN) for=
 undefined byte counts could be useful to distinguish between a file size t=
hat is null, and a result of a counting operation that failed.=A0</blockquo=
te>

</div>=A0<br>-1.=A0 Please don&#39;t break regularity.=A0 Do you really wan=
t another value that you cannot use as a key in a map?<br>-- <br>=A0Nevin &=
quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com=
" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

--089e01493cee332ab304e012ffd4--

.

------=_Part_413_4063805.1372272114644
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu =B6roda, 26 czerwca 2013 20:33:09 UTC+2 u=BFytkownik VinceRev napisa=
=B3:
>
>
> --------------------------------------------
> I think this is a bad idea, because it will become hard for the user=20
> to see the difference between a value of 0 and a value that is not=20
> defined. operator bool() in the sense of signalling the latter is only=20
> useful/save for types that are smart-pointers or smart-pointer-like=20
> (such as optional), because in those cases access to the actual value=20
> always requires an indirection.=20
> --------------------------------------------
> Ok, it makes sense. However, I think that having a kind of "NaN" value=20
> (with the same kind of operation/comparison behaviour as NaN) for undefin=
ed=20
> byte counts could be useful to distinguish between a file size that is=20
> null, and a result of a counting operation that failed. =20
>
>
As I said before, I would rather see a optional<byte_size> as a return for=
=20
the operation that want to report failure via a return type, so it will=20
automatically add a additional null value.=20

--=20

---=20
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 e=
mail 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-proposa=
ls/.



------=_Part_413_4063805.1372272114644
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu =B6roda, 26 czerwca 2013 20:33:09 UTC+2 u=BFytkownik VinceRe=
v napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>--------------=
----------------<wbr>--------------<br>I think this is a bad idea, because =
it will become hard for the user
<br>to see the difference between a value of 0 and a value that is not
<br>defined. operator bool() in the sense of signalling the latter is only
<br>useful/save for types that are smart-pointers or smart-pointer-like
<br>(such as optional), because in those cases access to the actual value
<br>always requires an indirection.
<br>------------------------------<wbr>--------------<br>Ok, it makes sense=
.. However, I think that having a kind of "NaN" value (with the same kind of=
 operation/comparison behaviour as NaN) for undefined byte counts could be =
useful to distinguish between a file size that is null, and a result of a c=
ounting operation that failed.&nbsp; <br><br></blockquote><div><br>As I sai=
d before, I would rather see a optional&lt;byte_size&gt; as a return for th=
e operation that want to report failure via a return type, so it will autom=
atically add a additional null value. <br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_413_4063805.1372272114644--

.