Tuesday, November 18, 2014

Digest for comp.lang.c++@googlegroups.com - 19 updates in 2 topics

comp.lang.c++@googlegroups.com Google Groups
Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Christopher Pisz <nospam@notanaddress.com>: Nov 18 04:13PM -0600

I wonder if I could gleam some advise on how to get the milliseconds out
of a time duration. Not the total milliseconds, mind you. Just the
milliseconds part of the time.
 
They define a method to get fractional seconds, so I am a bit boggled on
what I would write to give milliseconds (or the closest approximation
given the resolution)
 
I imagine I would get something like .2374 in one machine and .24 on
another, but I am not sure.
Brian Waldrop <bwald32@hotmail.com>: Nov 18 10:24PM

Christopher Pisz wrote:
 
> I wonder if I could gleam some advise on how to get the milliseconds out
> of a time duration. Not the total milliseconds, mind you. Just the
> milliseconds part of the time.
 
I guess they already are given in ms, so make sure you know the size of
the register 32 or 64 bits, then out mask only the LSB part or modulus 1000
 
Why the need of boost?
"Öö Tiib" <ootiib@hot.ee>: Nov 18 02:28PM -0800

On Wednesday, 19 November 2014 00:13:39 UTC+2, Christopher Pisz wrote:
 
> They define a method to get fractional seconds, so I am a bit boggled on
> what I would write to give milliseconds (or the closest approximation
> given the resolution)
 
Does not something like that work:
int msec = (duration.total_nanoseconds() % 1000000000)/1000000;
 
?
 
> I imagine I would get something like .2374 in one machine and .24 on
> another, but I am not sure.
 
You get count of milliseconds that way above, accuracy guarantees
depend how "real time" the clocks on your hardware are.
Christopher Pisz <nospam@notanaddress.com>: Nov 18 04:39PM -0600

On 11/18/2014 4:28 PM, 嘱 Tiib wrote:
 
> Does not something like that work:
> int msec = (duration.total_nanoseconds() % 1000000000)/1000000;
 
> ?
 
No, because I do not want to include the year, month, day, hour, minute,
or seconds parts of the date time. I want just the fractional seconds
part as milliseconds.
 
Unless I am misunderstanding the documentation for total_nanoseconds and
its brothers.
 
 
I would think they'd give fractional second as a double, so that I could
multiply it by 1000, but it looks like it comes back as an int64, so
that leaves me not knowing what metric of time the int64 represents.
 
 
Brian Waldrop <bwald32@hotmail.com>: Nov 18 10:39PM

Öö Tiib wrote:
 
>> approximation given the resolution)
 
> Does not something like that work:
> int msec = (duration.total_nanoseconds() % 1000000000)/1000000;
 
This takes a lot of water to manage. Out masking the bits is much faster.
Melzzzzz <mel@zzzzz.com>: Nov 18 11:42PM +0100

On Tue, 18 Nov 2014 16:13:28 -0600
 
What's wrong with:
http://pubs.opengroup.org/onlinepubs/7908799/xsh/systime.h.html
Christopher Pisz <nospam@notanaddress.com>: Nov 18 04:43PM -0600

On 11/18/2014 4:24 PM, Brian Waldrop wrote:
>> milliseconds part of the time.
 
> I guess they already are given in ms, so make sure you know the size of
> the register 32 or 64 bits, then out mask only the LSB part or modulus 1000
 
As far as I can tell I can only get fractional second and it comes back
as a 64 bit int, so I have no idea of knowing the metric of time the int
represents.
 
They have a get resolution method that returns an enum too.
 
 
> Why the need of boost?
 
Because the gregorian date and posix_time classes have served me well in
the past and I am replacing a broken chunk of code where yet another
programmer wanted to custom make his own data structures for datetime
incorrectly.
 
I can't use std::chrono, because I am bound to msvc2010 for this
particular library.
 
I also despise the old Windows C representations for datetime.
Christopher Pisz <nospam@notanaddress.com>: Nov 18 04:47PM -0600

On 11/18/2014 4:42 PM, Melzzzzz wrote:
 
> What's wrong with:
> http://pubs.opengroup.org/onlinepubs/7908799/xsh/systime.h.html
 
Well, "wrong" would be a matter of personal opinion, but my choice to
use boost's datetime classes is based on the following:
 
I've already got boost in for other libraries it provides
It has a much much better interface with much much more utility.
It supports UTC, local time, and conversions
It supports conversion to and from popular string formats
I like its style and error handling (exceptions)
I don't like C style :)
"Öö Tiib" <ootiib@hot.ee>: Nov 18 03:00PM -0800

