Re: Working with Large Values (double)
On 2/24/2014 10:23 AM, jacob navia wrote:
Le 24/02/2014 15:54, Victor Bazarov a ?crit :
When I mentioned overloading, I did really mean *function* overloading.
Well, strange, since we were talking about the << syntax of c++ for
OUTPUT, what is operator overloading and NOT function overloading.
If you care to reread the thread, I decided to reply to you when you stated
On 2/24/2014 8:49 AM, jacob navia wrote:
> Le 24/02/2014 12:32, Juha Nieminen a ?crit :
>> The C version is not type safe, cannot be expanded with new types,
>
> In C++ you have to overload the operator << as far as I remember. In C
> you have to write a "Print_XXX" function. I do not see why C++ is so
> fundamentally better.
So, let me repeat.
C++ is so "fundamentally better" that you don't have to write Print_XXX
function with different XXX for every different type.
Moreover, making 'print_whatnot' a stand-alone function would probably
be a design mistake in that case anyway. Most likely it's better to
split the responsibilities between three parts of the design -- the
class that needs to be printed, the sink that handles the actual output
and the template that binds the two.
But again, this discussion is not about how to design an output for a
combination of object types and sinks, is it?
It is a pity that all my arguments are brushed aside as "a rant" and you
do not even go into them.
There is no depth in them that would allow anybody to "go into them",
unfortunately.
This is convenient for you of course, since the sorry state of affairs
in c++ because precisely too much operator overloading when formatting
is at the center of this dicussion.
Now, to come back to a function overload solution:
Having a SINGLE print function to print ANY object looks great at first
but then... how do you remember which one to use?
"Are you saying that I can dodge bullets?"
"I am saying that when you are ready, you won't have to."
(or something like that). You're still thinking in C terms. You don't
have to remember which function to use *when* your output subsystem is
designed and implemented properly, using not C but C++ mechanisms as
they are intended to be used.
Suppose
void print(XXX *data1);
void print(XXX *data1, FILE *sink);
void print(XXX *data1, int printFlags, FILE *sink);
void print(XXX *data1, int printFlags, int linewidth); // Uses stdout
void print(YYY *data2, long long printflags);
void print(YYY *data2, CUSTOMER *c, long long flags);
etc.
Now the programmer must remember which arguments/argument order is
necessary for each function... And since all have the SAME name
remembering them is MUCH more difficult than
void print_noargs(XXX *data1);
void printWithSink(XXX *data1, FILE *sink);
void printFlagsSink(XXX *data1, int flags, FILE *sink);
or other similar simple naming schema.
You see?
No, I don't see. What I see is a C approach to designing C++
interfaces, and *that* is the most common problem leading to the
dismissal of C++ features by those who come from long (too long if you
ask me) time use of C.
It's not impossible for C programmers to adopt the correct approach and
learn C++ ways -- I've seen it happen, but more often than not it's due
to what seems their lack of interest or fear to have to apply effort or
to leave the comfort of well-learned C idioms that they stay in their
playpen and keep trying to use their trusted building blocks instead of
getting to know a complex erector set.
IT DEPENDS!
If you have few "print" functions with identical number of arguments
overloading is OK, but as the print functions proliferate, it becomes
more and more difficult to use the correct one!
*IT DEPENDS*
That is what many C++ heads do not understand. The world is very complex
and single solutions are good in some contexts, bad in another,
the same as I said from operator overloading.
Thanks for your input.
You're welcome.
It looks that you're just starting on the journey that is C++. You have
made a few wrong steps and your feet start to ache or perhaps you
twisted your ankle because you weren't watchful enough for rocks just
underneath the surface. Two thoughts come to mind. Don't let a small
pain divert you from the right path. And, when in shallows, don't
pretend you're treading water -- others who have already passed that
part of the way will see right through that.
Good luck in your studies!
V
--
I do not respond to top-posted replies, please don't ask