Working with Large Values (double)

[Ike Naar]

Le 24/02/2014 16:43, Wouter van Ooijen a ?crit :

actually
c = strcatMany(a,b,NULL);

What's the type of c in the line above?
(Note that strcatMany returns an int).

 

[Gerhard Fiedler]

See, that's the C++ programmer view. A real programmer will use ...

This sounds as if you think that a C++ programmer is not a real
programmer

... snprintf when and where it makes sense ...

Sure... I thought that was a given.

... and not worry about "encapsulating" it ...

Well, when programming, I rarely think in single programming lines but
more about bigger concepts. And there, "encapsulation" is always
important, no matter the language.

... and doesn't care about spurious "language purity".

That idea of "language purity" seems to be yours; it definitely wasn't
part of my post. Does that make you an "unreal" programmer?

examples from C++ operating system:

Not sure what a "C++ operating system" is. But I do understand (and
occasionally use) the printf-family of functions, if that was the point.

Letting the compiler check arguments, even on user-defined functions
is trivial with a good compiler:

Try letting the compiler check the argument types when using a variable
as formatting string.

Gerhard

 

[Victor Bazarov]

Try letting the compiler check the argument types when using a variable
as formatting string.

I've never seen a case where it makes sense to use a variable as a
formatting string[*]. Can you describe a case where it does make sense
and it doesn't cause a potential security problem?

<shrug> All you need to imagine is selection between different formats
based on a run-time expression, like

const char* fmt[] = { "%d", "%p", "%s" };
...
int i = some_runtime_value;
...
printf(fmt[i % (sizeof(fmt)/sizeof(*fmt))], whatever);

What security problem do you see here?

[*] absent a wrapper function that uses __attribute__((printf(x,y))), anyway.

V

 

[Dombo]

Op 25-Feb-14 0:52, jacob navia schreef:

Le 25/02/2014 00:39, Dombo a écrit :

As you know the equality operator is "==" and NOT "=" that means store
the right hand side in the left hand side...

In C it is, not in mathematical notation. So how come you could easily
make this distinction in this example, but not in case of your string
example?

The discussion is about overusing overloading for output, and I think
most participants agree that it is a PITA.

If have no problems with the use of function overloading for output, in
fact I believe it is a good choice since it allows it to be extended
transparently for the user. That doesn't mean I particularly like the
overloading of the << operator (minor gripe) or how iostreams deals with
formatting (big gripe).

Now, could a "printf" based
approach: a (mini) "language" and a run time interpreter/formatter be
better suited to output than an overloaded operator?

That is my point.

Why a runtime interpreter? I'd much rather see as much as reasonably can
be done at compile time, including checks and with type safety. The
Boost Format library seems to be a nice compromise between the ease of
formatting of printf and the extendability, type safety and flexibility
of the iostreams.

 

[Ian Collins]

Try letting the compiler check the argument types when using a variable
as formatting string.

I've never seen a case where it makes sense to use a variable as a
formatting string[*]. Can you describe a case where it does make sense
and it doesn't cause a potential security problem?

Simple internationalisation. I've worked on embedded projects where we
used different sets of format strings for different languages. No
security risks there.

[*] absent a wrapper function that uses __attribute__((printf(x,y))), anyway.

Where is that defined in the C++ standard?

 

[David Brown]

Try letting the compiler check the argument types when using a variable
as formatting string.

I've never seen a case where it makes sense to use a variable as a
formatting string[*]. Can you describe a case where it does make sense
and it doesn't cause a potential security problem?

Simple internationalisation. I've worked on embedded projects where we
used different sets of format strings for different languages. No
security risks there.

That would be my thought. You might have something like this:

typedef enum { formatUK, formatUS } dateFormatChoices;
static const char dateFormatStrings[] = {
"%1$02d/%2$02d/%3$04d", "%2$02d/%1$02d/%3$04d"
}
void printDate(dateFormatChoices i, int day, int month, int year) {
printf(dateFormatStrings, day, month, year);
}

(That particular example relies on posix printf with parameters - if you
can't re-arrange parameter order like that, variable format strings are,
I think, significantly less useful.)

[*] absent a wrapper function that uses __attribute__((printf(x,y))),
anyway.

Where is that defined in the C++ standard?

 

[Ian Collins]

Try letting the compiler check the argument types when using a variable
as formatting string.

I've never seen a case where it makes sense to use a variable as a
formatting string[*]. Can you describe a case where it does make sense
and it doesn't cause a potential security problem?

Simple internationalisation. I've worked on embedded projects where we
used different sets of format strings for different languages. No
security risks there.

That would be my thought. You might have something like this:

typedef enum { formatUK, formatUS } dateFormatChoices;
static const char dateFormatStrings[] = {
"%1$02d/%2$02d/%3$04d", "%2$02d/%1$02d/%3$04d"
}
void printDate(dateFormatChoices i, int day, int month, int year) {
printf(dateFormatStrings, day, month, year);
}

(That particular example relies on posix printf with parameters - if you
can't re-arrange parameter order like that, variable format strings are,
I think, significantly less useful.)

The case I was thinking of was a monitoring device that displayed the
name of a unit (such as "Battery Time Remaining") or menu items in the
language selected by the user. Nothing fancy.

 

[David Brown]

Scott Lurndal wrote:

Try letting the compiler check the argument types when using a
variable
as formatting string.

I've never seen a case where it makes sense to use a variable as a
formatting string[*]. Can you describe a case where it does make
sense
and it doesn't cause a potential security problem?

Simple internationalisation. I've worked on embedded projects where we
used different sets of format strings for different languages. No
security risks there.

That would be my thought. You might have something like this:

typedef enum { formatUK, formatUS } dateFormatChoices;
static const char dateFormatStrings[] = {
"%1$02d/%2$02d/%3$04d", "%2$02d/%1$02d/%3$04d"
}
void printDate(dateFormatChoices i, int day, int month, int year) {
printf(dateFormatStrings, day, month, year);
}

(That particular example relies on posix printf with parameters - if you
can't re-arrange parameter order like that, variable format strings are,
I think, significantly less useful.)

The case I was thinking of was a monitoring device that displayed the
name of a unit (such as "Battery Time Remaining") or menu items in the
language selected by the user. Nothing fancy.

In cases like that (if I am reading you correctly), for printing a
variable char* p

printf(p);

you could use

printf("%s", p);

That version is arguably safer (it is /definitely/ safer if your strings
come from elsewhere, but I don't expect that applies in your case), and
probably runs faster.

 

[David Brown]

Try letting the compiler check the argument types when using a variable
as formatting string.

I've never seen a case where it makes sense to use a variable as a
formatting string[*]. Can you describe a case where it does make sense
and it doesn't cause a potential security problem?

Simple internationalisation. I've worked on embedded projects where we
used different sets of format strings for different languages. No
security risks there.

Unfortunately the strictly positional nature of the input parameters
in the printf functions has always led us to use our own replacement.

If you've got a posix extended printf, then the input parameters don't
have to be strictly positional (see my example).

 

[Gerhard Fiedler]

Try letting the compiler check the argument types when using a
variable as formatting string.

I've never seen a case where it makes sense to use a variable as a
formatting string[*]. Can you describe a case where it does make
sense and it doesn't cause a potential security problem?

Not sure what you call a security problem, but user-selectable output
languages are a pretty common requirement.

Gerhard

 

[Seungbeom Kim]

Because there is no ADDITION being done when a and b are STRINGS but a
concatenation of two strings, what is *completely different*. If a and
b are strings we have

a+b != b+a

what goes against all the mathematical basis of addition as normal
people use that word.

That is why string "addition" is an ABUSE of overloading.

Mathematical operators do not define the abuse of C++ operator
overloading. If they did,
* '=' as assignment (instead of equality),
* '<<' as left-shift (instead of 'much less than'),
* '%' as remainder (instead of percent), or
* '|' as bitwise OR (instead of 'divides'), etc.
would all be an abuse as well.

In the same vein, shifting left an object to print it just because the
opeartor << looks like the head of a left arrow or suggests "put into"
is NONSENSE and an abuse of the overloading concept.

'<<' is defined both as a left-shift operator and a stream insert
operator in the same document that defines C++. The fact that << is
used for one doesn't automatically make the other usage an abuse.

 

[Jorgen Grahn]

jacob navia schreef op 24-Feb-14 3:34 PM:

In true C++: if that is what you want it is cetainly possible, just like
you can have print_xxx functions if you want to.

I think I would prefer to reserve operator<<(person) for (debug)
printing of ALL data in person, and have separate getters for the items
that you might want to print, like

std::cout
<< std::setw( 30 ) << person.name()
<< " lives at "
<< std::setw( 60 ) << person.adress();

This keeps *what* you want to print separate from *how* you want to
print it.

I think what jacob navia is after would be better done as a bunch of
classes which only know how to format a Customer, each in its unique
fashion:

std::cout << ForMailingLabel(some_customer);
std::cout << ForGreetingMessage(some_customer);
std::cout << ForTheNSA(some_customer);

(Sorry about the bad naming; I don't deal with customers so I don't
know what you want to print or why.)

/Jorgen

 

[jacob navia]

Le 26/02/2014 23:30, Jorgen Grahn a écrit :

I think what jacob navia is after would be better done as a bunch of
classes which only know how to format a Customer, each in its unique
fashion:

std::cout << ForMailingLabel(some_customer);
std::cout << ForGreetingMessage(some_customer);
std::cout << ForTheNSA(some_customer);

(Sorry about the bad naming; I don't deal with customers so I don't
know what you want to print or why.)

/Jorgen

Exactly, and I like specially the last one:

std::cout << ForTheNSA(some_customer);

!!!

 

[Stuart]

I think what jacob navia is after would be better done as a bunch of
classes which only know how to format a Customer, each in its unique
fashion:

std::cout << ForMailingLabel(some_customer);
std::cout << ForGreetingMessage(some_customer);
std::cout << ForTheNSA(some_customer);

[snip]


Exactly, and I like specially the last one:

std::cout << ForTheNSA(some_customer);

!!!

+1.

If the NSA was really that good, they should slip it into the C++
standard and make it a required method for each class ;-)