On Wednesday, 19 November 2014 00:39:44 UTC+2, Christopher Pisz wrote:
> part as milliseconds.
 
> Unless I am misunderstanding the documentation for total_nanoseconds and
> its brothers.
 
I am not sure how you understand the documentation but ...
Ok ... I did choose a bad time to joke then, sorry.
 
I try with little more serious logic lesson then ... perhaps?
Imagine that 'total_milliseconds()' returns 6789.
 
1) How many seconds was in that duration?
2) How many milliseconds was in it?
3) Does not remainder (operator %) let you to separate those seconds from
milliseconds?
"Öö Tiib" <ootiib@hot.ee>: Nov 18 03:07PM -0800

On Wednesday, 19 November 2014 00:40:03 UTC+2, Brian Waldrop wrote:
 
> > Does not something like that work:
> > int msec = (duration.total_nanoseconds() % 1000000000)/1000000;
 
> This takes a lot of water to manage. Out masking the bits is much faster.
 
This must be is some counter-joke. 1000 happens to not be power of 2
so I don't know how to get the remainder of divison by 1000 using
some outmasking the bits trick.
Christopher Pisz <nospam@notanaddress.com>: Nov 18 05:17PM -0600

On 11/18/2014 5:00 PM, Öö Tiib wrote:
> 2) How many milliseconds was in it?
> 3) Does not remainder (operator %) let you to separate those seconds from
> milliseconds?
 
I see what you are saying now.
Have to check the mins and maxes though and make sure no overflow is
possible.
scott@slp53.sl.home (Scott Lurndal): Nov 18 09:07PM

>there are ways to do things in the present which are incompatible with
>the way things were done in the past. I think the goal should always
>be looking forward, not looking backward.
 
If you really want to use "OR" instead of "||", feel free to code
in COBOL or Fortran. In other words, nobody is looking backward
here except the C++11 committee.
legalize+jeeves@mail.xmission.com (Richard): Nov 18 09:19PM

[Please do not mail me a copy of your followup]
 
no@notvalid.com spake the secret code
 
>is more human readable than
 
>if( a == 5 || a == 8 )
 
>?
 
No. It isn't the norm in the community. (I would go farther and say
that writing if to look like a function call and bracketing the
conditional expression with additional whitespace also hinders
readability.)
 
>we are really doing or-operation there, so how could something else than
>or be better?
 
Section 2.6 of the standard calls these keywords "alternative tokens".
As far as I know, this is the only place in the standard where these
alternates are mentioned. Everywhere else logical OR is written as ||.
This is a strong hint that these alternate tokens aren't intended to
be the typical use.
 
The standard doesn't give a rationale for why these alternate tokens
are present in the language, but I suspect it is a legacy issue of
allowing C/C++ to be used in older environments where the keyboards
don't have some of the more "exotic" punctuation marks beyond those
found on typewriters.
 
Looking at the C standard, section 7.9 gives these same alternate
spellings as macros that expand to the operators. The macros are
defined in <iso646.h>. Looking up ISO 646 on Wikipedia gives a
description of this standard as the 7-bit coded character set -- in
other words it's the standardized version of ASCII.
<http://en.wikipedia.org/wiki/ISO/IEC_646>
 
Now take a look at the keyboard on a common teletype:
<http://commons.wikimedia.org/wiki/File:Mappa_Teletype_ASR-33.jpg>
 
Look carefully at the punctuation and you will find the following
characters are missing: {, }, |, ^ and ~. In such an environment
you would have no choice but to use the digraphs <%, %> for { and }
and the alternate keywords for operators containing ^, ~ and |.
 
So, you can see that these alternate spellings of the operators are
there only for compatibility with legacy environments and are not
considered to be used in "normal" situations.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
scott@slp53.sl.home (Scott Lurndal): Nov 18 09:34PM

>characters are missing: {, }, |, ^ and ~. In such an environment
>you would have no choice but to use the digraphs <%, %> for { and }
>and the alternate keywords for operators containing ^, ~ and |.
 
Historically in C, this was handled by trigraphs '??(' == '[' etc.
 
In C++, 'or', 'and', 'xor', 'bitor', et. alia are considered by
the standard to be digraphs.
 
The term "digraph" (token consisting of two characters) is not perfectly
descriptive, since one of the alternative preprocessing-tokens is %:%:
and of course several primary tokens contain two characters. Nonetheless,
those alternative tokens that aren't lexical keywords are colloquially
known as "digraphs".
Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 18 09:38PM

