To go with Go or C/C++?

J

Jorgen Grahn

My experience too.
This is probably acceptable for some types of technical software
(e.g. a C++ compiler). For most things, however, you'll want
a local language interface

It's tricky to talk about "most things" WRT C++. You've worked in
areas where i18n is important; Paavo has worked in areas where it
isn't.

For the record, I'm in Paavo's camp. In ~20 years across many
projects and products, I've never had to deal with this. (And for
hobby projects, since I strongly prefer English user interfaces I have
had no reason to do it there either.)

Bottom line: I am grateful for gcc's format string checker. It has
saved me many times.

/Jorgen
 
J

Jorgen Grahn

.
(The case of
dates is particularly special: there are a number of
conventions, which don't respect the usual locales---US military
uses a different format than civilian use, etc.

You don't even have to go that far. I tried the other day to write a
encoder/decoder for HTTP dates, but discovered that the standard
(POSIX) functions were of no use, since they are locale-sensitive and
also time zone sensitive. There's no way to make strftime() generate
"Sunday" without setting a locale where Sunday is spelled like that.

This kind of thing affects most internet protocols. Probably Boost
has functions which do the right thing, but it seems common for
software to basically implement this from scratch, leap day
calculations and all[1]. Ugh.

/Jorgen

[1] I looked at the popular 'nginx' web server.
 
W

woodbrian77

It's tricky to talk about "most things" WRT C++. You've worked in

areas where i18n is important; Paavo has worked in areas where it

isn't.



For the record, I'm in Paavo's camp. In ~20 years across many

projects and products, I've never had to deal with this. (And for

hobby projects, since I strongly prefer English user interfaces I have

had no reason to do it there either.)

I'm with you and Paavo also.


Brian
Ebenezer Enterprises - John 3:16
http://webEbenezer.net
 
J

Jorgen Grahn

(The case of
dates is particularly special: there are a number of
conventions, which don't respect the usual locales---US military
uses a different format than civilian use, etc.

You don't even have to go that far. I tried the other day to write a
encoder/decoder for HTTP dates, but discovered that the standard
(POSIX) functions were of no use, since they are locale-sensitive and
also time zone sensitive. There's no way to make strftime() generate
"Sunday" without setting a locale where Sunday is spelled like that.

This kind of thing affects most internet protocols. Probably Boost
has functions which do the right thing, but it seems common for
software to basically implement this from scratch, leap day
calculations and all[1]. Ugh.

Boost DateTime library is of some help, but extremely hard to use, and

That sounds like the Boost I keep hearing about :-/. I never used any
of Boost myself, partly because I found even the documentation hard to
understand, for the libraries I considered using.

[problems]
Hopefully it has improved meanwhile, I needed to develop the datetime support some years
back and haven't looked since.

In some sense this is expected as the topic itself is very hairy [...]

Some of it yes, but some parts are not, and should have a similarly
non-hairy interface.

I was hoping DateTime was all about removing hairiness, and maybe
provide support specifically targeting commonly used areas, such as
Internet mail dates, HTTP dates and "yesterday/a month from now"
calculations.

(And perhaps it does -- I still haven't checked.)

/Jorgen
 
J

Jorgen Grahn

One interesting thing what I learned when dealing with dates and times is
that a day (same date) is nowhere near of 24 hours. Any certain date is
essentially a string label attached to all local events around the world,
and the same label is valid for about 48 hours or more, depending on the
local timezone rules around the international date line. So a date-time
type or even time_t are not just more exact representations of the date
type (like double and float), they are very different beasts.

Yes. Discovered this the hard way back in the mid-1990s, when I
represented a date in a file format as the number of seconds since the
AmigaDOS Epoch (1st of January 1980 IIRC, in whatever time zone you
happened to be in). The problems/uncertainties caused by that
decision never quite went away (I still use the file format, 20 years
later).

/Jorgen
 
S

Stuart

On *2013-05-13T12:07+00:00*, James Kanze wrote:
[snip]
Or just to use ISO format everywhere, but the world isn't
ready for that yet.)
[snip]

I'm ready, see?

Stuart

PS: I don't know what timezone you live in, so I gave you a +00:00.
 
J

Jorgen Grahn

On *2013-05-13T12:07+00:00*, James Kanze wrote:
[snip]
Or just to use ISO format everywhere, but the world isn't
ready for that yet.)
[snip]

I'm ready, see?

2013-05-13T12:07+00:00

Too bad it's so ugly. The 'T' I mean; I don't mind this at all:

2013-05-13 12:07 +00:00

It seems to be easily avoidable though:

4.3.2 NOTE: By mutual agreement of the partners in information
interchange, the character [T] may be omitted in applications
where there is no risk of confusing a date and time of day
representation with others defined in this International
Standard."
https://en.wikipedia.org/wiki/ISO_8601#cite_note-13

/Jorgen
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,955
Messages
2,570,117
Members
46,705
Latest member
v_darius

Latest Threads

Top