comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Friendly GUI for windows building? - 5 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/c865fa27ccf9e327?hl=en
* C++ standards committee looking at adding Cairo to the C++ standard - 17
messages, 9 authors
http://groups.google.com/group/comp.lang.c++/t/0b3c6e40a26c7051?hl=en
* C++/QT/ARM Processors Cross-compiling/Programming Problem - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/32d49ff56804bf40?hl=en
* Overloaded function template resolution - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/43d848f835065043?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
==============================================================================
TOPIC: Friendly GUI for windows building?
http://groups.google.com/group/comp.lang.c++/t/c865fa27ccf9e327?hl=en
==============================================================================
== 1 of 5 ==
Date: Sun, Jan 5 2014 7:43 pm
From: Geoff
On Sun, 5 Jan 2014 23:36:42 +0000 (UTC), Rupert Miscavige
<ruoe@btasco.com> wrote:
>Paavo Helde wrote:
>
>> Rupert Miscavige <ruoe@btasco.com> wrote in news:lacm3d$osi$1
>> @speranza.aioe.org:
>>
>>> Francois Guillet wrote:
>>
>>>> The first solution I will try is yours. From what I read on fltk.org,
>>>> FTKL seems to be simple and fits the requirements.
>>>> Thanks for the reply!
>>>
>>> Bullshit. If they are so good, why aren't they compile a Windows binary
>>> distributable? That they require YOU to compile their crap is the first
>>> sign that their crap IS crap.
>>
>> Source-only distributions are not crap (many portable projects are
>> distributed like that) and even if this were not true, there is no
>> connection to the quality of the project itself. Bring up some facts
>> instead of biased opinions!
>
>Sure it is. Crap. The proof for this is that they are unable to compile a
>windows binary, for whatever reasons, then let the user using it.
>Directly, as they are supposed to do.
>
>You are an ignorant. You don't know crap and are unable to handle it.
Where's the beef?
Out of curiosity I downloaded the stable archive and they don't
provided ANY binaries, not for Windows, OSX or Linux. You have to
build them yourself regardless of the platform.
I opened the fltk.sln for VS2010 and built the entire framework
error-free in about 10 minutes.
A source distribution allows you to take any portion of it you may
like without having to drag all of the framework into your
application. It also allows you to build debug and release versions of
the framework. This seems entirely logical to me.
Shipping a DLL, a collection of libs, the headers and instructions
seems more cumbersome to use than a source distro.
== 2 of 5 ==
Date: Mon, Jan 6 2014 6:39 am
From: scott@slp53.sl.home (Scott Lurndal)
David FLEURY <dfleury2@free.fr> writes:
>Le 04/01/2014 11:51, Francois Guillet a �crit :
>> Hi
>>
>> Creating many windows and controls is very tedious when the parameters
>> of the CreateWindowEx function have to be set manually.
>>
>> I'm looking for a tool able to build code automatically from drag and
>> drop of objects (buttons, check boxes, edit controls...) onto a first
>> empty window, and allowing repositionning, sizing, property settings...
>>
>> This was provided in environments like C++ builder, but I'm searching
>> for a more light tool that would generate simple cpp and h files to
>> include in my project and that wouldn't need an obscure and heavy
>> library (I'm using codeblock/gcc/mingw).
>>
>> Some advises?
>>
>> Thanks
>
>You can give a chance to FTLK. It has not a very up-to-date look, and
>can be though to learn but it is small, free, and "easy" to enhance.
I believe that should be FLTK.
http://en.wikipedia.org/wiki/FLTK
I'm comfortable with Athena Widgets, myself :-)
== 3 of 5 ==
Date: Mon, Jan 6 2014 2:42 pm
From: woodbrian77@gmail.com
On Sunday, January 5, 2014 9:43:19 PM UTC-6, Geoff wrote:
>
> A source distribution allows you to take any portion of it you may
> like without having to drag all of the framework into your
> application. It also allows you to build debug and release versions of
> the framework. This seems entirely logical to me.
>
I agree, but think it's hard to get investors interested
in a 100% open source project.
Brian
Ebenezer Enterprises - John 3:16.
http://webEbenezer.net
== 4 of 5 ==
Date: Mon, Jan 6 2014 9:42 pm
From: Öö Tiib
On Tuesday, 7 January 2014 00:42:58 UTC+2, woodb...@gmail.com wrote:
> On Sunday, January 5, 2014 9:43:19 PM UTC-6, Geoff wrote:
> >
> > A source distribution allows you to take any portion of it you may
> > like without having to drag all of the framework into your
> > application. It also allows you to build debug and release versions of
> > the framework. This seems entirely logical to me.
>
> I agree, but think it's hard to get investors interested
> in a 100% open source project.
It is hard if they do not want to buy fame, or the project under
question is unlikely to provide fame. Fame is not cheap commodity.
== 5 of 5 ==
Date: Mon, Jan 6 2014 10:40 pm
From: Ian Collins
woodbrian77@gmail.com wrote:
> On Sunday, January 5, 2014 9:43:19 PM UTC-6, Geoff wrote:
>>
>> A source distribution allows you to take any portion of it you may
>> like without having to drag all of the framework into your
>> application. It also allows you to build debug and release versions of
>> the framework. This seems entirely logical to me.
>>
>
> I agree, but think it's hard to get investors interested
> in a 100% open source project.
Um, Linux, MySQL, PostgreSQL, Illumos, the BSDs...?
There are plenty of investors will to invest in companies who add value
(usually support or other, often also open source, add-ons) to open
source projects.
--
Ian Collins
==============================================================================
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 17 ==
Date: Sun, Jan 5 2014 8:59 pm
From: "Alf P. Steinbach"
On 06.01.2014 04:18, �� Tiib wrote:
>
> The future of anything depends heavily on first impressions it leaves.
> Console ... that is rather unimpressive. It is easier to attract and
> to teach C++ to kids when there is graphics API present right out of
> the box.
But I think Cairo may be too complex, too heavy, for kids.
Not that C++ isn't -- but tonight I saw a question from a 9-year old
on Stack Overflow, and he claimed to already have written a 4000+ lines
C++ program. I didn't write a program of that many lines until college
(but then, computers weren't available at all until high school).
I think the first one of that size that I made was "RealCalc", a general
expression evaluator with naming and graphing of formulas, written in
Pascal. I remember how nice it felt to demonstrate it to someone, doing
some electronic circuit simulation, yay, works! And what a down-trip it
was to discover that the way that I'd been passing files around as
arguments, was not supported by the language, like today's C++ formal
UB, only worse because it wasn't even meaningful enough to possibly
/could/ have been supported, it just worked by a fluke...
Cheers,
- Alf
== 2 of 17 ==
Date: Mon, Jan 6 2014 12:30 am
From: Öö Tiib
On Monday, 6 January 2014 06:59:07 UTC+2, Alf P. Steinbach wrote:
> On 06.01.2014 04:18, �� Tiib wrote:
> >
> > The future of anything depends heavily on first impressions it leaves.
> > Console ... that is rather unimpressive. It is easier to attract and
> > to teach C++ to kids when there is graphics API present right out of
> > the box.
>
> But I think Cairo may be too complex, too heavy, for kids.
I meant "for kids" not in literal sense but for anyone who is not
too experienced and tries C++.
I am unsure if there is plan that Cairo will be standardized. Cairo
is C library AFAIK. More likely they want to take Cairomm (or OFX
or Cinder) and evolve (and strip) some immediate mode graphics
library prototype out of it.
The immediate mode graphics are less used, less likely evolved,
easier to understand for novices but have more various libs.
Retained mode graphics have DirectX and OpenGL and it is
unlikely that hardware vendors want to support something more.
> Not that C++ isn't -- but tonight I saw a question from a 9-year old
> on Stack Overflow, and he claimed to already have written a 4000+ lines
> C++ program. I didn't write a program of that many lines until college
> (but then, computers weren't available at all until high school).
Yes, times change. Most kids know the touch-pad gestures better than
me. I also started with simple languages Basic and then Pascal as kid,
don't remember line counts but the printouts were long. :)
> I think the first one of that size that I made was "RealCalc", a general
> expression evaluator with naming and graphing of formulas, written in
> Pascal. I remember how nice it felt to demonstrate it to someone, doing
> some electronic circuit simulation, yay, works! And what a down-trip it
> was to discover that the way that I'd been passing files around as
> arguments, was not supported by the language, like today's C++ formal
> UB, only worse because it wasn't even meaningful enough to possibly
> /could/ have been supported, it just worked by a fluke...
I was young man when I first tried C (horror) and then C++ (also
shock). Translating, assembling and linking took ages, terrible
diagnostics, most errors were left undiagnosed. Graphics were
supported by language in Basic and (Turbo) Pascal already back
then. C++ had nothing. I basically had to learn how VGA card
and dot matrix printer work on low level to produce graphs.
About same was with mouse.
Modern day is other way around ... there are number of libraries
to choose. That might be even harder for novice than the *nothing*
that I had. Something accepted by committee, no matter if as C++
standard, as separate standard, as technical specification or as
technical report would be good thing.
== 3 of 17 ==
Date: Mon, Jan 6 2014 2:56 pm
From: Rui Maciel
Öö Tiib wrote:
> The future of anything depends heavily on first impressions it leaves.
> Console ... that is rather unimpressive.
I don't believe that's relevant at all. Just because something isn't included in the standard
it doesn't mean it doesn't exist.
Rui Maciel
== 4 of 17 ==
Date: Mon, Jan 6 2014 2:57 pm
From: Rui Maciel
Paavo Helde wrote:
> It would be a major relief if things like SVG rendering could be done
> cross-platform and with standard tools.
Is it really necessary to standardize those tools throught the C++ standard?
Rui Maciel
== 5 of 17 ==
Date: Mon, Jan 6 2014 10:05 pm
From: Öö Tiib
On Tuesday, 7 January 2014 00:56:44 UTC+2, Rui Maciel wrote:
> Öö Tiib wrote:
>
> > The future of anything depends heavily on first impressions it leaves.
> > Console ... that is rather unimpressive.
>
> I don't believe that's relevant at all. Just because something isn't
> included in the standard it doesn't mean it doesn't exist.
I do not understand. Are you saying that first impression is irrelevant?
My point was that C++ toolset leaves sad first impression as state of art.
C++ standard is guideline for people writing C++ compilers and standard
library implementations so it has everything to do with improving that
toolset.
== 6 of 17 ==
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.
== 7 of 17 ==
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
== 8 of 17 ==
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
== 9 of 17 ==
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 .
== 10 of 17 ==
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
== 11 of 17 ==
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
== 12 of 17 ==
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?
== 13 of 17 ==
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.
== 14 of 17 ==
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
== 15 of 17 ==
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
== 16 of 17 ==
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
== 17 of 17 ==
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.
==============================================================================
TOPIC: C++/QT/ARM Processors Cross-compiling/Programming Problem
http://groups.google.com/group/comp.lang.c++/t/32d49ff56804bf40?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Jan 6 2014 1:36 pm
From: Jorgen Grahn
On Sat, 2014-01-04, Saeed Amrollahi wrote:
...
> Recently, I'm involved in a QT/ARM Processor software development project.
...
> Q. Is it important to host and target computers have the same architecture,
> I mean both should be 32-bits (x86 or i586/i686) or both should be
> 64-bits (x86_64)?
No. That's why the distinction "host" and "target" exists. They
don't have to have /anything/ in common. With the right compiler and
libraries you can build MC68020 AmigaDOS software on a PDP-11, or
whatever ...
On the other hand, it makes life a lot easier if they are identical so
you don't have to cross-compile at all. But if the target is too rare
or too slow/limited to support a compiler, that's not an option.
...
> another problem is about kernel version: is it important
> Q. Is it important to host and target computers have the same kernel number (x.y.z)?
Only if it is to the cross-compilation tools you use, and that seems
unlikely. One of the main purposes of a cross-compiler is to make the
binaries produced independent from host environment details.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
==============================================================================
TOPIC: Overloaded function template resolution
http://groups.google.com/group/comp.lang.c++/t/43d848f835065043?hl=en
==============================================================================
== 1 of 2 ==
Date: Mon, Jan 6 2014 8:06 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: 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: 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
==============================================================================
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