[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  SMAUG
. -> [Folder]  SMAUG coding
. . -> [Subject]  Converting from GCC to G++
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Converting from GCC to G++
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2  

Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Sat 20 Mar 2010 02:03 AM (UTC)  [ quote  ]
Message
Nick Gammon said:
I am making the point that for some functions you may not *need* to get data back out of them, if they operate only by causing side-effects.


That, by definition, is getting data back out of them, at least in my book. It's what I meant earlier about C#'s "out" parameter modifier.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Nick Gammon   Australia  (18,797 posts)  [Biography] bio   Forum Administrator
Date Sat 20 Mar 2010 02:01 AM (UTC)  [ quote  ]
Message
Twisol said:

I meant that there's nothing that the function does that the calling code sees straight away. Of course it has side effects, that's the point of the function. ;) But the side-effected data is sent to the user over a socket, not back out of the interpret function, correct?


Yes, in this case.

However some functions (like math.floor for example) only work on the provided data, and return a result. Thus (in C at least) if they need to modify lots of things, you need to provide them with non-const arguments which are not simply call-by-value.

I am making the point that for some functions you may not *need* to get data back out of them, if they operate only by causing side-effects.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Sat 20 Mar 2010 01:50 AM (UTC)  [ quote  ]

Amended on Sat 20 Mar 2010 01:51 AM (UTC) by Twisol

Message
Nick Gammon said:

Twisol said:

Since the function returns void, the parameter is the only way to get any data back out of the function.


No, the function has side-effects. So for example interpret ("who") shows a who list. The function interpret does not return data, per se.


I meant that there's nothing that the function does that the calling code sees straight away. Of course it has side effects, that's the point of the function. ;) But the side-effected data is sent to the user over a socket, not back out of the interpret function, correct?
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Nick Gammon   Australia  (18,797 posts)  [Biography] bio   Forum Administrator
Date Sat 20 Mar 2010 01:49 AM (UTC)  [ quote  ]
Message
Twisol said:

Since the function returns void, the parameter is the only way to get any data back out of the function.


No, the function has side-effects. So for example interpret ("who") shows a who list. The function interpret does not return data, per se.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Fri 19 Mar 2010 07:57 PM (UTC)  [ quote  ]
Message
David Haley said:
I guess I'm not sure what you're trying to argue. :-)

Me either, anymore. =/ I guess I just enjoy a good discussion.

I was originally trying to show how you probably don't need an overloaded function at all. and assuming that either the modifications were interesting or they weren't. Since the function returns void, the parameter is the only way to get any data back out of the function. So if it's interesting, use char*; if it's not interesting, use const char* and strdup(). In the first case, yes, I'm assuming the general case is that you want the interesting modifications. If you don't, well, I guess that's what the original post's overload was for. But that's far too implicit for my tastes, and I don't think overloading is a good fit for that.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Fri 19 Mar 2010 07:47 PM (UTC)  [ quote  ]
Message
What guarantee exactly am I breaking?

You can modify your input, without it being safe to have a version that reads and writes the same memory location.

You might be saying that you want the two-argument version to do the exact same thing as the one-argument version internally, just write to the second param. It would therefore still be duplicating the input parameter internally, because it's doing the exact same thing. If this is what you are saying, then ok, but this is kind of silly (it defeats the whole point of having a const parameter!) and regardless is not an assumption that can be made generally.

You can't assume, when looking at things in general, that just because it's safe to call the one-parameter version, it's also safe to call the two-parameter version with the same buffer unless special precautions have been taken (and the API documentation would presumably make this clear).

Obviously we can contrive any number of cases in which this would be safe, but I'm trying to make statements about general programming practices, not an extremely specific case. What got us into this tangent were comments made about constness and overloading in general, not on some specific case we make up. See in particular my first comment in this thread.

And even if you want to get into specifics, namely the SMAUG 'interpret' function, my previous comments argue that you want to make life as convenient as possible for the caller, and that your suggestions reduce convenience for the caller because they force the creation of a writable buffer, which is annoying when all you have is a const buffer: you need to do the duplication yourself. By contrast, if you have an overloaded version that hides that from you, you don't need to worry about it.

I guess I'm not sure what you're trying to argue. :-)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Fri 19 Mar 2010 07:37 PM (UTC)  [ quote  ]

Amended on Fri 19 Mar 2010 07:42 PM (UTC) by Twisol

Message
David Haley said:
Also assume that foo(const X* in, X* out) assumes (rather reasonably) that the input and output buffers are different, and therefore does not need to copy its input.

There, right there, you are changing the logic of the original function, and breaking the guarantee I postulated.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Fri 19 Mar 2010 07:33 PM (UTC)  [ quote  ]
Message
Twisol said:
I was assuming that foo()/1 does modify its input string, otherwise I'd make it a const char*. If foo()/1 is safe, and it modifies its input string, then foo()/2 should be safe, assuming you replace the relevant variable references with 'out' instead. But you shouldn't have to change the logic, at all.

No, I disagree with this.

Assume that foo(X*) is modifying its input string by first copying it, and then using the copy as input, and writing output back to the parameter. Also assume that foo(const X* in, X* out) assumes (rather reasonably) that the input and output buffers are different, and therefore does not need to copy its input. Therefore, it will be writing into the output even though it is squashing its input.

