Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #14772 > unrolled thread

use of pointers

Back to article view | Back to comp.lang.c++

Contents

  use of pointers ahso <ahso47@yahoo.com> - 2012-03-06 02:54 -0800
    Re: use of pointers Marcel Müller <news.5.maazl@spamgourmet.com> - 2012-03-06 12:22 +0100
      Re: use of pointers nick_keighley_nospam@hotmail.com - 2012-03-07 00:32 -0800
        Re: use of pointers Juha Nieminen <nospam@thanks.invalid> - 2012-03-07 13:47 +0000
          Re: use of pointers nick_keighley_nospam@hotmail.com - 2012-03-07 07:06 -0800
            Re: use of pointers Juha Nieminen <nospam@thanks.invalid> - 2012-03-07 16:04 +0000
    Re: use of pointers Juha Nieminen <nospam@thanks.invalid> - 2012-03-06 12:29 +0000
      Re: use of pointers Victor Bazarov <v.bazarov@comcast.invalid> - 2012-03-06 08:04 -0500
        Re: use of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-03-06 14:05 +0000
          Re: use of pointers Victor Bazarov <v.bazarov@comcast.invalid> - 2012-03-06 11:25 -0500
            Re: use of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-03-06 20:56 +0000
        Re: use of pointers SG <s.gesemann@gmail.com> - 2012-03-06 06:27 -0800
          Re: use of pointers BGB <cr88192@hotmail.com> - 2012-03-06 13:05 -0700
          Re: use of pointers woodbrian77@gmail.com - 2012-03-07 05:38 -0800
        Re: use of pointers Rui Maciel <rui.maciel@gmail.com> - 2012-03-07 15:48 +0000
          Re: use of pointers BGB <cr88192@hotmail.com> - 2012-03-07 18:38 -0700
            Re: use of pointers Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-03-10 21:10 -0500
              Re: use of pointers Jeff Flinn <TriumphSprint2000@hotmail.com> - 2012-03-12 08:26 -0400
                Re: use of pointers Jeff Flinn <TriumphSprint2000@hotmail.com> - 2012-03-12 12:28 -0400
        Re: use of pointers Nobody <nobody@nowhere.com> - 2012-03-09 21:28 +0000
    Re: use of pointers Geoff <geoff@invalid.invalid> - 2012-03-06 21:31 -0800
      Re: use of pointers Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-07 11:26 +0000
        Re: use of pointers yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2012-03-07 13:56 +0000
          Re: use of pointers Maarten <maarten.sneep@knmi.nl> - 2012-03-07 06:14 -0800
            Re: use of pointers Rui Maciel <rui.maciel@gmail.com> - 2012-03-07 16:05 +0000
              Re: use of pointers yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2012-03-08 10:08 +0000
                Re: use of pointers Rui Maciel <rui.maciel@gmail.com> - 2012-03-08 21:17 +0000
              Re: use of pointers Maarten <maarten.sneep@knmi.nl> - 2012-03-08 04:55 -0800
            Re: use of pointers Nobody <nobody@nowhere.com> - 2012-03-09 21:45 +0000
          Re: use of pointers Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-07 20:08 +0000
        Re: use of pointers Nobody <nobody@nowhere.com> - 2012-03-09 21:50 +0000
          Re: use of pointers Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-09 22:37 +0000
    Re: use of pointers Rui Maciel <rui.maciel@gmail.com> - 2012-03-07 15:37 +0000

Page 1 of 2  [1] 2  Next page →

#14772 — use of pointers

Hi
I want to rewrite a function as below to not use pointers:

void NewPos(float angle, float speed, float *x, float *y){

	angle = (angle-90.0)*0.0174532925199433;

	*x = (cos(angle) * speed);
	*y = (sin(angle) * speed);

}

I also don't know what this is doing exactly. Any explanations and
also why this needs pointers?
Many thanks

[toc] | [next] | [standalone]

#14773

