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. |
- boost::posix_time::time_duration fractional seconds - 11 Updates
- or vs || , and a template question - 8 Updates
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:
Post a Comment