In other words, in the first case it might use the parameter memory as both input and output, and does this safely because it copies the input stream before operating on the parameter's memory.

So: it's not safe to assume that just because things work with the single-parameter version, they'll necessarily work the same way with the two-parameter version.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Fri 19 Mar 2010 07:26 PM (UTC)  [ quote  ]
Message
David Haley said:
I don't understand the notation you're using, sorry. :)

Arity: I blatantly stole it from Erlang. foo()/2 means the version of foo() with 2 arguments. (Strictly speaking, I have the () in the wrong place, but I'm just using it descriptively)

David Haley said:
I think what you're saying is that if the single-parameter version was safe, then it must not be overwriting its input anyhow. Well, that's not necessarily the case, either: it might be duplicating the input stream internally as a convenience to the caller, so that they pass in some input, and it comes back modified, without needing to worry about creating a buffer themselves.

I was assuming that foo()/1 does modify its input string, otherwise I'd make it a const char*. If foo()/1 is safe, and it modifies its input string, then foo()/2 should be safe, assuming you replace the relevant variable references with 'out' instead. But you shouldn't have to change the logic, at all.

David Haley said:
Basically, my point here again is pretty simple: if a function has in and out parameters, you should be wary of using the same memory for both, unless the documentation explicitly allows it.

In general I agree. I still believe that a "widening" conversion gives you an implicit guarantee, at least until you actually change the logic in foo()/2.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Fri 19 Mar 2010 07:16 PM (UTC)  [ quote  ]
Message
I don't understand the notation you're using, sorry. :)

I think what you're saying is that if the single-parameter version was safe, then it must not be overwriting its input anyhow. Well, that's not necessarily the case, either: it might be duplicating the input stream internally as a convenience to the caller, so that they pass in some input, and it comes back modified, without needing to worry about creating a buffer themselves.

Basically, my point here again is pretty simple: if a function has in and out parameters, you should be wary of using the same memory for both, unless the documentation explicitly allows it.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Fri 19 Mar 2010 07:08 PM (UTC)  [ quote  ]
Message
Put it this way... A "widening" type conversion, like conversion from a char to a long, is valid and safe. The reverse is not true, as you may be losing data in the higher bits. This is the same thing going on here; I'm widening from the original foo(char*) to foo(const char*, char*), whereas you're looking at it in the reverse direction. Assuming that both versions of the function still do the same thing, it should be legal to call foo()/2 with the same argument twice, which effectively degenerates to the original foo()/1.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Fri 19 Mar 2010 06:51 PM (UTC)  [ quote  ]
Message
I guess I don't see how it's the same thing, because you're likely to have to duplicate it so that the program won't be overwriting the buffer it's reading from.

If your function is foo(const char* in, char* out), you most likely wouldn't want to pass the same char* to both, unless the function explicitly says that it is safe to do so. (This might be the case for a function that converts a string's case, for instance, so it only writes over input positions that it has already read.)

A color converter, for example, shows quite clearly how disastrous it can be to pass in a single string, because you'll be expanding color codes into the input you haven't seen yet.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Fri 19 Mar 2010 06:10 PM (UTC)  [ quote  ]
Message
David Haley said:

Twisol said:
It's also completely possible to call it with the same variable as both the second and third argument, i.e. interpret(ch, command, command)

Most of the time, that is in fact very dangerous. It's like working on input as you're pulling it out from under yourself. Most functions with in/out parameters require that they point to different things, or else much confusion results.

Fair point. My point was just that it would be basically exactly the same thing as an interpret() with only a char*.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Fri 19 Mar 2010 06:04 PM (UTC)  [ quote  ]
Message
Twisol said:
It's also completely possible to call it with the same variable as both the second and third argument, i.e. interpret(ch, command, command)

Most of the time, that is in fact very dangerous. It's like working on input as you're pulling it out from under yourself. Most functions with in/out parameters require that they point to different things, or else much confusion results.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Fri 19 Mar 2010 05:55 PM (UTC)  [ quote  ]
Message
David Haley said:
The 'out' parameter is another way to deal with this, but it (as usual) depends on what exactly is happening here. Sometimes it's more convenient to have the input operated on directly for whatever reason. For instance, it might be a more complicated data structure than just a char*. Also, it means more stuff to keep track of on the caller's end when they want to get the modifications; now they have to make the call and prepare the target buffer for the modifications. Like I said, it really depends on what the common case is.

It's also completely possible to call it with the same variable as both the second and third argument, i.e. interpret(ch, command, command)

David Haley said:
All I was trying to say here is that there are reasonable cases besides "always care" and "never care", and so it can make sense to have this form of overloading. (Sometimes, the implementations might even be different, and the overloaded version wouldn't wrap it with a duplication but do some other computation that doesn't involve the side effect.) So the answer isn't a clear-cut "make it either const or non const but not both". Even in the case of the nullable out parameter, we see that this is happening (although out parameters, especially for some types in C/C++, have a whole new slew of issues of their own...).

Of course. Again, I'm just trying to keep the original issue in mind here.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

5,029 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]