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

[John Harrison]

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

Rob Williscroft wrote:

White Wolf wrote in news:cj******** **@phys-news1.kolumbus. fi in
comp.lang.c++:

Which part of the above is C++?

#include <time.h>
#include <stdio.h>

int main()
{
time_t t = time(0);
struct tm* lt = localtime(&t);
char time_str[15];
sprintf(time_st r, "%04d%02d%02d%0 2d%02d%02d",
lt->tm_year + 1900, lt->tm_mon + 1, lt->tm_mday,
lt->tm_hour, lt->tm_min, lt->tm_sec
);
printf( "%s\n", time_str );
}

All of it apparently.

Starting with two deprecated headers and followed by pure C code. Here
and there introducing the opportunity for buffer overruns. I see. It is
code which compiles with a C++ compiler. I would not call it C++ code.

I see no buffer overflow before the year 10000. I don't care about that.

I was mainly trying to demonstrate to the OP that the same solution was
possible in C and C++ (he seemed concerned). But if you compare the partial
solution given by Gary Labowitz with mine I would still prefer the C like
solution above. Right tool for the right job I would say.

John

[Gary Labowitz]

"John Harrison" <jo************ *@hotmail.com> wrote in message
news:2s******** *****@uni-berlin.de...

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

Rob Williscroft wrote:

White Wolf wrote in news:cj******** **@phys-news1.kolumbus. fi in
comp.lang.c++:

Which part of the above is C++?

#include <time.h>
#include <stdio.h>

int main()
{
time_t t = time(0);
struct tm* lt = localtime(&t);
char time_str[15];
sprintf(time_st r, "%04d%02d%02d%0 2d%02d%02d",
lt->tm_year + 1900, lt->tm_mon + 1, lt->tm_mday,
lt->tm_hour, lt->tm_min, lt->tm_sec
);
printf( "%s\n", time_str );
}

All of it apparently.
Starting with two deprecated headers and followed by pure C code. Here
and there introducing the opportunity for buffer overruns. I see. It is code which compiles with a C++ compiler. I would not call it C++ code.

I see no buffer overflow before the year 10000. I don't care about that.

I was mainly trying to demonstrate to the OP that the same solution was
possible in C and C++ (he seemed concerned). But if you compare the

partial solution given by Gary Labowitz with mine I would still prefer the C like
solution above. Right tool for the right job I would say.

I've taught C, and I teach C++. There is not a mention of sprintf and printf
in my C++ courses. Why should there be?
I don't teach backward compatibility. I don't even like having to explain
why <ctime> is used instead of just <time>.
Since the languages have diverged, there is no sense to me in trying to keep
them together.
--
Gary

[JKop]

I've taught C, and I teach C++. There is not a mention of sprintf and
printf in my C++ courses. Why should there be?
I don't teach backward compatibility. I don't even like having to
explain why <ctime> is used instead of just <time>.
Since the languages have diverged, there is no sense to me in trying to
keep them together.

Preach!
-JKop

[John Harrison]

"Gary Labowitz" <gl*******@comc ast.net> wrote in message
news:cv******** ************@co mcast.com...

"John Harrison" <jo************ *@hotmail.com> wrote in message
news:2s******** *****@uni-berlin.de...

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

Rob Williscroft wrote:
> White Wolf wrote in news:cj******** **@phys-news1.kolumbus. fi in
> comp.lang.c++:
>
>> Which part of the above is C++?
>
> #include <time.h>
> #include <stdio.h>
>
> int main()
> {
> time_t t = time(0);
> struct tm* lt = localtime(&t);
> char time_str[15];
> sprintf(time_st r, "%04d%02d%02d%0 2d%02d%02d",
> lt->tm_year + 1900, lt->tm_mon + 1, lt->tm_mday,
> lt->tm_hour, lt->tm_min, lt->tm_sec
> );
> printf( "%s\n", time_str );
> }
>
> All of it apparently.

Starting with two deprecated headers and followed by pure C code. Here and there introducing the opportunity for buffer overruns. I see. It is code which compiles with a C++ compiler. I would not call it C++ code.
I see no buffer overflow before the year 10000. I don't care about that.

I was mainly trying to demonstrate to the OP that the same solution was
possible in C and C++ (he seemed concerned). But if you compare the

partial

solution given by Gary Labowitz with mine I would still prefer the C like solution above. Right tool for the right job I would say.

I've taught C, and I teach C++. There is not a mention of sprintf and

printf in my C++ courses. Why should there be?
Well if it's your course it is up to you, and I can see why you would not
want to teach two methods of doing the same thing, so it makes perfect sense
not to teach sprintf etc. Nevertheless I still find sprintf useful for
certain situations.

1) The code is more compact when the formatting is complex, as it was in
this example.

2) With sprintf the format information is localised in a single string. This
can be useful when trying to write applications for different locales. Of
course C++ libraries exist with the same facility (e.g. boost format). The
very fact that boost format exists demonstrates that the approach taken by
sprintf is useful.

3) There is also considerably less overhead in sprintf than ostringstream. I
almost always prefer it to ostringstream when doing one off formatting tasks
like the OP's.
I don't teach backward compatibility. I don't even like having to explain
why <ctime> is used instead of just <time>.
Since the languages have diverged, there is no sense to me in trying to keep them together.

I'm not trying to keep anything together, just picking what I see as the
right tools for this particular task. Obviously it a judgement call, and
different people will choose different methods. I'm not trying to say my
method is the best, just that it is valid.

