ambigious constructor of QextSreialPort

[GoogleCodeExporter]

Overloaded QextSerialPort constructors are providing two ambigious
function pairs:

1. QextSerialPort() and QextSerialPort(QueryMode mode = EventDriven)
2. QextSerialPort(const QString & name) / QextSerialPort(const QString &
name, QueryMode mode = EventDriven)

My way so solve this problem was to remove (comment out for this time) the
first ones respectively, because I think they are somhow redundant.

Original issue reported on code.google.com by ulrich.l...@hhi.fraunhofer.de on 2 Sep 2009 at 9:09

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

attached patch adressing following related issues:
* ADDED:  setPortName also excepts  empty strings and then uses the default 
port name
          -> now there is really a port name set when using e.g. the
             QextSerialPort(const QextSerialPortSettings& settings,
             QextSerialPort::QueryMode mode) constructor.
* REMOVED: ambigious constructors:
           - QextSerialPort()
           - QextSerialPort(const QString & name)

Original comment by ulrich.l...@hhi.fraunhofer.de on 8 Sep 2009 at 1:08

Attachments:

• qextserialport-ambigious-constructors.patch

[GoogleCodeExporter]

I hit this problem too.  Maybe only pops up using VS compiler?   I've got 
MSVC2008 and 
the ambiguous constructors will only throw a warning when compiling 
qextserialport, but 
any code trying to create an instance of it will not compile.

Original comment by leo.spal...@gmail.com on 16 Sep 2009 at 10:17

[GoogleCodeExporter]

Oh, I forgot to mention my setup. I used the Qt Creator SDK on Windows XP, so 
gcc is
used.

When the penny dropped, everything is pretty clear here. I hope I can help you 
to
understand the issue. If you already do, just ignore my writings.

The given default value in e.g. QextSerialPort(QueryMode mode = EventDriven)
automatically provides the caller two forms of calling the same function. One
possibility is with the argument and one without. The functions definition is 
not
affected by this activity and is just provided with the default value. The 
compiler
is inserting the default value if you don't provide a parameter.

Knowing that - how should the compiler figure out which function you want to 
use:
the one with one parameters default value assigned or the other function 
without any
parameters.

So, we ran into this issue, because we haven't used the long version of the
functions. Using QextSerialPort(EventDriven) dows not produce errors. Other 
users
seem to use just the long versions.

Can you please verify if supplied the patch works for you?

Original comment by ulrich.l...@hhi.fraunhofer.de on 16 Sep 2009 at 11:10

[GoogleCodeExporter]

Yeah I didn't apply the patch, but made similar changes on my own that worked.  
 Not
sure how this is working for anyone in its current state. 

Original comment by leo.spal...@gmail.com on 18 Sep 2009 at 9:13

[GoogleCodeExporter]

I removed the ambiguous constructors - this should be resolved.

Original comment by lst...@gmail.com on 24 Oct 2009 at 11:44

• Changed state: Fixed