On 06.03.2012 11:54, ahso wrote:
> Hi
> I want to rewrite a function as below to not use pointers:
>
> void NewPos(float angle, float speed, float *x, float *y){
>
> 	angle = (angle-90.0)*0.0174532925199433;
>
> 	*x = (cos(angle) * speed);
> 	*y = (sin(angle) * speed);
>
> }
>
> I also don't know what this is doing exactly. Any explanations and
> also why this needs pointers?

Well, it looks like old C code. The pointers are used as reference 
parameters in this case. The function in fact returns two values.

The C++ way to do so is
   void NewPos(float angle, float speed, float& x, float& y)
Now you pass x and y explicitely as references. Of course, you need to 
remove the * before x and y in the function and most probably & where 
the function is called.

A even better code might return a structure consisting of x and y.

By the way: the magic number 0.017... is bad programming style, since no 
one knows what it is good for. You should write 2*M_PI/360. which is 
more clearly a conversion between degrees and radians.


Marcel

[toc] | [prev] | [next] | [standalone]

#14794

On Tuesday, March 6, 2012 11:22:09 AM UTC, Marcel Müller wrote:
> On 06.03.2012 11:54, ahso wrote:

<snip>

> By the way: the magic number 0.017... is bad programming style, since no 
> one knows what it is good for. You should write 2*M_PI/360. which is 
> more clearly a conversion between degrees and radians.

or even better

inline double degreesToRadians (double d)
{
   return d * M_PI / 180.0;
}

[toc] | [prev] | [next] | [standalone]

#14803

nick_keighley_nospam@hotmail.com wrote:
> or even better
> 
> inline double degreesToRadians (double d)
> {
>   return d * M_PI / 180.0;
> }

  The compiler will most probably not replace "M_PI / 180.0" with its
result at compile time in the above expression, unless you specifically
set optimizations that allow it (eg. -ffast-math). If you want to avoid
the runtime division, do it like this:

    return d * (M_PI / 180.0);

  Now the compiler is allowed to do the division at compile time.
(OTOH, you should not assume that all compilers will do that when
dealing with floating point...)

[toc] | [prev] | [next] | [standalone]

#14807

On Wednesday, March 7, 2012 1:47:37 PM UTC, Juha Nieminen wrote:
> nick_keighley wrote:
> > or even better
> > 
> > inline double degreesToRadians (double d)
> > {
> >   return d * M_PI / 180.0;
> > }
> 
>   The compiler will most probably not replace "M_PI / 180.0" with its
> result at compile time in the above expression, unless you specifically
> set optimizations that allow it (eg. -ffast-math). If you want to avoid
> the runtime division, do it like this:
> 
>     return d * (M_PI / 180.0);
> 
>   Now the compiler is allowed to do the division at compile time.
> (OTOH, you should not assume that all compilers will do that when
> dealing with floating point...)

inline double degreesToRadians (double d)
{
   const double radsPerDeg = M_PI / 180.0;
   return d * radsPerDeg;
}

[toc] | [prev] | [next] | [standalone]

#14810

nick_keighley_nospam@hotmail.com wrote:
> inline double degreesToRadians (double d)
> {
>   const double radsPerDeg = M_PI / 180.0;
>   return d * radsPerDeg;
> }

  That still doesn't guarantee that the compiler will calculate the
division at compile time any more than with my version. Remember
that a 'double' isn't a compile-time constant in C++98.

  It's probably different in C++11, where you can use:

    constexpr double radPerDeg = M_PI / 180.0;

  Here the compiler has no choice (AFAIK) than to perform the calcuation
at compile time.

[toc] | [prev] | [next] | [standalone]

#14774

ahso <ahso47@yahoo.com> wrote:
> Hi
> I want to rewrite a function as below to not use pointers:
> 
> void NewPos(float angle, float speed, float *x, float *y){
> 
>        angle = (angle-90.0)*0.0174532925199433;
> 
>        *x = (cos(angle) * speed);
>        *y = (sin(angle) * speed);
> 
> }

  Since floats are small basic types, it's much, much cleaner (and
equally efficient) to do this:

struct Point { float x, y; };

Point NewPos(float angle, float speed)
{
    angle = (angle - 90.0f) * 0.0174532925199433f;
    Point p = { std::cos(angle) * speed, std::sin(angle) * speed };
    return p;
}

  (With C++11 you can skip creating the local variable 'p' and return
the initializer list directly.)

[toc] | [prev] | [next] | [standalone]

#14775

On 3/6/2012 7:29 AM, Juha Nieminen wrote:
> ahso<ahso47@yahoo.com>  wrote:
>> Hi
>> I want to rewrite a function as below to not use pointers:
>>
>> void NewPos(float angle, float speed, float *x, float *y){
>>
>>         angle = (angle-90.0)*0.0174532925199433;
>>
>>         *x = (cos(angle) * speed);
>>         *y = (sin(angle) * speed);
>>
>> }
>
>    Since floats are small basic types, it's much, much cleaner (and
> equally efficient) to do this:
>
> struct Point { float x, y; };
>
> Point NewPos(float angle, float speed)
> {
>      angle = (angle - 90.0f) * 0.0174532925199433f;
>      Point p = { std::cos(angle) * speed, std::sin(angle) * speed };
>      return p;
> }
>
>    (With C++11 you can skip creating the local variable 'p' and return
> the initializer list directly.)

The name 'Point' is misleading IMNSHO and so is the name of the 
function.  What is returned is a velocity vector, not a position.

And I am not so sure one couldn't just return std::pair<float,float> 
since it essentially does the same thing, except that its members are 
not called 'x' and 'y'...  Why invent another type when a standard one 
exists?

V
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#14777

Victor Bazarov <v.bazarov@comcast.invalid> wrote:

(snip, someone wrote)
>>    Since floats are small basic types, it's much, much cleaner (and
>> equally efficient) to do this:

>> struct Point { float x, y; };

(snip)
> The name 'Point' is misleading IMNSHO and so is the name of the 
> function.  What is returned is a velocity vector, not a position.

I suppose, but you could just consider it a point in velocity space.

> And I am not so sure one couldn't just return std::pair<float,float> 
> since it essentially does the same thing, except that its members are 
> not called 'x' and 'y'...  Why invent another type when a standard one 
> exists?

But velocity also has x and y components, so Point is fine.

-- glen

[toc] | [prev] | [next] | [standalone]

#14782

On 3/6/2012 9:05 AM, glen herrmannsfeldt wrote:
> Victor Bazarov<v.bazarov@comcast.invalid>  wrote:
>
> (snip, someone wrote)
>>>     Since floats are small basic types, it's much, much cleaner (and
>>> equally efficient) to do this:
>
>>> struct Point { float x, y; };
>
> (snip)
>> The name 'Point' is misleading IMNSHO and so is the name of the
>> function.  What is returned is a velocity vector, not a position.
>
> I suppose, but you could just consider it a point in velocity space.

I could.  But somebody who will likely assign a velocity "point" to a 
two-dimensional spatial (planar) point, shouldn't.  There is no "space" 
designation in the type, is there?

>> And I am not so sure one couldn't just return std::pair<float,float>
>> since it essentially does the same thing, except that its members are
>> not called 'x' and 'y'...  Why invent another type when a standard one
>> exists?
>
> But velocity also has x and y components, so Point is fine.

<sigh> It isn't.  But I don't see any use of arguing.  Not anymore. 
Sorry I brought it up.

V
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#14790

Victor Bazarov <v.bazarov@comcast.invalid> wrote:
 (snip, someone wrote)
>>> The name 'Point' is misleading IMNSHO and so is the name of the
>>> function.  What is returned is a velocity vector, not a position.

>> I suppose, but you could just consider it a point in velocity space.

> I could.  But somebody who will likely assign a velocity "point" to a 
> two-dimensional spatial (planar) point, shouldn't.  There is no "space" 
> designation in the type, is there?

I expect that you will find that some people think one way one
some the other. Note that it is unusual (there might be one) for
programming languages to keep track of dimensional units.

Physics has, in addition to velocity space, which might not seem
too strange, momentum space. There are some problems that can easily
be solved if you think of them in momentum space. (Even 
relativistically when it isn't mass times velocity anymore.)

>>> And I am not so sure one couldn't just return std::pair<float,float>
>>> since it essentially does the same thing, except that its members are
>>> not called 'x' and 'y'...  Why invent another type when a standard one
>>> exists?

>> But velocity also has x and y components, so Point is fine.

> <sigh> It isn't.  But I don't see any use of arguing.  Not anymore. 
> Sorry I brought it up.

I have thought for some time now, that it is more usual for
physicists to include units in their variables, and for engineers
to factor them out.

In a physics book you will see F=ma.

In an engineering book F(Newtons) = m(kg) * a (m/s**2)

In the latter case, the variable holds the unitless value that,
when the specified unit is applied, has the appropriate value
and dimensions.

Now, with a name like Point, one could ask why it is 2D and
not 3D, or even 4D. You could name the class Vector2D, though.

-- glen

[toc] | [prev] | [next] | [standalone]

#14778

On 6 Mrz., 14:04, Victor Bazarov wrote:
> The name 'Point' is misleading IMNSHO

I think it's okay. I don't see the benefit of creating two types (for
points and vectors) with basically the same interface. And since we
already have vector<> in std:: ...

> Why invent another type when a standard one exists?

Because even "point" says more than "pair<float,float>" to the human
source code reader.

Cheers!
SG

[toc] | [prev] | [next] | [standalone]

#14788

On 3/6/2012 7:27 AM, SG wrote:
> On 6 Mrz., 14:04, Victor Bazarov wrote:
>> The name 'Point' is misleading IMNSHO
>
> I think it's okay. I don't see the benefit of creating two types (for
> points and vectors) with basically the same interface. And since we
> already have vector<>  in std:: ...
>
>> Why invent another type when a standard one exists?
>
> Because even "point" says more than "pair<float,float>" to the human
> source code reader.
>

I personally used vec2/vec3/vec4/quat (each as a struct), following a 
convention more like in GLSL, except that most operations have a 
v2/v3/v4 prefix (say: "v3dot(v0, v1)", ...), and some many new ones were 
added (note that, a lot of these are technically macros which redirect 
the calls to other functions, and many others are "static inline" and 
defined solely in the header).

one could potentially use classes and be like: "v0.dot(v1)", but this 
would look kind of funky (and also wouldn't be C-friendly).

as-is, when used from C++, it does gain some overloaded operators and 
similar.


but, a lot of the older code still follows a convention of passing 
around float-array pointers, but this convention is (gradually) being 
phased out in many places (due mostly to being more awkward and 
error-prone).

or such...

[toc] | [prev] | [next] | [standalone]

#14802

On Tuesday, March 6, 2012 8:27:18 AM UTC-6, SG wrote:
> On 6 Mrz., 14:04, Victor Bazarov wrote:
> > The name 'Point' is misleading IMNSHO
> 
> I think it's okay. I don't see the benefit of creating two types (for
> points and vectors) with basically the same interface. And since we
> already have vector<> in std:: ...
> 
> > Why invent another type when a standard one exists?
> 
> Because even "point" says more than "pair<float,float>" to the human
> source code reader.
> 

I'd prefer the point also over a pair.  I'm not keen 
on the first and second names.  One disappoint with
the latest standard is there's still not a good
alternative to std::map.  

Brian
Ebenezer Enterprises
http://webEbenezer.net

[toc] | [prev] | [next] | [standalone]

#14809

Victor Bazarov wrote:

> The name 'Point' is misleading IMNSHO and so is the name of the
> function.  What is returned is a velocity vector, not a position.
> 
> And I am not so sure one couldn't just return std::pair<float,float>
> since it essentially does the same thing, except that its members are
> not called 'x' and 'y'...  Why invent another type when a standard one
> exists?

User-defined data types improve code readability.  Under some circumstances, 
it also help reduce the propensity to inadvertently add bugs to the code.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#14824

On 3/7/2012 8:48 AM, Rui Maciel wrote:
> Victor Bazarov wrote:
>
>> The name 'Point' is misleading IMNSHO and so is the name of the
>> function.  What is returned is a velocity vector, not a position.
>>
>> And I am not so sure one couldn't just return std::pair<float,float>
>> since it essentially does the same thing, except that its members are
>> not called 'x' and 'y'...  Why invent another type when a standard one
>> exists?
>
> User-defined data types improve code readability.  Under some circumstances,
> it also help reduce the propensity to inadvertently add bugs to the code.
>

yep, and in many cases where points/vectors are in use, they are a 
fairly fundamental building-block type, rather than an "afterthought" 
(or "misc") type, making them more suited to having their own dedicated 
type-names and their own dedicated logic.


granted, a lot depends on the particular domain as well.
for example, I am prone to think of a "money" or "date" types as fairly 
misc, since I don't use them much for what I do, but there are people 
who write types of software where such things make a good deal more 
sense (and languages like SQL treat both as fundamental types).

nevermind other strangeness (observed in accounting contexts): thinking 
as dates strictly in terms of days, or even ignoring the existence of 
things like leap years and similar in calculations (vs the more "sane" 
option of, say, thinking as time more strictly in terms of an absolute 
number of seconds, as a real value, between events).

but, it could be argued that maybe for the accountant, there is little 
reason for the accountant to care if "this time next year" may easily 
differ by hours or maybe days from "this time next year" as far as a 
scientist or engineer would be concerned (in terms of the number of 
seconds between "now" and "this date and time exactly one year from 
now"...).

or, for that matter, mentioning doing something "tomorrow" when it is 
after midnight, and said "tomorrow" is maybe only 10 or 14 hours away 
and technically the same day (as far as the calender is concerned...).



and, say, if one writes a 3D engine, they will be seeing points, 
vectors, matrices, ... quite a fair amount.

so, yeah, sometimes it makes a lot of sense to make dedicated types for 
these sorts of things.

[toc] | [prev] | [next] | [standalone]

#14876

BGB wrote:
> On 3/7/2012 8:48 AM, Rui Maciel wrote:
>> Victor Bazarov wrote:
>>
>>> The name 'Point' is misleading IMNSHO and so is the name of the
>>> function. What is returned is a velocity vector, not a position.
>>>
>>> And I am not so sure one couldn't just return std::pair<float,float>
>>> since it essentially does the same thing, except that its members are
>>> not called 'x' and 'y'... Why invent another type when a standard one
>>> exists?
>>
>> User-defined data types improve code readability. Under some circumstances,
>> it also help reduce the propensity to inadvertently add bugs to the code.
>>
>
> yep, and in many cases where points/vectors are in use, they are a fairly
> fundamental building-block type, rather than an "afterthought" (or "misc") type,
> making them more suited to having their own dedicated type-names and their own
> dedicated logic.
>
>
> granted, a lot depends on the particular domain as well.
> for example, I am prone to think of a "money" or "date" types as fairly misc,
> since I don't use them much for what I do, but there are people who write types
> of software where such things make a good deal more sense (and languages like
> SQL treat both as fundamental types).
>
> nevermind other strangeness (observed in accounting contexts): thinking as dates
> strictly in terms of days, or even ignoring the existence of things like leap
> years and similar in calculations (vs the more "sane" option of, say, thinking
> as time more strictly in terms of an absolute number of seconds, as a real
> value, between events).
>
> but, it could be argued that maybe for the accountant, there is little reason
> for the accountant to care if "this time next year" may easily differ by hours
> or maybe days from "this time next year" as far as a scientist or engineer would
> be concerned (in terms of the number of seconds between "now" and "this date and
> time exactly one year from now"...).
>
> or, for that matter, mentioning doing something "tomorrow" when it is after
> midnight, and said "tomorrow" is maybe only 10 or 14 hours away and technically
> the same day (as far as the calender is concerned...).
>
>
>
> and, say, if one writes a 3D engine, they will be seeing points, vectors,
> matrices, ... quite a fair amount.
>
> so, yeah, sometimes it makes a lot of sense to make dedicated types for these
> sorts of things.
>
I think those suggesting change in the interface other than replacing pointers 
with references spoke without trying to understand how the function is used.

For example, if the call site converts separate arrays of the two velocity 
components, changing from output parameters to return type would do more harm 
than good.

On a side note, even though I am not crazy about using pointers that shall not 
be NULLs, I tend to think twice before changing existing APIs from pointers to 
references: if significant amount of client code is "C-style" or just follows 
the convention of always using pointers for output parameters, its maintainers 
may assume that the arguments passed for x and y are values and misread the 
code's intention.

I am seriously thinking of wrapping my passed-by-referenced parameters in "Ref" 
objects with explicit constructors -- with the only goal to better document call 
sites  (e.g. NewPos(angle, speed, FloatRef(x), FloatRef(y));). Does anybody know 
anything existing of the kind?

As for the OP's question, I would seriously think of leaving the interface as it 
is -- at least until there is a domain-area-originated reason for changing it.

-Pavel

[toc] | [prev] | [next] | [standalone]

#14906

Pavel wrote:
> BGB wrote:
>> On 3/7/2012 8:48 AM, Rui Maciel wrote:
>>> Victor Bazarov wrote:
>>>
>>>> The name 'Point' is misleading IMNSHO and so is the name of the
>>>> function. What is returned is a velocity vector, not a position.
>>>>
>>>> And I am not so sure one couldn't just return std::pair<float,float>
>>>> since it essentially does the same thing, except that its members are
>>>> not called 'x' and 'y'... Why invent another type when a standard one
>>>> exists?
>>>
>>> User-defined data types improve code readability. Under some 
>>> circumstances,
>>> it also help reduce the propensity to inadvertently add bugs to the 
>>> code.
>>>
>>
>> yep, and in many cases where points/vectors are in use, they are a fairly
>> fundamental building-block type, rather than an "afterthought" (or 
>> "misc") type,
>> making them more suited to having their own dedicated type-names and 
>> their own
>> dedicated logic.
>>
>>
>> granted, a lot depends on the particular domain as well.
>> for example, I am prone to think of a "money" or "date" types as 
>> fairly misc,
>> since I don't use them much for what I do, but there are people who 
>> write types
>> of software where such things make a good deal more sense (and 
>> languages like
>> SQL treat both as fundamental types).
>>
>> nevermind other strangeness (observed in accounting contexts): 
>> thinking as dates
>> strictly in terms of days, or even ignoring the existence of things 
>> like leap
>> years and similar in calculations (vs the more "sane" option of, say, 
>> thinking
>> as time more strictly in terms of an absolute number of seconds, as a 
>> real
>> value, between events).
>>
>> but, it could be argued that maybe for the accountant, there is little 
>> reason
>> for the accountant to care if "this time next year" may easily differ 
>> by hours
>> or maybe days from "this time next year" as far as a scientist or 
>> engineer would
>> be concerned (in terms of the number of seconds between "now" and 
>> "this date and
>> time exactly one year from now"...).
>>
>> or, for that matter, mentioning doing something "tomorrow" when it is 
>> after
>> midnight, and said "tomorrow" is maybe only 10 or 14 hours away and 
>> technically
>> the same day (as far as the calender is concerned...).
>>
>>
>>
>> and, say, if one writes a 3D engine, they will be seeing points, vectors,
>> matrices, ... quite a fair amount.
>>
>> so, yeah, sometimes it makes a lot of sense to make dedicated types 
>> for these
>> sorts of things.
>>
> I think those suggesting change in the interface other than replacing 
> pointers with references spoke without trying to understand how the 
> function is used.
> 
> For example, if the call site converts separate arrays of the two 
> velocity components, changing from output parameters to return type 
> would do more harm than good.

std::tuple<float, float>
NewPos(float angle, float speed, float *x, float *y)
{

    angle = (angle-90.0)*0.0174532925199433;

    return std::make_tuple( cos(angle) * speed
                          , sin(angle) * speed);
}

int main()
{
    ...

    std::tie(x[i], y[i]) = NewPos(angle, speed);
}

I see no harm here, in fact the intent is more explicit.

Jeff

[toc] | [prev] | [next] | [standalone]

#14916

Jeff Flinn wrote:
> Pavel wrote:
>> BGB wrote:
>>> On 3/7/2012 8:48 AM, Rui Maciel wrote:
>>>> Victor Bazarov wrote:
>>>>
>>>>> The name 'Point' is misleading IMNSHO and so is the name of the
>>>>> function. What is returned is a velocity vector, not a position.
>>>>>
>>>>> And I am not so sure one couldn't just return std::pair<float,float>
>>>>> since it essentially does the same thing, except that its members are
>>>>> not called 'x' and 'y'... Why invent another type when a standard one
>>>>> exists?
>>>>
>>>> User-defined data types improve code readability. Under some 
>>>> circumstances,
>>>> it also help reduce the propensity to inadvertently add bugs to the 
>>>> code.
>>>>
>>>
>>> yep, and in many cases where points/vectors are in use, they are a 
>>> fairly
>>> fundamental building-block type, rather than an "afterthought" (or 
>>> "misc") type,
>>> making them more suited to having their own dedicated type-names and 
>>> their own
>>> dedicated logic.
>>>
>>>
>>> granted, a lot depends on the particular domain as well.
>>> for example, I am prone to think of a "money" or "date" types as 
>>> fairly misc,
>>> since I don't use them much for what I do, but there are people who 
>>> write types
>>> of software where such things make a good deal more sense (and 
>>> languages like
>>> SQL treat both as fundamental types).
>>>
>>> nevermind other strangeness (observed in accounting contexts): 
>>> thinking as dates
>>> strictly in terms of days, or even ignoring the existence of things 
>>> like leap
>>> years and similar in calculations (vs the more "sane" option of, say, 
>>> thinking
>>> as time more strictly in terms of an absolute number of seconds, as a 
>>> real
>>> value, between events).
>>>
>>> but, it could be argued that maybe for the accountant, there is 
>>> little reason
>>> for the accountant to care if "this time next year" may easily differ 
>>> by hours
>>> or maybe days from "this time next year" as far as a scientist or 
>>> engineer would
>>> be concerned (in terms of the number of seconds between "now" and 
>>> "this date and
>>> time exactly one year from now"...).
>>>
>>> or, for that matter, mentioning doing something "tomorrow" when it is 
>>> after
>>> midnight, and said "tomorrow" is maybe only 10 or 14 hours away and 
>>> technically
>>> the same day (as far as the calender is concerned...).
>>>
>>>
>>>
>>> and, say, if one writes a 3D engine, they will be seeing points, 
>>> vectors,
>>> matrices, ... quite a fair amount.
>>>
>>> so, yeah, sometimes it makes a lot of sense to make dedicated types 
>>> for these
>>> sorts of things.
>>>
>> I think those suggesting change in the interface other than replacing 
>> pointers with references spoke without trying to understand how the 
>> function is used.
>>
>> For example, if the call site converts separate arrays of the two 
>> velocity components, changing from output parameters to return type 
>> would do more harm than good.
> 
> std::tuple<float, float>
> NewPos(float angle, float speed, float *x, float *y)

Oops that should be:
std::tuple<float, float> NewPos(float angle, float speed)

> {
> 
>    angle = (angle-90.0)*0.0174532925199433;
> 
>    return std::make_tuple( cos(angle) * speed
>                          , sin(angle) * speed);
> }
> 
> int main()
> {
>    ...
> 
>    std::tie(x[i], y[i]) = NewPos(angle, speed);
> }
> 
> I see no harm here, in fact the intent is more explicit.
> 
> Jeff

[toc] | [prev] | [next] | [standalone]

#14855

On Tue, 06 Mar 2012 08:04:54 -0500, Victor Bazarov wrote:

> And I am not so sure one couldn't just return std::pair<float,float> 
> since it essentially does the same thing, except that its members are 
> not called 'x' and 'y'...  Why invent another type when a standard one 
> exists?

1. Clarity. A specific type provides clues as to the meaning of the data.

2. Safety. If you have separate Position and Velocity types, you'll get a
type error if you try to use one where the other is required.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web