john

[Gary Labowitz]

"John Harrison" <jo************ *@hotmail.com> wrote in message
news:2s******** *****@uni-berlin.de...

"Gary Labowitz" <gl*******@comc ast.net> wrote in message <<snip>> I'm not trying to keep anything together, just picking what I see as the
right tools for this particular task. Obviously it a judgement call, and
different people will choose different methods. I'm not trying to say my
method is the best, just that it is valid.

Thanks, John, it's a reasonable response.
Look, when I get a call to do some Access 2 work (and I did about a year
ago) I had to explain that I had long ago uninstalled that version and moved
on. The guy was very disappointed. I had a job updating a FoxPro program a
while back, and they wouldn't convert to Visual FoxPro. What they wanted was
virtually undoable and I told them so. I've been through the trauma of
learning enough new versions of languages to want to maintain lots of
versions --- in general I pick up the new version and move on. My current
internal debate is with VB6.0 and VB .NET. I have them both installed and I
hate like hell to give up VB 6.0. But I guess it will happen if I stick
around much longer.

I have always hated the languages that maintain lots of old version
constructs for backward compatibility. They don't want to break all the old
code, and you can't force people to upgrade all that software in a short
timeframe, but when? Microsoft puts the screws on by naming a date and
dropping support after that. It's cruel I guess, but otherwise they will
sink in a quagmire of versions. It's one of the worst aspects of computing.
Hard won knowledge is hard to let go of, and the new stuff can be very hard
to learn. Will we ever get rid of C-style strings in C++? Probably not. One
book I'm using now mentions them in an Appendix, that's how little they are
needed -- except for backwash I/O and old programs. I have to teach it, but
if you teach string class first they look like a real waste of time and
effort.

Well, I can cut and run (being over the age of sticking around). But what of
my students? They are graduating in years like 2006, 2008, and still
programming like it was 1991. I'm getting to hate it. [This is in the
category of "Don't get me started."]
--
Gary

[JKop]

Will we ever get rid of C-style
strings in C++? Probably not.

I don't see what's wrong with C-style strings. I use them 90% of the time,
unless I *need* an std::string. Why? Efficency.

A string is and always will be just an array of characters after all! As for
the whole null character thing... two possible methods:

A) Use a null character which signifies the end of the string, as in:

char blah[6] = { 'H', 'e', 'l', 'l', 'o', '\0' };
B) Have a field for the length of the string:

struct Blah
{
unsigned length;

char blah[5];
};

Blah poo = { 5, { 'H', 'e', 'l', 'l', 'o' } };
The former was chosen and it works well. It has advantages too: There's no
limit put on the length of the string, whereas with the latter, the length
is limited to the maximum value of an "unsigned".

As for std::string and std::ostringstr eam, I use them when want I want to do
would take me a few hours to code if I were to do it by myself, whereas it
would only take a few mins with these classes.

-JKop

[White Wolf]

Gary Labowitz wrote:

All of it apparently.

Starting with two deprecated headers and followed by pure C code. Here
and there introducing the opportunity for buffer overruns. I see. It
is code which compiles with a C++ compiler. I would not call it C++
code.

Oh, Atilla, you are SO fussy!

Neither. I am Attila and I believe that in a C++ group pure C code should
be flagged as such. BTW the sig-quotes are REALLY random. Does my random
number device try to tell something? To whom? ;-)

--
WW aka Attila
:::
Never argue with an idiot. They drag you down to their level then beat you
with experience.

[White Wolf]

Mike Wahler wrote:

All of it apparently.

Starting with two deprecated headers and followed by pure C code.

which also qualifies as 'pure C++ code'.

I see. Do you not want to see the point?

Here and
there introducing the opportunity for buffer overruns.

That's a quality issue.

Is it? Or is it that code with C++ design is less likely to have that
problem?

I see. It is code
which compiles with a C++ compiler. I would not call it C++ code.

Call it what you like. It *is* C++, according to 14882.

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

--
WW aka Attila
:::
Man is a peculiar creature. He spends a fortune making his home
insect-proof and air-conditioned, and then eats in the yard.

[John Harrison]

I see. It is code
which compiles with a C++ compiler. I would not call it C++ code.

Call it what you like. It *is* C++, according to 14882.

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

What is this please?

int main()
{
return 0;
}

john

[White Wolf]

John Harrison wrote:

"White Wolf" <wo***@freemail .hu> wrote in message [SNIP]

All of it apparently.

Starting with two deprecated headers and followed by pure C code. Here
and there introducing the opportunity for buffer overruns. I see. It
is code which compiles with a C++ compiler. I would not call it C++
code.

I see no buffer overflow before the year 10000. I don't care about that.

I see. I do, since I do not believe that this is the only way of failure
waiting there.
I was mainly trying to demonstrate to the OP that the same solution was
possible in C and C++ (he seemed concerned). But if you compare the
partial solution given by Gary Labowitz with mine I would still prefer
the C like solution above. Right tool for the right job I would say.

I have asked if it was a C++ solution. Later (having got the reply I did) I
hinted on it, that it had a buffer overflow opportunity. Prior to that all
I have been trying to point out is that it is C and not C++. Reason being
that we have tried for ages here to show C++ solutions or flag the pure C
solutions as such. Or tell (for dumb people like me) why is that C code the
best C++ to use.

--
WW aka Attila
:::
When the pupil is ready, the teacher will come.