comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Overloaded function template resolution - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/43d848f835065043?hl=en
* C++ standards committee looking at adding Cairo to the C++ standard - 22
messages, 8 authors
http://groups.google.com/group/comp.lang.c++/t/0b3c6e40a26c7051?hl=en
* Registration for C++Now 2014 is Open - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/2c96a987a1685bf4?hl=en
* Overloaded template resolution - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/16d19f355b1d27b4?hl=en
==============================================================================
TOPIC: Overloaded function template resolution
http://groups.google.com/group/comp.lang.c++/t/43d848f835065043?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Jan 7 2014 12:52 am
From: bblaz
On 01/07/14 05:06, somenath wrote:
> While going through the book C++ Primer (Third edition) I came across the following code from the book.
>
> I have added the return statement and cout to trace the flow.
>
> #include<iostream>
> using namespace std;
> template<class T>
> T max(T t1, T t2) {
> cout<<"Inside Template Fun"<<endl;
> return t1;
> }
> //Two ordinary functions
> char max(char c1,char c2)
> {
> cout<<"Inside char Fun "<<endl;
> return c1;
> }
> double max(double d1, double d2 )
> {
> cout<<"Inside double Fun "<<endl;
> return d1;
> }
>
> int main(void)
> {
> float fd;
> max(0,fd);
> return 0;
> }
> According to the book the compiler should be reporting error for the following reason.
> "As the call (max(0,fd) ) is ambiguous ,only the ordinary functions are considered. Neither of these functions is selected as the best viable function, because the type conversions on the arguments are equally bad for both those functions: both arguments require standard conversion to match the corresponding parameter in either of the viable functions. The call is therefore ambiguous and is flagged as an error by the compiler."
>
> But When I compile the above code in g++ I do not get any error and when I ran the program I get the following output.
>
> �Inside double Fun�
>
> According to me in max(0,fd); the first argument 0 is converted to double and fd is converted to double so the max(double d1, double d2 ) is getting called and as the promotion will not cause any loss of precision so it is fine therefore there is no ambiguity exists.
>
> Is my understanding is correct? Am I wrongly interpreting author�s point of view?
>
Correct,
promotion to double is better than conversion to char.
13.3.3.2 � 4
Standard conversion sequences are ordered by their ranks: an Exact Match
is a better conversion than a
Promotion, which is a better conversion than a Conversion. Two
conversion sequences with the same rank
are indistinguishable unless one of the following rules applies: ...
4.6
Floating point promotion
A prvalue of type float can be converted to a prvalue of type double.
The value is unchanged.
This conversion is called floating point promotion.
4.8
The conversions allowed as floating point promotions are excluded from
the set of floating point conversions.
blaz
==============================================================================
TOPIC: C++ standards committee looking at adding Cairo to the C++ standard
http://groups.google.com/group/comp.lang.c++/t/0b3c6e40a26c7051?hl=en
==============================================================================
== 1 of 22 ==
Date: Tues, Jan 7 2014 6:46 am
From: ram@zedat.fu-berlin.de (Stefan Ram)
�� Tiib <ootiib@hot.ee> writes:
>C++ standard is guideline for people writing C++ compilers and standard
>library implementations so it has everything to do with improving that
>toolset.
I am giving classes in Java and C++. I try to stay focussed,
on-topic in these classes. So I do teach what is part of the
standard ISO C++ and standard Java SE / JDK.
Teaching Java SE, I can teach how to write JavaDoc, because
this is part of the standard JDK. C++ does not have a
standard for documentation comments, although there is
Doxygen. Contracts are essential for modern programming, and
contracts of classes and functions are being described in
the documentation. So it is good when a language supports this.
Teaching Swing in Java is great as a motivation to learn
Java and OOP in Java. People want to write GUI programs and
they can see that they absolutely need to learn OOP to do
this in Java. There are not licensing issues that I am aware of.
In C++, I cannot teach GUIs because that would be off-topic
in a C++ class. A GUI does not belong to the standard C++.
Sometimes people try to teach OOP in C++ with �class cow :
public animal { public void sound(){ ::std::cout << "moe\n"
...�, but students are annoyed by such examples, possibly
they feel to be treated like children, because the topic of
animal sounds usually is treated in daycare facilities for
children. And what's the point of a shape array with
circles and rectangles, when one then cannot paint the shapes?
I myself would not mind to teach C++ in a more abstract
manner. But at least some students seem to like to see some
GUI or graphics sometimes. If C++ would have gotten a
standard interface for sockets, GUI, doc comments, XML, and
all these things 10 years ago, it would be more important
today. But instead, on TIOBE it dropped from rank 2 in 1994
to rank 3 in 2009 and now to rank 4 in 2014 (in spite of the
new 2011 standard!). This is sad, it is a wasted opportunity.
== 2 of 22 ==
Date: Tues, Jan 7 2014 7:40 am
From: see.my.homepage@gmail.com
> I am giving classes in Java and C++. I try to stay focussed,
> on-topic in these classes. So I do teach what is part of the
> standard ISO C++ and standard Java SE / JDK.
Sorry, but even though I'm positive about adding some GUI support to C++, your argument is not convincing for me.
Your "inability" to teach students GUI in C++ is a result of your strict policy of limiting yourself to the standard C++ only. This might be equivalent to saying that there is no GUI in C++, which your students can easily refute by just looking at their desktop computers - they are already using GUI applications written in C++ (I am using such an application to write this post, for example), so obviously you have chosen not to teach them something useful. Does it make you a good teacher?
You might as well relax your strict policy and show them some Qt (or whatever) examples *today*. There is no need to wait for the std committee to put GUI in the standard library only so that you can keep your lectures "focused". I guess your students would prefer "useful" over "focused" any single day.
A side note: when I have recently shown some Qt examples to my Java colleague at work, he was literally shocked how easy it is to write GUI code in C++.
--
Maciej Sobczak * http://www.inspirel.com
== 3 of 22 ==
Date: Tues, Jan 7 2014 8:13 am
From: Wouter van Ooijen
>> I am giving classes in Java and C++. I try to stay focussed,
>> on-topic in these classes. So I do teach what is part of the
>> standard ISO C++ and standard Java SE / JDK.
>
> Your "inability" to teach students GUI in C++ is a result of your strict policy of
> limiting yourself to the standard C++ only.
I teach C++ too.
Each quarter, we combine two 'theoretical' courses with one 'practical'
(project) course. My C++ course runs in parallel with a game project, so
of course I use drawble graphic objects as examples for inheritance. For
the assignments I provide a library for drawing such objects. That
library itself is not a subject of the C++ course, but its interface,
and creating drawable objects with it, sure is. It does not matter much
which library I use, the important aspects are inheritance and (virtual)
overloading.
Restrict yourself to the C++ standard does not mean you can't use a real
library! Just focus on the interface.
Wouter van Ooijen
== 4 of 22 ==
Date: Tues, Jan 7 2014 1:50 pm
From: Jorgen Grahn
On Tue, 2014-01-07, Stefan Ram wrote:
...
> I am giving classes in Java and C++. I try to stay focussed,
> on-topic in these classes. So I do teach what is part of the
> standard ISO C++ and standard Java SE / JDK.
>
> Teaching Java SE, I can teach how to write JavaDoc, because
> this is part of the standard JDK. C++ does not have a
> standard for documentation comments, although there is
> Doxygen. Contracts are essential for modern programming, and
> contracts of classes and functions are being described in
> the documentation. So it is good when a language supports this.
Surely this doesn't mean you don't teach your students to document at
the right level (especially since you seem to know very well)? Even
if you ignore Doxygen, there are still /* */ and // so it's not as if
you cannot document your code in ISO C++.
...
For the rest, I just agree with the others who responded.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 5 of 22 ==
Date: Tues, Jan 7 2014 1:59 pm
From: woodbrian77@gmail.com
On Tuesday, January 7, 2014 9:40:09 AM UTC-6, see.my....@gmail.com wrote:
>
> Sorry, but even though I'm positive about adding some GUI support to C++, your argument is not convincing for me.
>
+1
When it comes to the standard, I keep this in mind:
"The stone which the builders rejected has become
the chief corner stone." Psalm 118:22
Iow, the C++ standard committee gets trumped here
and there. What's in the standard is often inferior
to alternatives outside the standard.
Brian
Ebenezer Enterprises - Heavenly code coming down
from the cloud.
http://webEbenezer.net
== 6 of 22 ==
Date: Tues, Jan 7 2014 2:08 pm
From: Ian Collins
Stefan Ram wrote:
> �� Tiib <ootiib@hot.ee> writes:
>> C++ standard is guideline for people writing C++ compilers and standard
>> library implementations so it has everything to do with improving that
>> toolset.
>
> I am giving classes in Java and C++. I try to stay focussed,
> on-topic in these classes. So I do teach what is part of the
> standard ISO C++ and standard Java SE / JDK.
>
> Teaching Java SE, I can teach how to write JavaDoc, because
> this is part of the standard JDK. C++ does not have a
> standard for documentation comments, although there is
> Doxygen. Contracts are essential for modern programming, and
> contracts of classes and functions are being described in
> the documentation. So it is good when a language supports this.
Which can be unit tests, which C++ certainly does support.
> Teaching Swing in Java is great as a motivation to learn
> Java and OOP in Java. People want to write GUI programs and
> they can see that they absolutely need to learn OOP to do
> this in Java. There are not licensing issues that I am aware of.
>
> In C++, I cannot teach GUIs because that would be off-topic
> in a C++ class. A GUI does not belong to the standard C++.
Teach them how things are done in the real world: pick a library and use it.
I never hear people complaining that they can't teach Python or PHP
because those languages lack a standard GUI.
--
Ian Collins
== 7 of 22 ==
Date: Tues, Jan 7 2014 2:13 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)
woodbrian77@gmail.com writes:
> What's in the standard is often inferior
>to alternatives outside the standard.
In the C++ standard, we have containers, algorithms,
an input/output library, a regular expressions library,
and more. What is there outside the standard to which
these are clearly inferior?
== 8 of 22 ==
Date: Tues, Jan 7 2014 2:24 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)
Ian Collins <ian-news@hotmail.com> writes:
>Which can be unit tests, which C++ certainly does support.
There are contracts that cannot be expressed as unit tests.
For example, we might require that �for all int values i:
0 <= f( i )< 100�. Unit tests can express random examinations
of this, but they cannot directly express a universal quantification
over a very large set.
Unit tests are great! But even in Java, they do not /replace/
the contracts in the JavaDoc, but are /added/ to them.
>Teach them how things are done in the real world: pick a library and use it.
What works in the real world does not always work in the
classroom. First, it does not even always work in the real
world (many software project fail, are cancelled, or overdue).
Next, the classes are already much too short to teach most
of what is in the standard C++, so they only teach a selection.
Teaching a �picked library� means that there will be even
less time to teach C++ proper. While some students might
like this, others might be alienated by it.
== 9 of 22 ==
Date: Tues, Jan 7 2014 2:29 pm
From: Wouter van Ooijen
>> Teach them how things are done in the real world: pick a library and use it.
>
> Teaching a �picked library� means that there will be even
> less time to teach C++ proper. While some students might
> like this, others might be alienated by it.
>
The suggestion is not to tceah a library, but to take your examples from
the use of the library. With a little added effort you can use the
library in the assignments.
Wouter
== 10 of 22 ==
Date: Tues, Jan 7 2014 2:38 pm
From: Ian Collins
Wouter van Ooijen wrote:
>>> Teach them how things are done in the real world: pick a library and use it.
>>
>> Teaching a �picked library� means that there will be even
>> less time to teach C++ proper. While some students might
>> like this, others might be alienated by it.
>>
>
> The suggestion is not to tceah a library, but to take your examples from
> the use of the library. With a little added effort you can use the
> library in the assignments.
That's correct. I can't see how adding something to the standard makes
it easier to teach. Whether a widget is a std::widget or one from a
library, it is still a widget.
--
Ian Collins
== 11 of 22 ==
Date: Tues, Jan 7 2014 2:31 pm
From: woodbrian77@gmail.com
On Tuesday, January 7, 2014 4:13:19 PM UTC-6, Stefan Ram wrote:
>
> In the C++ standard, we have containers, algorithms,
> an input/output library, a regular expressions library,
> and more. What is there outside the standard to which
> these are clearly inferior?
Rather than using map, I suggest one of these:
http://www.boost.org/doc/libs/1_55_0/doc/html/intrusive.html
Leigh's segmented arrays are better than deque:
i42.co.uk/stuff/segmented_array.htm
Using Boost Multi_index is better than using multiple
standard containers:
http://www.boost.org/doc/libs/1_55_0/libs/multi_index/doc/index.html
== 12 of 22 ==
Date: Tues, Jan 7 2014 2:43 pm
From: woodbrian77@gmail.com
> Rather than using map, I suggest one of these:
> http://www.boost.org/doc/libs/1_55_0/doc/html/intrusive.html
>
> Leigh's segmented arrays are better than deque:
> i42.co.uk/stuff/segmented_array.htm
>
> Using Boost Multi_index is better than using multiple
> standard containers:
> http://www.boost.org/doc/libs/1_55_0/libs/multi_index/doc/index.html
I think val_array is not used much and there are
alternatives to it that are used more often.
== 13 of 22 ==
Date: Tues, Jan 7 2014 2:44 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)
Ian Collins <ian-news@hotmail.com> writes:
>That's correct. I can't see how adding something to the standard makes
>it easier to teach. Whether a widget is a std::widget or one from a
... non-standard ...
>library, it is still a widget.
When something is announced as a �C++ course�, it is easier to
teach what actually /is/ part of C++, because people expect this
and also I myself deem this to be honest.
== 14 of 22 ==
Date: Tues, Jan 7 2014 2:45 pm
From: Jorgen Grahn
On Tue, 2014-01-07, Stefan Ram wrote:
> Ian Collins <ian-news@hotmail.com> writes:
Some extra context: SR wrote:
| Contracts are essential for modern programming, and
| contracts of classes and functions are being described in
| the documentation. So it is good when a language supports this.
>>Which can be unit tests, which C++ certainly does support.
>
> There are contracts that cannot be expressed as unit tests.
> For example, we might require that �for all int values i:
> 0 <= f( i )< 100�. Unit tests can express random examinations
> of this, but they cannot directly express a universal quantification
> over a very large set.
>
> Unit tests are great! But even in Java, they do not /replace/
> the contracts in the JavaDoc, but are /added/ to them.
I don't know Java, but are unit tests useful as documentation in /any/
interesting cases? Mine turn out, in the best case, as examples which
supplement the interface documentation but are rather useless if you
don't read the latter first.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 15 of 22 ==
Date: Tues, Jan 7 2014 2:53 pm
From: Ian Collins
Stefan Ram wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> That's correct. I can't see how adding something to the standard makes
>> it easier to teach. Whether a widget is a std::widget or one from a
>
> ... non-standard ...
>
>> library, it is still a widget.
>
> When something is announced as a �C++ course�, it is easier to
> teach what actually /is/ part of C++, because people expect this
> and also I myself deem this to be honest.
But you aren't teaching the library, you are using a part of it to
illustrate a concept. I assume you use a compiler in your course but
you don't consider learning how to use the compiler as part of the course.
--
Ian Collins
== 16 of 22 ==
Date: Tues, Jan 7 2014 2:56 pm
From: Ian Collins
Jorgen Grahn wrote:
> On Tue, 2014-01-07, Stefan Ram wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>
> Some extra context: SR wrote:
> | Contracts are essential for modern programming, and
> | contracts of classes and functions are being described in
> | the documentation. So it is good when a language supports this.
>
>>> Which can be unit tests, which C++ certainly does support.
>>
>> There are contracts that cannot be expressed as unit tests.
>> For example, we might require that �for all int values i:
>> 0 <= f( i )< 100�. Unit tests can express random examinations
>> of this, but they cannot directly express a universal quantification
>> over a very large set.
>>
>> Unit tests are great! But even in Java, they do not /replace/
>> the contracts in the JavaDoc, but are /added/ to them.
>
> I don't know Java, but are unit tests useful as documentation in /any/
> interesting cases? Mine turn out, in the best case, as examples which
> supplement the interface documentation but are rather useless if you
> don't read the latter first.
In most of my projects, they are the documentation (and implementation)
step between the user stories and the code. Unlike JavaDoc style
comments, they are always up to date!
--
Ian Collins
== 17 of 22 ==
Date: Tues, Jan 7 2014 3:00 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)
Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>I don't know Java, but are unit tests useful as documentation in /any/
>interesting cases?
I think that some people do have this idea. For example the Wikipedia
contains this:
�using unit-tests as a design specification has one significant advantage�
. It might be possible if one first establishes a formal specification
language and then a formal and bijective mapping to unit tests.
So, to contradict what I myself wrote in my previous post, the contract
�for all i, such that P(i): Q(f(i))�
might be expressed as:
�select a random value i using a random generator G(P,i)
assert Q(f(i))�
. But while this might help to express contracts, it might not be the
best approach to write unit tests. Unit test also need to fulfill
other demands, for example, to find as many bugs as possible.
And contracts might be easier for humans to understand when
expressed using English than using unit test.
== 18 of 22 ==
Date: Tues, Jan 7 2014 3:17 pm
From: Jorgen Grahn
On Tue, 2014-01-07, Ian Collins wrote:
> Jorgen Grahn wrote:
>> On Tue, 2014-01-07, Stefan Ram wrote:
>>> Ian Collins <ian-news@hotmail.com> writes:
>>
>> Some extra context: SR wrote:
>> | Contracts are essential for modern programming, and
>> | contracts of classes and functions are being described in
>> | the documentation. So it is good when a language supports this.
>>
>>>> Which can be unit tests, which C++ certainly does support.
>>>
>>> There are contracts that cannot be expressed as unit tests.
>>> For example, we might require that �for all int values i:
>>> 0 <= f( i )< 100�. Unit tests can express random examinations
>>> of this, but they cannot directly express a universal quantification
>>> over a very large set.
>>>
>>> Unit tests are great! But even in Java, they do not /replace/
>>> the contracts in the JavaDoc, but are /added/ to them.
>>
>> I don't know Java, but are unit tests useful as documentation in /any/
>> interesting cases? Mine turn out, in the best case, as examples which
>> supplement the interface documentation but are rather useless if you
>> don't read the latter first.
>
> In most of my projects, they are the documentation (and implementation)
> step between the user stories and the code.
I wonder if I would find them /useful/ as documentation too ... are
any of these projects publicly available so I could take a look?
> Unlike JavaDoc style
> comments, they are always up to date!
Yeah, well ... I don't understand what's so hard about keeping
documentation up to date. I frequently see people let it slip, and I
cannot figure out why. Incompetence? Mine is always up to date, but
that's because I write it to /use/ it. If I was forced to write
meaningless or superfluous documentation ("void foo() is a function
called foo which returns nothing") that would be a different issue.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 19 of 22 ==
Date: Tues, Jan 7 2014 3:22 pm
From: Mr Flibble
On 07/01/2014 22:31, woodbrian77@gmail.com wrote:
> On Tuesday, January 7, 2014 4:13:19 PM UTC-6, Stefan Ram wrote:
>>
>> In the C++ standard, we have containers, algorithms,
>> an input/output library, a regular expressions library,
>> and more. What is there outside the standard to which
>> these are clearly inferior?
>
>
> Rather than using map, I suggest one of these:
> http://www.boost.org/doc/libs/1_55_0/doc/html/intrusive.html
>
> Leigh's segmented arrays are better than deque:
> i42.co.uk/stuff/segmented_array.htm
My segmented_array container is not /better/ than deque it is just
/different/; it has different performance and invalidation
characteristics for certain operations compared with vector, deque *and*
list.
I plan on improving segmented_array by making a change that should turn
it into an ultimate general purpose container (when I can find the time
and I am not drinking gin).
/Flibble
== 20 of 22 ==
Date: Tues, Jan 7 2014 5:48 pm
From: woodbrian77@gmail.com
On Tuesday, January 7, 2014 5:22:00 PM UTC-6, Mr Flibble wrote:
>
> My segmented_array container is not /better/ than deque it is just
> /different/; it has different performance and invalidation
> characteristics for certain operations compared with vector, deque *and*
> list.
>
Your container is more flexible in that the user can pick the
segment size. That's better.
Brian
Ebenezer Enterprises
http://webEbenezer.net
== 21 of 22 ==
Date: Tues, Jan 7 2014 11:07 pm
From: Wouter van Ooijen
> When something is announced as a �C++ course�, it is easier to
> teach what actually /is/ part of C++, because people expect this
> and also I myself deem this to be honest.
You can't explain C++ without examples. Examples are not part of the
standard, so why not take real-world examples from the use of a library.
I assume your course has homework or something similar? There are no
assignments in the C++ standard. So when you select/write the
assignemnets, make them do somthing simple but real. Graphics are not
the only choice, but not a bad one.
Wouter
== 22 of 22 ==
Date: Wed, Jan 8 2014 1:45 am
From: Öö Tiib
On Wednesday, 8 January 2014 00:31:00 UTC+2, woodb...@gmail.com wrote:
> On Tuesday, January 7, 2014 4:13:19 PM UTC-6, Stefan Ram wrote:
> >
> > In the C++ standard, we have containers, algorithms,
> > an input/output library, a regular expressions library,
> > and more. What is there outside the standard to which
> > these are clearly inferior?
>
> Rather than using map, I suggest one of these:
> http://www.boost.org/doc/libs/1_55_0/doc/html/intrusive.html
'boost::intrusive' does not contain 'map'. So if someone needs
a map then 'std::map' is clearly superior for her. If someone does
not need a map then sure, why she used 'std::map'?
Note that the original intention of starters of boost was to build
libraries suitable for incorporation into the C++ language standard.
They actually have been quite successful with that. You basically
bring example from work that is meant for proposing to standard.
The major beneficial difference of intrusive containers is that
exactly same object can be in several different containers at same
time.
The other difference is that user has to manage the lifetime of
objects. Lot of users I have met have difficulties of optimal
resource management (coming from garbage collections) so that
difference can not be labeled as clearly beneficial.
I have seen cases in practice where 'boost::intrusive::set' results
with 4 times faster than 'std::set' with default allocator. 'std::set'
can be also made to perform as well as 'boost::intrusive::set' by
using custom allocator so it still does not mean it is clearly
inferior.
==============================================================================
TOPIC: Registration for C++Now 2014 is Open
http://groups.google.com/group/comp.lang.c++/t/2c96a987a1685bf4?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Jan 7 2014 12:11 pm
From: Boris Kolpackov
Hi,
Registration is now open for the eighth annual C++Now conference
(formerly BoostCon) which will be held in Aspen, Colorado, USA, May
12th to 17th, 2014.
C++Now is a general C++ conference for C++ experts and enthusiasts.
It is not specific to any library/framework or compiler vendor and
has three tracks with presentations ranging from hands-on, practical
tutorials to advanced C++ design and development techniques. In
particular, one of the tracks is dedicated exclusively to tutorials.
Last year the conference sold out pretty quickly and we expect it to
happen again this year. As a result, we encourage anyone interested
in attending to register early. Additionally, early bird hotel
reservations end January 10th.
For more information on registering, visit:
http://cppnow.org/2014/01/2014-registration-is-open/
For early bird hotel reservations, visit:
http://cppnow.org/location/lodging/
For general information about the conference, visit:
http://cppnow.org/about/
Boris
==============================================================================
TOPIC: Overloaded template resolution
http://groups.google.com/group/comp.lang.c++/t/16d19f355b1d27b4?hl=en
==============================================================================
== 1 of 2 ==
Date: Mon, Jan 6 2014 8:01 pm
From: somenath
While going through the book C++ Primer (Third edition) I came across the following code from the book.
I have added the return statement and cout to trace the flow.
#include<iostream>
using namespace std;
template<class T>
T max(T t1, T t2) {
cout<<"Inside Template Fun"<<endl;
return t1;
}
//Two ordinary functions
char max(char c1,char c2)
{
cout<<"Inside char Fun "<<endl;
return c1;
}
double max(double d1, double d2 )
{
cout<<"Inside double Fun "<<endl;
return d1;
}
int main(void)
{
float fd;
max(0,fd);
return 0;
}
According to the book the compiler should be reporting error for the following reason.
"As the call (max(0,fd) ) is ambiguous ,only the ordinary functions are considered. Neither of these functions is selected as the best viable function, because the type conversions on the arguments are equally bad for both those functions: both arguments require standard conversion to match the corresponding parameter in either of the viable functions. The call is therefore ambiguous and is flagged as an error by the compiler."
But When I compile the above code in g++ I do not get any error and when I ran the program I get the following output.
"Inside double Fun"
According to me in max(0,fd); the first argument 0 is converted to double and fd is converted to double so the max(double d1, double d2 ) is getting called and as the promotion will not cause any loss of precision so it is fine therefore there is no ambiguity exists.
Is my understanding is correct? Am I wrongly interpreting author's point of view?
== 2 of 2 ==
Date: Wed, Jan 8 2014 1:51 am
From: Öö Tiib
On Tuesday, 7 January 2014 06:01:48 UTC+2, somenath wrote:
> While going through the book C++ Primer (Third edition) I came across
> the following code from the book.
Will you post it every day now? Yes, it is a defect in book. All books contain
defects and some examples do not even compile. It is anyway good book.
So contact the authors if you want them to fix the defect.
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment