DATETIME like YYYYMMDDHHMMSS

[Jazzhouse]

Hi,

How do you get the local date time as YYYYMMDDHHMMSS 14 digit string???

I am very new to C++, but if the MSDN tutorials are like that may be it
is better to go with GCC... :)

Ferhat

[Mike Wahler]

"White Wolf" <wo***@freemail .hu> wrote in message
news:cj******** **@phys-news1.kolumbus. fi...

Mike Wahler wrote:

I did not mean it will not compile on a C++ compiler. I guess when I
say C++ code (in the realm of this NG) I mean a bit more(*) "than just
code well-formed code which does not invoke undefined behavior and
implementation defined behavior which may alter its meaning".

(*) It more on contraints, so less code qualifies as C++ with that
definition.

So here's the crux: our definitions of what C++ is differs.
My meaning is: "does not violate requirements or constraints
imposed by 14882). Iterestingly, this does not preclude
syntactically correct code which produces undefined behavior.
Such code *is* C++, although it's certainly not 'good' code.

Useless C++, yes. But aren't we here to discuss useful ideas,
and ideas
which (if necessary/possible) use the full power of the language?

It's not always necessary to harness the full power in order
to get certain things done. I find that John's solution does
get the job done. Whether it's the 'best' way, I don't know,
since I don't know OP's specific criteria, if any.

-Mike

[Karl Heinz Buchegger]

White Wolf wrote:

[snip]
Yep. I understand. But that is not what I was talking about when you have
chosen to contradict me, without trying to understand what I mean - which is
rather unusual from you.

Excuse me for bailing in.
I think we all understood what you were trying to say.
But we don't agree (me too) with the wording you choosed.

<Quote from your response which started that all>
Which part of the above is C++?
</Quote>

What you should have said IMHO is this:
"While this is valid C++, it is not the recommended way to
do this in C++. In C++ we usually use streams instead of
the error prone printf() family of functions"

Attila, you want your response be seen in that way, while others
take your original response literally and argue that the posted
solution is perfectly valid C++ (from the language point of view).

I think there is no disagreement with the people you argue with,
that indeed in C++ the posted solution is a valid one although not
one a C++ coder would (or should) use.

Can all agree to that?

--
Karl Heinz Buchegger
kb******@gascad .at

[Old Wolf]

"White Wolf" <wo***@freemail .hu> wrote:

Old Wolf wrote:

"White Wolf" <wo***@freemail .hu> wrote:

There is no opportunity for buffer overruns in the posted code
(assuming an implementation that conforms to the C++ standard,
of course)

I see. Using sprintf, on a limited size buffer and there is no opportunity
of buffer overflow. Which C++ standard? Todays? 5 years from now? 50
years from now?

The standard won't change to break old but conforming code.
IMHO it's more likely that the standard libraries relating to
time will break backwards compatibility, than sprintf.

In fact there would be a buffer problem if someone changed their
computer clock to the year 10000; you can fix this by increasing
the buffer size.

It is pure C. There is nothing C++ to it. You can call it whatever you
want, that won't change the facts.

Everything in it is C++. Have you read the C++ standard?
The truth is that
C++ is a language in its own right (which has tried to
remain as compatible with C as possible, even to the extent
that some text files constitute valid programs in both
languages).

Yes. And that is why a pure C code needs explanation, telling why is it
posted to a C++ group. It may be the best C++ implementation possible. It
may not. But many people work on getting people to do C++ programming in
C++, and it does not do any justice to their work if others post pure C code
as C++.

Who was unjustly treated here? Until a few hours ago, John Harrison's
code is the only posted code that answers the OP's question.
And as he himself pointed out, nobody is trying to say that it is
the best solution. FWIW John's solution is about half the size
of Gary Labowitz's.

C++ is often referred to as a 'multi-paradigm' langauge. IMHO
it's silly to cut one paradigm out just because there is another
one available. It's like refusing to buy a coping-saw because
you already have a hacksaw.
But the answer which says, yeah it is also C++, is the wrong
answer. It sounds a lot like: Why did I do it? Because I could.

More like: Why did I do it? Because it is simple and it works.

If the question was: "Write a program that returns 42 to the OS"
would you reject:
int main() { return 42; }
as being "un-C++" ?

[Gary Labowitz]

"Old Wolf" <ol*****@inspir e.net.nz> wrote in message
news:84******** *************** ***@posting.goo gle.com...
<<snip>>
I finally got unlazy and checked Stroustrup. He says:

Because C++ and C code are often intermixed, C++ stream I/O is sometimes
mixed with the C printf() family of I/O functions. The Cstyle I/O functions
are presented by <cstdio> and <stdio.h>. Also, because C functions can be
called from C++ some programmers may prefer to use the more familiar C I/O
functions. Even if you prefer stream I/O, you will undoubtedly encounter
Cstyle I/O at some time.
[page 651]

It would appear he makes a distinction between C++ code (using I/O streams)
and C code (printf() family of I/O functions). C++ compilers provide support
of C code for backward compatibility (BC), and the framers of the standand
included it to ensure that the BC would be there. Mistakenly, in my opinion.
But as long as all the C-style string usage isn't completely replaced with
C++ equivalents, the BC support will have to remain. Perhaps forever. Thus,
stuff like c_str(), etc.

</rhetorical>
Of course, by the same argument, we should elimnate arrays, too. Or would
that break too much current C++ code?
</rhetorical>
--
Gary

[White Wolf]

Karl Heinz Buchegger wrote:

White Wolf wrote:

[snip]

Yep. I understand. But that is not what I was talking about when you
have chosen to contradict me, without trying to understand what I mean
- which is rather unusual from you.

Excuse me for bailing in.
I think we all understood what you were trying to say.
But we don't agree (me too) with the wording you choosed.

<Quote from your response which started that all>
Which part of the above is C++?
</Quote>

What you should have said IMHO is this:
"While this is valid C++, it is not the recommended way to
do this in C++. In C++ we usually use streams instead of
the error prone printf() family of functions"

Attila, you want your response be seen in that way, while others
take your original response literally and argue that the posted
solution is perfectly valid C++ (from the language point of view).

I think there is no disagreement with the people you argue with,
that indeed in C++ the posted solution is a valid one although not
one a C++ coder would (or should) use.

Can all agree to that?

"Which part of the above is C++?" was a bit meant to see who will jump.
What it did mean - and was meant to convey to those who chose to
understand - is C++ a.k.a. not C, a.k.a. better C, a.k.a. more than C etc.
My point was not more than getting half of what you have said. I do not say
for certain, that a C++ coder would or should not use the code... there may
be valid reasons to use it. But yet, since this NG spells C++, it is always
a good idea to mention if a code is made with C compatibility in mind.

--
WW aka Attila
:::
Usenet is like a herd of performing elephants with diarrhea - massive,
difficult to redirect, awe-inspiring, entertaining, and a source of mind -
boggling amounts of excrement when you least expect it. - Gene
Spafford,1992

[White Wolf]

Old Wolf wrote:

I see. Using sprintf, on a limited size buffer and there is no
opportunity of buffer overflow. Which C++ standard? Todays? 5 years
from now? 50 years from now?
The standard won't change to break old but conforming code.
IMHO it's more likely that the standard libraries relating to
time will break backwards compatibility, than sprintf.

In fact there would be a buffer problem if someone changed their
computer clock to the year 10000; you can fix this by increasing
the buffer size.

Runtime? And you are concentrating on changing the standard library only.
Other parts of the code may change as well.
C++ is often referred to as a 'multi-paradigm' langauge. IMHO
it's silly to cut one paradigm out just because there is another
one available. It's like refusing to buy a coping-saw because
you already have a hacksaw.
And yet, it does not hurt to mention that the code is pure C. Which is not
necessarily any decision about any quality in itself. Only a fair reminder.

But the answer which says, yeah it is also C++, is the wrong
answer. It sounds a lot like: Why did I do it? Because I could.

More like: Why did I do it? Because it is simple and it works.

There are differences between simple and simple.
If the question was: "Write a program that returns 42 to the OS"
would you reject:
int main() { return 42; }
as being "un-C++" ?

If you cared to read my posts, you would find the answer in a reply to Mike.

Since I have absolutely zero stamina please forgive me that I am really not
going to keep answering the same things anymore. I think I have done what I
possibly could to politely tell that you have all misunderstood my
intentions. Either you can accept that or keep arguing, but please solve it
without me. I have carpal, so this sub-thread hurts me double. :-(

So all of you please have a nice time, I regard this discussion as one which
has ended.

--
WW aka Attila
:::
Buy land - they've stopped making it. - Mark Twain