Regards,
Stuart

 

[David Brown]

I think what jacob navia is after would be better done as a bunch of
classes which only know how to format a Customer, each in its unique
fashion:

std::cout << ForMailingLabel(some_customer);
std::cout << ForGreetingMessage(some_customer);
std::cout << ForTheNSA(some_customer);

[snip]


Exactly, and I like specially the last one:

std::cout << ForTheNSA(some_customer);

!!!

+1.

If the NSA was really that good, they should slip it into the C++
standard and make it a required method for each class ;-)

This explains the "hidden overheads" in C++ that C fans always complain
about...

 

[Jorgen Grahn]

"Seldom needs" is such a tired argument. I still remember when it was
used to defend Windows3 as "better" than actual multi-tasking OS's.

My main issue was with "the correct type was chosen from the start"
part. I distrust strategies which depend on getting things right
in an initial design.

And changing the types of existing variables is one of my main
ways of improving C++ code. Wrapping all those uint32_t in classes,
and so on.

/Jorgen

 

[Wouter van Ooijen]

My main issue was with "the correct type was chosen from the start"

part. I distrust strategies which depend on getting things right
in an initial design.

I totally agree. Quality is mostly the result of a long struggle,
feeding new insights and experiences back into the design. Rembember,
99% transpiration.

Wouter

 

[woodbrian77]

I totally agree. Quality is mostly the result of a long struggle,
feeding new insights and experiences back into the design. Rembember,
99% transpiration.

Yeah, and some companies have to switch languages in the
middle of a project because their initial choice isn't
working out for some reason.


Brian
Ebenezer Enterprises
http://webEbenezer.net

 

[Stuart]

But not of safety, extensibility or absraction.

+1

Every time I get back to the love of my life (erm, the second one, I
mean, just in case you are reading this, my darling), C++, I'm
tremendously relieved that I can write
somestream << "Processed " << current << " out of " << total << "\n";
instead of
buffer.appendString ("Processed %i out of %i", current, total);
because I keep forgetting with secret code to put after the percent
character. Was it %i for integer? Or %d for decimal?

And don't get me started on the syntax for printing with a precision of
2 decimal places and a fixed width. I would have to browse through the
online help in order to get that right, so I'd rather use setw and such.

Admittedly this can get ugly if you have to write lots of such code, but
for someone like me, who does this kind of thing only once in a month,
the C++ syntax is way more verbose.

Just my 2 cents.

Stuart

 

[jacob navia]

Le 04/03/2014 10:52, Juha Nieminen a écrit :

Oh, I could write an entire book with all the problems that C has.
Don't even get me started.

Sure, better not. You could start by reading the problems of C++, for
instance here:

http://yosefk.com/c++fqa/index.html

Each language is an approximation to perfection Mr. Has some bright
things and some bad things. There is no magic bullet.