Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
On Monday, June 01, 2015 10:25:33 AM Thiago Macieira wrote: On Monday 18 May 2015 09:15:01 Simon Hausmann wrote: Since we're not going to implement that, I suggest renaming the function to readLineInto to solve the ambiguity. I think that's a good idea. Has anyone done this? Don't expect me to do it. I've made a change that renames the function: https://codereview.qt-project.org/#/c/113538/ Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
On Monday 18 May 2015 09:15:01 Simon Hausmann wrote: Since we're not going to implement that, I suggest renaming the function to readLineInto to solve the ambiguity. I think that's a good idea. Has anyone done this? Don't expect me to do it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
On Sunday, May 17, 2015 12:21:35 PM Thiago Macieira wrote: On Sunday 17 May 2015 22:17:04 Marc Mutz wrote: On Sunday 17 May 2015 15:19:49 Giuseppe D'Angelo wrote: It would solve, but Qt APIs use pointers instead of references for out-arguments (and that's a very good code policy). *Any* form of out parameter is bad code policy. Much better in virtually all cases to return multiple values in a small struct. In the case at hand, the idea is probably to reuse the capacity of the passed QString, so returning a struct while still allowing reuse of the capacity requires C++11 (taking a QString to avoid a refcount 1, which incidentally shows how poor pointer parameter semantics really are). I believe it was Sean Parent who in one of his talks showed how capacity- preserving file reading should be implemented (iirc, by keeping the string as a member of an object and handing it out as a reference). Since we're not going to implement that, I suggest renaming the function to readLineInto to solve the ambiguity. I think that's a good idea. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
2015-05-18 11:40 GMT+02:00 André Somers an...@familiesomers.nl: Andreas Aardal Hanssen schreef op 18-5-2015 om 11:35: Qt convention is to promote pointers for out parameters to make it immediately clear that your input can be modified. Out references, or non-const reference parameters, have traditionally been discouraged because they make the code harder to read. It's not about what's proper C/C++. Pointers can be just as opague. In terms of the above example: I cannot see from any of the parameters to those functions what their types are. If they are already pointers, they may already get modified. On the other hand: that pointer may not get modified at all. I created https://bugreports.qt.io/browse/QTCREATORBUG-14468 for some tooling support to get a better feedback on what's going on. At the end of the day, tmp is always a pointer, whereas tmp may not be. It's simply easier to read. Having reference out parameters is a API design mistake in Qt. Agree or not but deviating from this makes for an inconsistent API. Andreas -- Andreas Aardal Hanssen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
When I'm reading code and I encounter a function call with parameters, if I am not familiar with that function, I look at its documentation. First I look at the signature. If it contains a non-const reference, I know the parameter can be modified. I read the function documentation to see if it is meant to be modified. What is required inside the function if a pointer is used instead? Is the function required to test the pointer for nil and return in an error state or report an error? That doesn't happen with a reference. martin From: development-bounces+martin.smith=theqtcompany@qt-project.org development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Andreas Aardal Hanssen andr...@hanssen.name Sent: Monday, May 18, 2015 11:44 AM To: development Subject: Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5 2015-05-18 11:40 GMT+02:00 André Somers an...@familiesomers.nlmailto:an...@familiesomers.nl: Andreas Aardal Hanssen schreef op 18-5-2015 om 11:35: Qt convention is to promote pointers for out parameters to make it immediately clear that your input can be modified. Out references, or non-const reference parameters, have traditionally been discouraged because they make the code harder to read. It's not about what's proper C/C++. Pointers can be just as opague. In terms of the above example: I cannot see from any of the parameters to those functions what their types are. If they are already pointers, they may already get modified. On the other hand: that pointer may not get modified at all. I created https://bugreports.qt.io/browse/QTCREATORBUG-14468 for some tooling support to get a better feedback on what's going on. At the end of the day, tmp is always a pointer, whereas tmp may not be. It's simply easier to read. Having reference out parameters is a API design mistake in Qt. Agree or not but deviating from this makes for an inconsistent API. Andreas -- Andreas Aardal Hanssen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
Giuseppe D'Angelo schreef op 17-5-2015 om 21:57: On Sun, May 17, 2015 at 9:55 PM, Smith Martin martin.sm...@theqtcompany.com wrote: How do you get bitten by an out-reference? As usual, because at call site I didn't realize the argument was actually being modified. Compare doSomething(param1, param2, param3); doSomething(param1, param2, param3); which one is likely to be modifying arguments? Right. So the policy is enforcing the use of a pointer argument to sort-of* force the use of the address-of operator so the potentially-modified argument is easier to spot in the code? If so, perhaps it would be better to improve the editors and let them highlight parameters to functions that may get changed by the function call. André *) you could already have a pointer, not needing the operator. And pointers are also passed for other reasons. Reverse, the pointer argument may also be const, thus promissing not to change the contents. You cannot rely on that clue. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
On 05/17/2015 09:57 PM, Giuseppe D'Angelo wrote: On Sun, May 17, 2015 at 9:55 PM, Smith Martin martin.sm...@theqtcompany.com wrote: How do you get bitten by an out-reference? As usual, because at call site I didn't realize the argument was actually being modified. Compare doSomething(param1, param2, param3); doSomething(param1, param2, param3); which one is likely to be modifying arguments? Both are equally likely to, unless you are a C programmer. Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
2015-05-18 11:10 GMT+02:00 Christian Kandeler christian.kande...@theqtcompany.com: On 05/17/2015 09:57 PM, Giuseppe D'Angelo wrote: On Sun, May 17, 2015 at 9:55 PM, Smith Martin martin.sm...@theqtcompany.com wrote: How do you get bitten by an out-reference? As usual, because at call site I didn't realize the argument was actually being modified. Compare doSomething(param1, param2, param3); doSomething(param1, param2, param3); which one is likely to be modifying arguments? Both are equally likely to, unless you are a C programmer. Qt convention is to promote pointers for out parameters to make it immediately clear that your input can be modified. Out references, or non-const reference parameters, have traditionally been discouraged because they make the code harder to read. It's not about what's proper C/C++. Andreas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
Andreas Aardal Hanssen schreef op 18-5-2015 om 11:35: 2015-05-18 11:10 GMT+02:00 Christian Kandeler christian.kande...@theqtcompany.com mailto:christian.kande...@theqtcompany.com: On 05/17/2015 09:57 PM, Giuseppe D'Angelo wrote: On Sun, May 17, 2015 at 9:55 PM, Smith Martin martin.sm...@theqtcompany.com mailto:martin.sm...@theqtcompany.com wrote: How do you get bitten by an out-reference? As usual, because at call site I didn't realize the argument was actually being modified. Compare doSomething(param1, param2, param3); doSomething(param1, param2, param3); which one is likely to be modifying arguments? Both are equally likely to, unless you are a C programmer. Qt convention is to promote pointers for out parameters to make it immediately clear that your input can be modified. Out references, or non-const reference parameters, have traditionally been discouraged because they make the code harder to read. It's not about what's proper C/C++. Pointers can be just as opague. In terms of the above example: I cannot see from any of the parameters to those functions what their types are. If they are already pointers, they may already get modified. On the other hand: that pointer may not get modified at all. I created https://bugreports.qt.io/browse/QTCREATORBUG-14468 for some tooling support to get a better feedback on what's going on. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
On Monday 18 May 2015 12:17:32 Koehne Kai wrote: Can you elaborate? We're talking about in/out parameters here, where raw pointers IMO are still perfectly valid. What do you expect the signature of readLine(QString *line) to be in C++14? QString readLine(QString reuseThisStringsCapacity); -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
-Original Message- From: development-bounces+louai.al-khanji=theqtcompany.com@qt- project.org [mailto:development-bounces+louai.al- khanji=theqtcompany@qt-project.org] On Behalf Of Marc Mutz Sent: Monday, May 18, 2015 2:47 PM To: development@qt-project.org Subject: Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5 On Monday 18 May 2015 12:17:32 Koehne Kai wrote: Can you elaborate? We're talking about in/out parameters here, where raw pointers IMO are still perfectly valid. What do you expect the signature of readLine(QString *line) to be in C++14? QString readLine(QString reuseThisStringsCapacity); -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Ooh, a bike shed thread! I vote that we implement N4282 and make the function signature bool readLine(std::observer_ptrQString, qint64); This is obviously better since we now can report failures *AND* make object lifetimes explicit! /snark :) Louai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
On Mon, May 18, 2015 at 12:54 PM, Al-Khanji Louai louai.al-kha...@theqtcompany.com wrote: Ooh, a bike shed thread! Indeed, trying to put the thread back on track: +1 for removing the overload (readLineInto or so). -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
On 17/05/2015 15:19, Giuseppe D'Angelo wrote: On Sun, May 17, 2015 at 2:30 PM, Andre Somers an...@familiesomers.nl wrote: In the spirit of option b), would it be an option to have the method take a QString instead of a QString*? That would resolve the ambiguity. It would solve, but Qt APIs use pointers instead of references for out-arguments (and that's a very good code policy). That *was* a good policy (it has its drawbacks). C++11 tends to remove the need of raw pointers, C++14 makes a step further in that direction. Sticking to such a rule would mean going against the general evolution of the language. That said, i wish there were a « ref X » or « out X » keyword needed when calling a function that takes a reference, like in C# or Ada. In C++, you should resort to const-correctness to prevent mistakes. I like the suggested idea of highlightings potentially modified parameters in qtcreator. Regards, Julien ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
2015-05-18 12:07 GMT+02:00 Julien Blanc julien.bl...@nmc-company.com: C++, you should resort to const-correctness to prevent mistakes. I like There is no const correctness in C++. #dontfeedthetroll #trymakingaconstcorrectlinkedlistinc++ -- Andreas Aardal Hanssen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
-Original Message- From: development-bounces+kai.koehne=theqtcompany.com@qt- project.org [mailto:development- bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of Julien Blanc Sent: Monday, May 18, 2015 12:08 PM To: development@qt-project.org Subject: Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5 On 17/05/2015 15:19, Giuseppe D'Angelo wrote: On Sun, May 17, 2015 at 2:30 PM, Andre Somers an...@familiesomers.nl wrote: In the spirit of option b), would it be an option to have the method take a QString instead of a QString*? That would resolve the ambiguity. It would solve, but Qt APIs use pointers instead of references for out-arguments (and that's a very good code policy). That *was* a good policy (it has its drawbacks). C++11 tends to remove the need of raw pointers, C++14 makes a step further in that direction. Sticking to such a rule would mean going against the general evolution of the language. Can you elaborate? We're talking about in/out parameters here, where raw pointers IMO are still perfectly valid. What do you expect the signature of readLine(QString *line) to be in C++14? Herb Sutter had a nice blog post about this a while ago: http://herbsutter.com/2013/06/05/gotw-91-solution-smart-pointer-parameters/ He suggests to use a * if you need to express null [...], otherwise prefer to use a though, where our coding standard suggests to use * for out parameters. Anyhow, this is an old argument that has nothing to do with C++11 , or smart pointers ... Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
2015-05-18 13:46 GMT+02:00 Marc Mutz marc.m...@kdab.com: On Monday 18 May 2015 12:17:32 Koehne Kai wrote: Can you elaborate? We're talking about in/out parameters here, where raw pointers IMO are still perfectly valid. What do you expect the signature of readLine(QString *line) to be in C++14? QString readLine(QString reuseThisStringsCapacity); The overload is unintuitive and the operation so complex that I would propose doing something different altogether. It's no longer a one-liner. It's not a good case for out parameters at all... -- Andreas Aardal Hanssen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
On Sunday 17 May 2015 22:17:04 Marc Mutz wrote: On Sunday 17 May 2015 15:19:49 Giuseppe D'Angelo wrote: It would solve, but Qt APIs use pointers instead of references for out-arguments (and that's a very good code policy). *Any* form of out parameter is bad code policy. Much better in virtually all cases to return multiple values in a small struct. In the case at hand, the idea is probably to reuse the capacity of the passed QString, so returning a struct while still allowing reuse of the capacity requires C++11 (taking a QString to avoid a refcount 1, which incidentally shows how poor pointer parameter semantics really are). I believe it was Sean Parent who in one of his talks showed how capacity- preserving file reading should be implemented (iirc, by keeping the string as a member of an object and handing it out as a reference). Since we're not going to implement that, I suggest renaming the function to readLineInto to solve the ambiguity. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
On Sun, May 17, 2015 at 9:55 PM, Smith Martin martin.sm...@theqtcompany.com wrote: How do you get bitten by an out-reference? As usual, because at call site I didn't realize the argument was actually being modified. Compare doSomething(param1, param2, param3); doSomething(param1, param2, param3); which one is likely to be modifying arguments? -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
How do you get bitten by an out-reference? From: development-bounces+martin.smith=theqtcompany@qt-project.org development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Giuseppe D'Angelo dange...@gmail.com Sent: Sunday, May 17, 2015 9:43 PM To: Marc Mutz Cc: development@qt-project.org Subject: Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5 On Sun, May 17, 2015 at 10:17 PM, Marc Mutz marc.m...@kdab.com wrote: *Any* form of out parameter is bad code policy. Much better in virtually all cases to return multiple values in a small struct. No, I was simply referring to the specific case of using pointers instead of references. I've been bitten too many times by out-references. Then whether we should ban out-arguments is another story entirely... -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
On Sun, May 17, 2015 at 10:17 PM, Marc Mutz marc.m...@kdab.com wrote: *Any* form of out parameter is bad code policy. Much better in virtually all cases to return multiple values in a small struct. No, I was simply referring to the specific case of using pointers instead of references. I've been bitten too many times by out-references. Then whether we should ban out-arguments is another story entirely... -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
I think output parameters are supposed to be placed at the end; their names should indicate that they are outputs, and the documentation should say they are changed by the function. martin From: Giuseppe D'Angelo dange...@gmail.com Sent: Sunday, May 17, 2015 9:57 PM To: Smith Martin Cc: Marc Mutz; development@qt-project.org Subject: Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5 On Sun, May 17, 2015 at 9:55 PM, Smith Martin martin.sm...@theqtcompany.com wrote: How do you get bitten by an out-reference? As usual, because at call site I didn't realize the argument was actually being modified. Compare doSomething(param1, param2, param3); doSomething(param1, param2, param3); which one is likely to be modifying arguments? -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
On 13-5-2015 2:44, Thiago Macieira wrote: On Wednesday 13 May 2015 02:34:28 Jan Kundrát wrote: Hi, this commit [1] added a new overload to QTextStream::readLine. As a result of that, calling stream.readLine(0) is now ambiguous: QString readLine(qint64 maxlen = 0); bool readLine(QString *line, qint64 maxlen = 0); While I can easily fix this in the caller (Konsole in this case), I'm wodnering whether this effect was understood at the time the change was merged. IMHO it's a bit more user-friendly to preserve source compatibility by removing the default value in the newly added overload. Should I send such a patch? Why write readLine(0) when it's the same as readLine() ? readLine(0) seems to me that it's asking for a line of at most zero bytes -- we should have had this argument default to -1 to indicate maximum length, not 0. Removing the default argument for the new overload will make it worse, by making people have to write the zero when they mean unlimited. I don't like that. The two options I will consider are: a) do nothing, accept and document the source incompatibility b) modify differently so that the new API isn't ambiguous but doesn't require people to write 0 either. In the spirit of option b), would it be an option to have the method take a QString instead of a QString*? That would resolve the ambiguity. It also makes it clear that it makes little sense to call the method without an actual QString to store the results in. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
On Wed, May 13, 2015 at 09:44:40AM +0900, Thiago Macieira wrote: On Wednesday 13 May 2015 02:34:28 Jan Kundrát wrote: Hi, this commit [1] added a new overload to QTextStream::readLine. As a result of that, calling stream.readLine(0) is now ambiguous: QString readLine(qint64 maxlen = 0); bool readLine(QString *line, qint64 maxlen = 0); While I can easily fix this in the caller (Konsole in this case), I'm wodnering whether this effect was understood at the time the change was merged. IMHO it's a bit more user-friendly to preserve source compatibility by removing the default value in the newly added overload. Should I send such a patch? Why write readLine(0) when it's the same as readLine() ? readLine(0) seems to me that it's asking for a line of at most zero bytes -- we should have had this argument default to -1 to indicate maximum length, not 0. Removing the default argument for the new overload will make it worse, by making people have to write the zero when they mean unlimited. I don't like that. The two options I will consider are: a) do nothing, accept and document the source incompatibility b) modify differently so that the new API isn't ambiguous but doesn't require people to write 0 either. Does it have to be an *overload*? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
On Wednesday 13 May 2015 20:43:58 André Pönitz wrote: a) do nothing, accept and document the source incompatibility b) modify differently so that the new API isn't ambiguous but doesn't require people to write 0 either. Does it have to be an *overload*? No, it doesn't. That would be one possible solution (b). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
Hi, this commit [1] added a new overload to QTextStream::readLine. As a result of that, calling stream.readLine(0) is now ambiguous: QString readLine(qint64 maxlen = 0); bool readLine(QString *line, qint64 maxlen = 0); While I can easily fix this in the caller (Konsole in this case), I'm wodnering whether this effect was understood at the time the change was merged. IMHO it's a bit more user-friendly to preserve source compatibility by removing the default value in the newly added overload. Should I send such a patch? Cheers, Jan [1] https://codereview.qt-project.org/98606 -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTextStream::readLine(0) is an ambiguous overload in 5.5
On Wednesday 13 May 2015 02:34:28 Jan Kundrát wrote: Hi, this commit [1] added a new overload to QTextStream::readLine. As a result of that, calling stream.readLine(0) is now ambiguous: QString readLine(qint64 maxlen = 0); bool readLine(QString *line, qint64 maxlen = 0); While I can easily fix this in the caller (Konsole in this case), I'm wodnering whether this effect was understood at the time the change was merged. IMHO it's a bit more user-friendly to preserve source compatibility by removing the default value in the newly added overload. Should I send such a patch? Why write readLine(0) when it's the same as readLine() ? readLine(0) seems to me that it's asking for a line of at most zero bytes -- we should have had this argument default to -1 to indicate maximum length, not 0. Removing the default argument for the new overload will make it worse, by making people have to write the zero when they mean unlimited. I don't like that. The two options I will consider are: a) do nothing, accept and document the source incompatibility b) modify differently so that the new API isn't ambiguous but doesn't require people to write 0 either. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
