«

Hi all.

How does one read the system calendar and clock with C++?
I have found this link to the <time.h> header

http://www.cplusplus.com/reference/clibrary/ctime/

but I don't see any reason to revert to C code unless absolutely
necessary. Is there anything in Boost? TR1? C++0x?

Rune

Rune Allnor wrote, On 18.10.2009 12:54:
> Hi all.
>
> How does one read the system calendar and clock with C++?
> I have found this link to the <time.h> header
>
> http://www.cplusplus.com/reference/clibrary/ctime/
>
> but I don't see any reason to revert to C code unless absolutely
> necessary. Is there anything in Boost? TR1? C++0x?
If you need more sophisticated time and date handling then you can use
something like Boost.DateTime library
<http://www.boost.org/doc/libs/1_40_0/doc/html/date_time.html>.

--
VH

Rune Allnor wrote:
> Hi all.
>
> How does one read the system calendar and clock with C++?
> I have found this link to the <time.h> header
>
> http://www.cplusplus.com/reference/clibrary/ctime/
>
> but I don't see any reason to revert to C code unless absolutely
> necessary. Is there anything in Boost? TR1? C++0x?

On Windows, just use win32 api

On 18 Okt, 21:59, Juha Nieminen <nos...@thanks.invalid> wrote:
> Rune Allnor wrote:
> > Hi all.
>
> > How does one read the system calendar and clock with C++?
> > I have found this link to the <time.h> header
>
> >http://www.cplusplus.com/reference/clibrary/ctime/
>
> > but I don't see any reason to revert to C code unless absolutely
> > necessary.
>
> * But why? It's not like there would be bad memory leak problems or such
> with the C time functions. (For example, std::strftime is a quite handy
> function to get the date in any format you want, and you can specify the
> maximum size of the destination buffer, so if used properly there's no
> danger of leaks.)

If used properly, there are no dangers with C at all.

It's a matter of personal preference. When I coded up the
timer based on the example above, I found myself in a place
I have been before, where I did not want to be, where I had
to consider all kinds of details I was not interested in.

When I write my application I want to focus on the application.
C forces me to focus on memory managment and all kinds of details
that distract me from th emain task.

Rune

[Please do not mail me a copy of your followup]

Juha Nieminen <> spake the secret code
<hbfs2r$8u3$> thusly:

> But why? It's not like there would be bad memory leak problems or such
>with the C time functions. [...]

Its difficult to provide a test double to isolate my code from the
clock when I use C time functions.

If I use C++, I can push those functions behind an interface allowing
my test code to force the time or date to be a specific value for
testing, isolating my code from the clock.

Production code delegates from the interface to the C time function in
code that is so obviously correct that I don't feel the need to unit
test it.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

On Oct 18, 12:54*pm, Rune Allnor <all...@tele.ntnu.no> wrote:
> Hi all.
>
> How does one read the system calendar and clock with C++?
> I have found this link to the <time.h> header
>
> http://www.cplusplus.com/reference/clibrary/ctime/
>
> but I don't see any reason to revert to C code unless absolutely
> necessary. Is there anything in Boost? TR1? C++0x?

The facilities in <time.h>/<ctime> are an integral part of C++. Using
them does in no way mean that you revert to C code.

>
> Rune

Bart v Ingen Schenau

Bart van Ingen Schenau wrote:

> On Oct 18, 12:54 pm, Rune Allnor <all...@tele.ntnu.no> wrote:
>> Hi all.
>>
>> How does one read the system calendar and clock with C++?
>> I have found this link to the <time.h> header
>>
>> http://www.cplusplus.com/reference/clibrary/ctime/
>>
>> but I don't see any reason to revert to C code unless absolutely
>> necessary. Is there anything in Boost? TR1? C++0x?
>
> The facilities in <time.h>/<ctime> are an integral part of C++. Using
> them does in no way mean that you revert to C code.

I view that as a formal response to an informal statement. Yes, they are an
integral part of C++, but in a similar vein, I invested a lot of time in
learning how to avoid the use of printf() and it's brothers and cousins.

I have no wish to argue or discuss further, this is just an observation.

osmium wrote:
> Bart van Ingen Schenau wrote:
>
>> On Oct 18, 12:54 pm, Rune Allnor <all...@tele.ntnu.no> wrote:
>>> Hi all.
>>>
>>> How does one read the system calendar and clock with C++?
>>> I have found this link to the <time.h> header
>>>
>>> http://www.cplusplus.com/reference/clibrary/ctime/
>>>
>>> but I don't see any reason to revert to C code unless absolutely
>>> necessary. Is there anything in Boost? TR1? C++0x?
>> The facilities in <time.h>/<ctime> are an integral part of C++. Using
>> them does in no way mean that you revert to C code.
>
> I view that as a formal response to an informal statement. Yes, they are an
> integral part of C++, but in a similar vein, I invested a lot of time in
> learning how to avoid the use of printf() and it's brothers and cousins.
>
> I have no wish to argue or discuss further, this is just an observation.

Not to attempt to discuss further; just another observation: 'printf'
has several well-known problems related to the use of '...' while
functions in <ctime> IIRC do not suffer from that. Hence the OP's
apprehension (of "reverting to C code") is IMHO unfounded, and your
likening of mechanisms from <ctime> to 'printf' does not work.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

On Oct 19, 10:04*am, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> osmium wrote:
> > Bart van Ingen Schenau wrote:
>
> >> On Oct 18, 12:54 pm, Rune Allnor <all...@tele.ntnu.no> wrote:
> >>> Hi all.
>
> >>> How does one read the system calendar and clock with C++?
> >>> I have found this link to the <time.h> header
>
> >>>http://www.cplusplus.com/reference/clibrary/ctime/
>
> >>> but I don't see any reason to revert to C code unless absolutely
> >>> necessary. Is there anything in Boost? TR1? C++0x?
> >> The facilities in <time.h>/<ctime> are an integral part of C++. Using
> >> them does in no way mean that you revert to C code.
>
> > I view that as a formal response to an informal statement. *Yes, they are an
> > integral part of C++, but in a similar vein, I invested a lot of time in
> > learning how to avoid the use of printf() and it's brothers and cousins..
>
> > I have no wish to argue or discuss further, this is just an observation..
>
> Not to attempt to discuss further; just another observation: 'printf'
> has several well-known problems related to the use of '...' while
> functions in <ctime> IIRC do not suffer from that. *Hence the OP's
> apprehension (of "reverting to C code") is IMHO unfounded, and your
> likening of mechanisms from <ctime> to 'printf' does not work.
>

asctime is known to be error-prone, significantly tougher to get it
right when compared to printf.

- Anand

In article <hbhv6c$84p$>,
says...

[ ... ]

> Not to attempt to discuss further; just another observation: 'printf'
> has several well-known problems related to the use of '...' while
> functions in <ctime> IIRC do not suffer from that. Hence the OP's
> apprehension (of "reverting to C code") is IMHO unfounded, and your
> likening of mechanisms from <ctime> to 'printf' does not work.

I think it's worth noting, however, that even though C's time
functions don't suffer from the _same_ problems as printf, they do
have some problems of their own. For example, a number use static
buffers that can be overwritten by successive calls to the same
function.

People can (and have) argued about whether iostreams are really a
_better_ alternative to C's standard I/O, but in the case of the time
functions, there's little real room for argument -- C++ simply
doesn't provide any alternatives.

--
Later,
Jerry.