On Tue, 2014-11-18, Martin Shobe wrote:
>> we are really doing or-operation there, so how could something else than
>> or be better?
 
> I've been using || for 27 years. or just recently became an option.
 
Because you used some other language until recently, surely? Because
'or' has been in the language since at least 1994 -- that's 20 years!
 
Not that I use 'or' and friends myself -- that's an area where
deviating from C is more trouble than it's worth. And noone else
uses them ...
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
JiiPee <no@notvalid.com>: Nov 18 09:40PM

On 18/11/2014 21:19, Richard wrote:
 
> So, you can see that these alternate spellings of the operators are
> there only for compatibility with legacy environments and are not
> considered to be used in "normal" situations.
 
Looks like that is the case ... unfortunately :(. I still think or is
better, but if everybody else uses || what can I do?...seems like I am
forced to go back to || .
"Öö Tiib" <ootiib@hot.ee>: Nov 18 02:03PM -0800

On Tuesday, 18 November 2014 20:58:44 UTC+2, JiiPee wrote:
> if(a == 5 or a > 9)
> ....
 
> (old: if(a == 5 || a > 9) )
 
In some sense of "new". The keywords 'and', 'and_eq', 'bitand',
'bitor', 'compl', 'not', 'or', 'or_eq' and so on were there in
C++03 as well.
 
> against using it? Why C++ people normally still prefer ||, I don't see
> people using "or" ? Is there a reason for it? I like to use all the
> improvements as they come with C++ ...
 
With too lot of operator and punctuation keywords the program code
becomes too COBOL-like for my taste. Even Pascal and Ada feel too
lot of keywords. I configure code editor to make operators of
different color (for example bold dark grey) to ease reading such
languages. That is matter of taste perhaps but since so lot of
popular programming languages share the syntactic style of C
(Java, Javascript, C++, C#, lua and so on and so on) I suspect
that lot of programmers share my view on syntax.
 
I think of the keywords as better alternative tokens than trigraphs
for those unlucky who do not have access to keyboard with all symbols.
So ... 'compl b' is certainly better than '??- b' but '~b' is best
for me to read. Similarly 'a xor b' is better than 'a ??' b'
but 'a ^ b' is best.
legalize+jeeves@mail.xmission.com (Richard): Nov 18 10:42PM

[Please do not mail me a copy of your followup]
 
slp53@pacbell.net spake the secret code
 
>Historically in C, this was handled by trigraphs '??(' == '[' etc.
 
Trigraphs are another mechanism for representing some of the same
characters. Trigraphs are listed in section 5.2.1.1, paragraph 1
of the C standard.
 
The current version of the C standard also describes digraphs. See
section 6.4.6, paragraph 3.
 
>In C++, 'or', 'and', 'xor', 'bitor', et. alia are considered by
>the standard to be digraphs.
 
Sorry, but they're not. They're called alternative tokens or reserved
words in section 2.6, paragraph 1.
 
> and of course several primary tokens contain two characters. Nonetheless,
> those alternative tokens that aren't lexical keywords are colloquially
> known as "digraphs".
 
This is the footnote in section 2.6 and it is not referring to 'or',
'and', etc., in the table of alternative tokens, but to <%, %>, <:, :>,
%:, %:%: in the table.
 
You omitted the first sentence of the footnote that makes this
abundantly clear:
 
"These include "digraphs" and additional reserved words."
 
None of this is to be confused with trigraph sequences described in
section 2.4 which also provide a means of typing some of the more
"exotic" punctuation not found on older input devices.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Alain Ketterlin <alain@dpt-info.u-strasbg.fr>: Nov 19 12:06AM +0100


> is more human readable than
 
> if( a == 5 || a == 8 )
 
> ?
 
No. I think using "or" is actually misleading, I would prefer "orelse"
as in Standard ML.
 
> we are really doing or-operation there, so how could something else
> than or be better?
 
Anything else is better. "||" does not commute, because of
short-circuiting rules. Its meaning is significantly different from "or"
(the grammatical conjunction), from "or" (the logical connective), from
"|" (the bitwise-or operator), and from what you call the "or-operation"
(I don't know what this is)--all of these being named or. It makes a lot
of sense to have a special symbol. I think the C commitee was wise to
require inclusion of iso646.h to use or, it is a pity C++ made them
keywords.
 
-- Alain.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.

No comments: