Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #67674 > unrolled thread

"C++: Size Matters in Platform Compatibility"

Back to article view | Back to comp.lang.c++

Contents

  "C++: Size Matters in Platform Compatibility" Lynn McGuire <lynnmcguire5@gmail.com> - 2019-08-16 14:04 -0500
    Re: "C++: Size Matters in Platform Compatibility" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-16 20:45 +0000
    Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-17 15:08 +0200
      Re: "C++: Size Matters in Platform Compatibility" Geoff <geoff@invalid.invalid> - 2019-08-17 12:43 -0700
        Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-18 12:32 +0200
          Re: "C++: Size Matters in Platform Compatibility" Geoff <geoff@invalid.invalid> - 2019-08-18 13:10 -0700
            Re: "C++: Size Matters in Platform Compatibility" Bart <bc@freeuk.com> - 2019-08-18 21:15 +0100
            Re: "C++: Size Matters in Platform Compatibility" Keith Thompson <kst-u@mib.org> - 2019-08-18 14:49 -0700
              Re: "C++: Size Matters in Platform Compatibility" Keith Thompson <kst-u@mib.org> - 2019-08-18 14:51 -0700
            Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-19 08:43 +0200
              Re: "C++: Size Matters in Platform Compatibility" "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-19 09:15 +0200
              Re: "C++: Size Matters in Platform Compatibility" Öö Tiib <ootiib@hot.ee> - 2019-08-19 01:07 -0700
        Re: "C++: Size Matters in Platform Compatibility" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-21 17:14 +0200
          Re: "C++: Size Matters in Platform Compatibility" Eli the Bearded <*@eli.users.panix.com> - 2019-08-21 18:30 +0000
            Re: "C++: Size Matters in Platform Compatibility" scott@slp53.sl.home (Scott Lurndal) - 2019-08-21 19:05 +0000
            Re: "C++: Size Matters in Platform Compatibility" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-21 21:25 +0200
            Re: "C++: Size Matters in Platform Compatibility" Keith Thompson <kst-u@mib.org> - 2019-08-21 12:28 -0700
            Re: "C++: Size Matters in Platform Compatibility" Richard Damon <Richard@Damon-Family.org> - 2019-08-22 22:58 -0400
              Re: "C++: Size Matters in Platform Compatibility" Eli the Bearded <*@eli.users.panix.com> - 2019-08-23 19:15 +0000
      Re: "C++: Size Matters in Platform Compatibility" Anton Shepelev <anton.txt@gmail.com> - 2019-08-18 15:59 +0300
        Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-18 16:32 +0200
      Re: "C++: Size Matters in Platform Compatibility" Juha Nieminen <nospam@thanks.invalid> - 2019-08-19 07:29 +0000
        Re: "C++: Size Matters in Platform Compatibility" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-19 12:20 +0300
        Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-19 11:22 +0200
          Re: "C++: Size Matters in Platform Compatibility" Richard Damon <Richard@Damon-Family.org> - 2019-08-23 14:14 -0400
            Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-24 20:56 +0200
              Re: "C++: Size Matters in Platform Compatibility" Robert Wessel <robertwessel2@yahoo.com> - 2019-08-24 23:43 -0500
                Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-25 12:11 +0200
                  Re: "C++: Size Matters in Platform Compatibility" Richard Damon <Richard@Damon-Family.org> - 2019-08-25 07:33 -0700
                    Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-25 20:27 +0200
                  Re: "C++: Size Matters in Platform Compatibility" Robert Wessel <robertwessel2@yahoo.com> - 2019-08-25 10:22 -0500
      Re: "C++: Size Matters in Platform Compatibility" Lynn McGuire <lynnmcguire5@gmail.com> - 2019-08-19 15:05 -0500
        Re: "C++: Size Matters in Platform Compatibility" scott@slp53.sl.home (Scott Lurndal) - 2019-08-19 20:17 +0000
          Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-20 08:21 +0200
            Re: "C++: Size Matters in Platform Compatibility" Lynn McGuire <lynnmcguire5@gmail.com> - 2019-08-20 14:38 -0500
        Re: "C++: Size Matters in Platform Compatibility" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-21 09:15 -0400
    Re: "C++: Size Matters in Platform Compatibility" Anton Shepelev <anton.txt@gmail.com> - 2019-08-18 15:20 +0300
      Re: "C++: Size Matters in Platform Compatibility" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-08-18 14:50 +0100

Page 1 of 2  [1] 2  Next page →

#67674 — "C++: Size Matters in Platform Compatibility"

"C++: Size Matters in Platform Compatibility"
 
https://www.codeproject.com/Tips/5164768/Cplusplus-Size-Matters-in-Platform-Compatibility

Interesting.  Especially on storing Unicode as UTF-8.

Lynn

[toc] | [next] | [standalone]

#67675

["Followup-To:" header set to comp.lang.c++.]

On Fri, 2019-08-16, Lynn McGuire wrote:
> "C++: Size Matters in Platform Compatibility"
>  
> https://www.codeproject.com/Tips/5164768/Cplusplus-Size-Matters-in-Platform-Compatibility
>
> Interesting.  Especially on storing Unicode as UTF-8.

Interesting that people still try to store/transfer data as manually
handled binary.  He also didn't seem to care about endianness and
similar issues.

I mostly use text, but if I really wanted binary I suppose I'd look
into Google protobuf.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#67682

On 16/08/2019 21:04, Lynn McGuire wrote:
> "C++: Size Matters in Platform Compatibility"
> 
> <https://www.codeproject.com/Tips/5164768/Cplusplus-Size-Matters-in-Platform-Compatibility> 
> 

Please put < > marks around links.

> 
> Interesting.  Especially on storing Unicode as UTF-8.
> 

If you are storing data in binary formats that need to be portable, you 
need to define and document the format, making it independent of the 
platform.  The author here glosses over the important bits - endianness 
and alignment (and consequently padding), which he doesn't mention at all.

Time should be not be stored in text format - that is very space 
inefficient in a binary file, and even if you stick to ISO formats there 
are huge numbers of variants possible.  Often the most sensible formats 
is 64 bit Unix epoch timestamps (happily covering the big bang up to 
well past the death of our sun).  IEEE floating point double Unix epoch 
seconds will last longer than protons, and give you accurate fractions 
of a second for more normal timeframes.  If these are not suitable, 
define a format for your particular requirements.

For character data where plain ASCII won't do, utf-8 is the only sane 
choice IMHO.  Other formats - utf-16, utf-32, wchar_t, etc., might be 
used internally for dealing with historical API's.

The author is right to use fixed size types for integers.  However, it 
doesn't make sense to have pointer types at all in a stored file or data 
interchange format.


The other alternative is to switch entirely to a text format such as 
JSON.  It is a lot less efficient to parse in C or C++ (though once we 
get introspection in C++, JSON generation and parsing will be a good 
deal nicer).  But it is easy to pass around between OS's, languages and 
applications, easy to handle in most higher level languages, and easy 
for debugging.

[toc] | [prev] | [next] | [standalone]

#67718

On Sat, 17 Aug 2019 15:08:52 +0200, David Brown
<david.brown@hesbynett.no> wrote:

[snip]

>
>If you are storing data in binary formats that need to be portable, you 
>need to define and document the format, making it independent of the 
>platform.  The author here glosses over the important bits - endianness 
>and alignment (and consequently padding), which he doesn't mention at all.
>

He does mention endianess and he declined to discuss it, saying it
needs a separate discussion. You are the second poster here to
overlook that.

[snip]

> Often the most sensible formats 
>is 64 bit Unix epoch timestamps (happily covering the big bang up to 
>well past the death of our sun).  IEEE floating point double Unix epoch 
>seconds will last longer than protons, and give you accurate fractions 
>of a second for more normal timeframes.  If these are not suitable, 
>define a format for your particular requirements.

The UNIX epoch-based 64-bit time is good only if you believe the sun
will only last another 2.147 billion years. The epoch time rolls over
in the year 2,147,485,547 on MacOS. The sun is calculated to have
another 5.4 billion years of hydrogen fuel left. 

Proton decay, so far, is only theoretical. It has never been observed.

[snip]

[toc] | [prev] | [next] | [standalone]

#67742

On 17/08/2019 21:43, Geoff wrote:
> On Sat, 17 Aug 2019 15:08:52 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
> [snip]
> 
>>
>> If you are storing data in binary formats that need to be portable, you
>> need to define and document the format, making it independent of the
>> platform.  The author here glosses over the important bits - endianness
>> and alignment (and consequently padding), which he doesn't mention at all.
>>
> 
> He does mention endianess and he declined to discuss it, saying it
> needs a separate discussion. You are the second poster here to
> overlook that.

I said he glossed over it, which he did.  I did not say he ignored it 
completely - he said it was an issue but did not discuss it further.

> 
> [snip]
> 
>> Often the most sensible formats
>> is 64 bit Unix epoch timestamps (happily covering the big bang up to
>> well past the death of our sun).  IEEE floating point double Unix epoch
>> seconds will last longer than protons, and give you accurate fractions
>> of a second for more normal timeframes.  If these are not suitable,
>> define a format for your particular requirements.
> 
> The UNIX epoch-based 64-bit time is good only if you believe the sun
> will only last another 2.147 billion years.

292 billion years, by my counting.  By that time, any issues with 
rollover will be an SEP¹.

> The epoch time rolls over
> in the year 2,147,485,547 on MacOS. The sun is calculated to have
> another 5.4 billion years of hydrogen fuel left.

That sounds like a signed 32-bit integer storing the number of years 
(not an unreasonable choice for a split time/date format).

> 
> Proton decay, so far, is only theoretical. It has never been observed.

True.  And perhaps humankind will have moved to a different, newer 
universe by that time.  We /could/ standardise on 128-bit second 
timestamps, but I think it is important to leave a few challenges to 
keep future generations motivated :-)

> 
> [snip]
> 

¹ <https://en.wikipedia.org/wiki/Somebody_else%27s_problem>

[toc] | [prev] | [next] | [standalone]

#67767

On Sun, 18 Aug 2019 12:32:18 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>> The UNIX epoch-based 64-bit time is good only if you believe the sun
>> will only last another 2.147 billion years.
>
>292 billion years, by my counting.  By that time, any issues with 
>rollover will be an SEP¹.
>
>>

Where are you getting that? time_t is the number of seconds since
January 1, 1970, 0:00 UTC and as a 64-bit integer that's not 292
billion years.

[toc] | [prev] | [next] | [standalone]

#67768

On 18/08/2019 21:10, Geoff wrote:
> On Sun, 18 Aug 2019 12:32:18 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>>> The UNIX epoch-based 64-bit time is good only if you believe the sun
>>> will only last another 2.147 billion years.
>>
>> 292 billion years, by my counting.  By that time, any issues with
>> rollover will be an SEP¹.
>>
>>>
> 
> Where are you getting that? time_t is the number of seconds since
> January 1, 1970, 0:00 UTC and as a 64-bit integer that's not 292
> billion years.
> 

No, it's 584 billion years. Presumably 292 billion was due to using it 
as a signed value (2**63 rather than 2**64 seconds).

[toc] | [prev] | [next] | [standalone]

#67769

Geoff <geoff@invalid.invalid> writes:
> On Sun, 18 Aug 2019 12:32:18 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
>
>>> The UNIX epoch-based 64-bit time is good only if you believe the sun
>>> will only last another 2.147 billion years.
>>
>>292 billion years, by my counting.  By that time, any issues with 
>>rollover will be an SEP¹.
>
> Where are you getting that? time_t is the number of seconds since
> January 1, 1970, 0:00 UTC and as a 64-bit integer that's not 292
> billion years.

Yes, it is.  A signed 64-bit time_t has a maximum value of 2**63-1.
2**63-1 seconds is just over 292 billion years.

The GNU coreutils "date" command gives an out of range error
for dates past Dec 31 in the year 2147485547, but that's not a
time_t issue.  Similarly, the type struct tm has tm_year as an int,
which imposes the same limit on systems where int is 32 bits.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#67770

Keith Thompson <kst-u@mib.org> writes:
> Geoff <geoff@invalid.invalid> writes:
>> On Sun, 18 Aug 2019 12:32:18 +0200, David Brown
>> <david.brown@hesbynett.no> wrote:
>>
>>>> The UNIX epoch-based 64-bit time is good only if you believe the sun
>>>> will only last another 2.147 billion years.
>>>
>>>292 billion years, by my counting.  By that time, any issues with 
>>>rollover will be an SEP¹.
>>
>> Where are you getting that? time_t is the number of seconds since
>> January 1, 1970, 0:00 UTC and as a 64-bit integer that's not 292
>> billion years.
>
> Yes, it is.  A signed 64-bit time_t has a maximum value of 2**63-1.
> 2**63-1 seconds is just over 292 billion years.

And I meant to mention that the C and C++ standards do not specify
that time_t represents seconds since 1970, though that is the most
common implementation.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#67774

On 18/08/2019 22:10, Geoff wrote:
> On Sun, 18 Aug 2019 12:32:18 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>>> The UNIX epoch-based 64-bit time is good only if you believe the sun
>>> will only last another 2.147 billion years.
>>
>> 292 billion years, by my counting.  By that time, any issues with 
>> rollover will be an SEP¹.
>>
>>>
> 
> Where are you getting that? time_t is the number of seconds since
> January 1, 1970, 0:00 UTC and as a 64-bit integer that's not 292
> billion years.
> 

time_t doesn't /have/ to be seconds since 1970, but it is a good choice
for the type.

2 ^ 63 		= 9.223372037×10¹⁸ seconds
ans / 3600	= 2.562047788×10¹⁵ hours
ans / 24	= 1.067519912×10¹⁴ days
ans / 365.24	= 292279025208.905503028 years
ans / 10⁹	= 292.279025208906 billion years

[toc] | [prev] | [next] | [standalone]

#67776

On 19.08.2019 08:43, David Brown wrote:
> On 18/08/2019 22:10, Geoff wrote:
>> On Sun, 18 Aug 2019 12:32:18 +0200, David Brown
>> <david.brown@hesbynett.no> wrote:
>>
>>>> The UNIX epoch-based 64-bit time is good only if you believe the sun
>>>> will only last another 2.147 billion years.
>>>
>>> 292 billion years, by my counting.  By that time, any issues with
>>> rollover will be an SEP¹.
>>>
>>>>
>>
>> Where are you getting that? time_t is the number of seconds since
>> January 1, 1970, 0:00 UTC and as a 64-bit integer that's not 292
>> billion years.
>>
> 
> time_t doesn't /have/ to be seconds since 1970,

Doesn't /yet/.

As I recall C++20 standardizes on the conventional Unix epoch for 
`<chrono>`, and it would then be weird if `time_t` had a different 
epoch, so my best offhand guess is that it nails down that too.


> but it is a good choice for the type.
> 
> 2 ^ 63 		= 9.223372037×10¹⁸ seconds
> ans / 3600	= 2.562047788×10¹⁵ hours
> ans / 24	= 1.067519912×10¹⁴ days
> ans / 365.24	= 292279025208.905503028 years
> ans / 10⁹	= 292.279025208906 billion years

Oh look! Tabs!


Cheers!,

- Alf

[toc] | [prev] | [next] | [standalone]

#67779

On Monday, 19 August 2019 09:43:25 UTC+3, David Brown  wrote:
>
> ans / 365.24	= 292279025208.905503028 years

Related issue is that lot of code uses <ctime> struct tm  to manipulate
date-time. In it the tm_year member is required to be int. When int
happens to have less than about 40 (*) bits then that number does
not fit into that member. So such software will be broken in conversions
between time_t and tm. 

* - "About 40" is bare eye estimation how lot of storage given number
     needs. 

[toc] | [prev] | [next] | [standalone]

#67845

I prefer Win32's FILETIME which is a 64 bit integer that
counts the number of 100ns-steps since 1.1.1601 00:00.
Unfortunately that's not portable.

[toc] | [prev] | [next] | [standalone]

#67847

In comp.lang.c, Bonita Montero  <Bonita.Montero@gmail.com> wrote:
> I prefer Win32's FILETIME which is a 64 bit integer that
> counts the number of 100ns-steps since 1.1.1601 00:00.

First thing I think of when I see that is "In what calendar?" Gregorian
transition started in 1582, happend in Britain and it's colonies in
1752, and I think you have to get to 1923 for Europe to finish switching
from Julian. (Greece was 1923, Turkey was 1926.)

> Unfortunately that's not portable.

Yes. Julian is still drifting apart at a rate of 1 day per 400 years,
which is around 0.0016 seconds day. That's a big jump in nanoseconds.

Elijah
------
given MS, probably whatever calender Redmond was on in 1995

[toc] | [prev] | [next] | [standalone]

#67848

Eli the Bearded <*@eli.users.panix.com> writes:
>In comp.lang.c, Bonita Montero  <Bonita.Montero@gmail.com> wrote:
>> I prefer Win32's FILETIME which is a 64 bit integer that
>> counts the number of 100ns-steps since 1.1.1601 00:00.
>
>First thing I think of when I see that is "In what calendar?" Gregorian
>transition started in 1582, happend in Britain and it's colonies in
>1752, and I think you have to get to 1923 for Europe to finish switching
>from Julian. (Greece was 1923, Turkey was 1926.)
>
>> Unfortunately that's not portable.
>
>Yes. Julian is still drifting apart at a rate of 1 day per 400 years,
>which is around 0.0016 seconds day. That's a big jump in nanoseconds.
>
>Elijah
>------
>given MS, probably whatever calender Redmond was on in 1995
>

Starting dates are completely arbitrary, and no one is better than the
other.  Personally, a 64-bit unix time_t works just fine.


http://www3.sympatico.ca/n.rieck/docs/calendar_time_y2k_etc.html#vax_vms_time

QUESTION:

Why is Wednesday, November 17, 1858 the base time for OpenVMS (VAX VMS)?

ANSWER:

November 17, 1858 is the base of the Modified Julian Day system.

The original Julian Day (JD) is used by astronomers and expressed in
days since noon January 1, 4713 B.C.  This measure of time was
introduced by Joseph Scaliger in the 16th century.  It is named in
honor of his father, Julius Caesar Scaliger (note that this Julian Day
is different from the Julian calendar named for the Roman Emperor
Julius Caesar!).

Why 4713 BC?  Scaliger traced three time cycles and found that they
were all in the first year of their cyle in 4713 B.C.  The three
cycles are 15, 19, and 28 years long.  By multiplying these three
numbers (15 * 19 * 28 = 7980), he was able to represent any date from
4713 B.C. through 3267 A.D.  The starting year was before any
historical event known to him.  In fact, the Jewish calendar marks the
start of the world as 3761 B.C.  Today his numbering scheme is still
used by astronomers to avoid the difficulties of converting the months
of different calendars in use during different eras.

So why 1858?  The Julian Day 2,400,000 just happens to be November 17,
1858.  The Modified Julian Day uses the following formula:

     MJD = JD - 2,400,000.5

The .5 changed when the day starts.  Astronomers had considered it
more convenient to have their day start at noon so that nighttime
observation times fall in the middle.  But they changed to conform to
the commercial day.

The Modified Julian Day was adopted by the Smithsonian Astrophysical
Observatory (SAO) in 1957 for satellite tracking.  SAO started
tracking satellites with an 8K (non-virtual) 36-bit IBM[R] 704 computer
in 1957, when Sputnik was launched.  The Julian day was 2,435,839 on
January 1, 1957.  This is 11,225,377 in octal notation, which was too
big to fit into an 18-bit field (half of the IBM standard 36-bit word).
And, with only 8K of memory, no one wanted to waste the 14 bits left
over by keeping the Julian Day in its own 36-bit word.  However, they
also needed to track hours and minutes, for which 18 bits gave enough
accuracy.  So, they decided to keep the number of days in the left 18
bits and the hours and minutes in the right 18 bits of a word.

Eighteen bits would allow the Modified Julian Day (the SAO day) to
grow as large as 262,143 ((2 ** 18) - 1).  From Nov. 17, 1858, this
allowed for seven centuries.  Using only 17 bits, the date could
possibly grow only as large as 131,071, but this still covers 3
centuries, as well as leaving the possibility of representing negative
time.  The year 1858 preceded the oldest star catalog in use at SAO,
which also avoided having to use negative time in any of the satellite
tracking calculations.

This base time of Nov. 17, 1858 has since been used by TOPS-10,
TOPS-20, and VAX VMS and OpenVMS.  Given this base date, the 100
nanosecond granularity implemented within OpenVMS and the 63-bit
absolute time representation (the sign bit must be clear), OpenVMS
should have no trouble with time until:

     31-JUL-31086 02:48:05.47

At this time, all clocks and time-keeping operations in OpenVMS will
suddenly stop, as system time values go negative.

Note that the OpenVMS time display and manipulation routines allow for
only 4 digits in the 'YEAR' field.  We expect this to be corrected in
a future release of OpenVMS sometime prior to 31-DEC-9999.

[toc] | [prev] | [next] | [standalone]

#67850

> First thing I think of when I see that is "In what calendar?" Gregorian
> transition started in 1582, happend in Britain and it's colonies in
> 1752, and I think you have to get to 1923 for Europe to finish switching
> from Julian. (Greece was 1923, Turkey was 1926.)

Try to google:
"The FILETIME structure records time in the form of 100-nanosecond
intervals since January 1, 1601. Why was that date chosen?
The Gregorian calendar operates on a 400-year cycle, and 1601 is the
first year of the cycle that was active at the time Windows NT was
being designed. In other words, it was chosen to make the math come
out nicely."

[toc] | [prev] | [next] | [standalone]

#67851

Eli the Bearded <*@eli.users.panix.com> writes:
> In comp.lang.c, Bonita Montero  <Bonita.Montero@gmail.com> wrote:
>> I prefer Win32's FILETIME which is a 64 bit integer that
>> counts the number of 100ns-steps since 1.1.1601 00:00.
>
> First thing I think of when I see that is "In what calendar?" Gregorian
> transition started in 1582, happend in Britain and it's colonies in
> 1752, and I think you have to get to 1923 for Europe to finish switching
> from Julian. (Greece was 1923, Turkey was 1926.)

Fortunately, there's an answer: it refers to 1601-01-01 in the Gregorian
calendar.

<https://devblogs.microsoft.com/oldnewthing/20090306-00/?p=18913>

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#67896

On 8/21/19 2:30 PM, Eli the Bearded wrote:

> Yes. Julian is still drifting apart at a rate of 1 day per 400 years,
> which is around 0.0016 seconds day. That's a big jump in nanoseconds.
> 
> Elijah
> ------
> given MS, probably whatever calender Redmond was on in 1995
> 
> 

I thought it was 3 days per 400 years, the multiples of 100 which aren't
multiples of 400 which are the ones the Gregorian Calendar omitted.

[toc] | [prev] | [next] | [standalone]

#67916

In comp.lang.c, Richard Damon  <Richard@Damon-Family.org> wrote:
> On 8/21/19 2:30 PM, Eli the Bearded wrote:
>> Yes. Julian is still drifting apart at a rate of 1 day per 400 years,
>> which is around 0.0016 seconds day. That's a big jump in nanoseconds.
> I thought it was 3 days per 400 years, the multiples of 100 which aren't
> multiples of 400 which are the ones the Gregorian Calendar omitted.

Hmmm. Yes. This is why I'm happy to use date libraries instead of
writing my own.

Elijah
------
there's too much to remember

[toc] | [prev] | [next] | [standalone]

#67753

David Brown:

> However, it doesn't make sense to have pointer types at
> all in a stored file or data interchange format.

He is talking about the use of pointer types as integer
indices, as (he says) WinAPI does with DWORD_PTR.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web