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

Groups > comp.lang.c > #15186 > unrolled thread

passing static 2D array to function - not fully working like I hoped for...

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

Contents

  passing static 2D array to function - not fully working like I hoped for... someone <newsboost@gmail.com> - 2011-12-29 09:11 -0800
    Re: passing static 2D array to function - not fully working like I hoped for... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-29 17:27 +0000
      Re: passing static 2D array to function - not fully working like I hoped for... someone <newsboost@gmail.com> - 2011-12-29 10:55 -0800
    Re: passing static 2D array to function - not fully working like I hoped for... jt@toerring.de (Jens Thoms Toerring) - 2011-12-29 17:34 +0000
      Re: passing static 2D array to function - not fully working like I hoped for... someone <newsboost@gmail.com> - 2011-12-29 11:03 -0800
        Re: passing static 2D array to function - not fully working like I hoped for... jt@toerring.de (Jens Thoms Toerring) - 2011-12-29 19:38 +0000
          Re: passing static 2D array to function - not fully working like I hoped for... "BartC" <bc@freeuk.com> - 2011-12-29 23:19 +0000
            Re: passing static 2D array to function - not fully working like I hoped for... "BartC" <bc@freeuk.com> - 2011-12-31 11:29 +0000
          Re: passing static 2D array to function - not fully working like I hoped for... 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-29 17:26 -0800
        Re: passing static 2D array to function - not fully working like I hoped for... Keith Thompson <kst-u@mib.org> - 2011-12-29 11:58 -0800
          Re: passing static 2D array to function - not fully working like I hoped for... Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 17:45 -0800
            Re: passing static 2D array to function - not fully working like I hoped for... Kaz Kylheku <kaz@kylheku.com> - 2012-01-26 02:08 +0000
        Re: passing static 2D array to function - not fully working like I hoped for... James Kuyper <jameskuyper@verizon.net> - 2011-12-29 15:35 -0500
          Re: passing static 2D array to function - not fully working like I hoped for... Keith Thompson <kst-u@mib.org> - 2011-12-29 13:25 -0800
            Re: passing static 2D array to function - not fully working like I hoped for... "io_x" <a@b.c.invalid> - 2011-12-31 16:32 +0100
              Re: passing static 2D array to function - not fully working like I hoped for... 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-31 15:10 -0800
                Re: passing static 2D array to function - not fully working like I hoped for... "osmium" <r124c4u102@comcast.net> - 2011-12-31 18:03 -0600
        Re: passing static 2D array to function - not fully working like I hoped for... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-29 20:37 +0000
          Re: passing static 2D array to function - not fully working like I hoped for... jgk@panix.com (Joe keane) - 2012-01-03 15:48 +0000
            Re: passing static 2D array to function - not fully working like I hoped for... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-03 16:47 +0000
            Re: passing static 2D array to function - not fully working like I hoped for... Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-01-05 22:31 +0200
        Re: passing static 2D array to function - not fully working like I hoped for... Nobody <nobody@nowhere.com> - 2011-12-31 09:23 +0000
          Re: passing static 2D array to function - not fully working like I hoped for... Keith Thompson <kst-u@mib.org> - 2011-12-31 11:04 -0800
            Re: passing static 2D array to function - not fully working like I hoped for... Nobody <nobody@nowhere.com> - 2012-01-01 08:20 +0000
    Re: passing static 2D array to function - not fully working like I hoped for... Barry Schwarz <schwarzb@dqel.com> - 2011-12-29 09:49 -0800
      Re: passing static 2D array to function - not fully working like I hoped for... someone <newsboost@gmail.com> - 2011-12-29 11:13 -0800
        Re: passing static 2D array to function - not fully working like I hoped for... Seebs <usenet-nospam@seebs.net> - 2011-12-29 19:22 +0000
          Re: passing static 2D array to function - not fully working like I hoped for... someone <newsboost@gmail.com> - 2011-12-29 13:29 -0800
            Re: passing static 2D array to function - not fully working like I hoped for... Seebs <usenet-nospam@seebs.net> - 2011-12-29 21:42 +0000
              Re: passing static 2D array to function - not fully working like I hoped for... someone <newsboost@gmail.com> - 2011-12-29 15:28 -0800
            Re: passing static 2D array to function - not fully working like I hoped for... Keith Thompson <kst-u@mib.org> - 2011-12-29 14:46 -0800
          Re: passing static 2D array to function - not fully working like I hoped for... James Kuyper <jameskuyper@verizon.net> - 2011-12-29 18:29 -0500
            Re: passing static 2D array to function - not fully working like I hoped for... Seebs <usenet-nospam@seebs.net> - 2011-12-30 00:03 +0000
              Re: passing static 2D array to function - not fully working like I hoped for... James Kuyper <jameskuyper@verizon.net> - 2011-12-29 21:30 -0500
          Re: passing static 2D array to function - not fully working like I hoped for... Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 17:47 -0800
    Re: passing static 2D array to function - not fully working like I hoped for... Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 17:39 -0800

Page 1 of 2  [1] 2  Next page →

#15186 — passing static 2D array to function - not fully working like I hoped for...

Hi all

Noob question:

-----------------------------------------------------------------------------
typedef float GLfloat; // float = GLfloat

void setBezierPoint(const double &x, const double &y, const double &z,
                    const int &P, GLfloat bezierCTRpts[][3])
{
  bezierCTRpts[P][0] = (GLfloat)x;
  bezierCTRpts[P][1] = (GLfloat)y;
  bezierCTRpts[P][2] = (GLfloat)z;
}


void FindBezierControlPointsND(const int *N_kontur,
      const double *cpp_X, const double *cpp_Y, GLfloat bezierData[]
[3])
{
  // calculations...
  // set xyz for point P=0 using 4th input parameter:
  setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, 0, bezierData);

  // set xyz for point P=3 using 4th input parameter:
  setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, 3, bezierData);
}


int main(int argc, char** argv)
{
  cout << "hi" << endl;
  GLfloat bezierData[4][3] = {0};

  // something
  FindBezierControlPointsND( &N_kontur, Xval, Yval, bezierData);
}
-----------------------------------------------------------------------------

Explanation:

I have a static 2D array: bezierData[4][3], 4 points * xyz-coordinates
and I pass it to FindBezierControlPointsND with this call:

  FindBezierControlPointsND( &N_kontur, Xval, Yval, bezierData);

and the function takes: GLfloat bezierData[][3] as input.
All is ok - the code works, however what I really wanted was to omit
the 4th input parameter (const int &P) so it looks like:

void setBezierPoint(const double &x, const double &y, const double &z,
                    GLfloat bezierCTRpts[][3]) // 4th input is GONE !
{
  bezierCTRpts[0][0] = (GLfloat)x;
  bezierCTRpts[0][1] = (GLfloat)y;
  bezierCTRpts[0][2] = (GLfloat)z;
}

Then I wanted to set the xyz-values by a function call like:

- for P=0:
  setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, bezierData[0][0]);

- for P=3:
  setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, bezierData[3][0]);


This however doesn't work! I also tried to add "&" in front of
bezierData[3][0] etc... Error message is something like:

error: cannot convert ‘GLfloat* {aka float*}’ to ‘GLfloat* (*)[3] {aka
float* (*)[3]}’ for argument ‘4’ to ‘void setBezierPoint(const
double&, const double&, const double&, GLfloat* (*)[3])’


If you like/ask for it, perhaps I can make a minimal working example.
However, I hope one of you geniuses out there can spot my mistake
right on :-)

THANKS!

[toc] | [next] | [standalone]

#15188

someone <newsboost@gmail.com> writes:
<snip>
> -----------------------------------------------------------------------------
> typedef float GLfloat; // float = GLfloat
>
> void setBezierPoint(const double &x, const double &y, const double &z,
>                     const int &P, GLfloat bezierCTRpts[][3])

This is not C!  Did you intend to remove the references?  If you are
really writing C++ there may be much better ways to it.

> {
>   bezierCTRpts[P][0] = (GLfloat)x;
>   bezierCTRpts[P][1] = (GLfloat)y;
>   bezierCTRpts[P][2] = (GLfloat)z;
> }
>
>
> void FindBezierControlPointsND(const int *N_kontur,
>       const double *cpp_X, const double *cpp_Y, GLfloat bezierData[]
> [3])
> {
>   // calculations...
>   // set xyz for point P=0 using 4th input parameter:
>   setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, 0, bezierData);
>
>   // set xyz for point P=3 using 4th input parameter:
>   setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, 3, bezierData);
> }
>
>
> int main(int argc, char** argv)
> {
>   cout << "hi" << endl;
>   GLfloat bezierData[4][3] = {0};
>
>   // something
>   FindBezierControlPointsND( &N_kontur, Xval, Yval, bezierData);
> }
> -----------------------------------------------------------------------------
>
> Explanation:
>
> I have a static 2D array: bezierData[4][3], 4 points * xyz-coordinates
> and I pass it to FindBezierControlPointsND with this call:
>
>   FindBezierControlPointsND( &N_kontur, Xval, Yval, bezierData);
>
> and the function takes: GLfloat bezierData[][3] as input.
> All is ok - the code works, however what I really wanted was to omit
> the 4th input parameter (const int &P) so it looks like:
>
> void setBezierPoint(const double &x, const double &y, const double &z,
>                     GLfloat bezierCTRpts[][3]) // 4th input is GONE !

You need simply to pass a pointer to once bezier tripple, rather than to
(the start of) an array of them.  Then, in the function, you drop the
first index.

  void setBezierPoint(const double &x, const double &y, const double &z,
                      GLfloat bezierCTRpt[])
  {
    bezierCTRpt[0] = x;
    bezierCTRpt[1] = y;
    bezierCTRpt[2] = z;
  }

(I make the name singular since there is now one point being passed).
Note that the casts are no needed -- they just clutter up the code in my
opinion.

> Then I wanted to set the xyz-values by a function call like:
>
> - for P=0:
>   setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, bezierData[0][0]);
>
> - for P=3:
>   setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, bezierData[3][0]);

Here you drop the second index or add and & operator:

   setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, bezierData[3]);
   setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, &bezierData[3][0]);

> This however doesn't work! I also tried to add "&" in front of
> bezierData[3][0] etc... Error message is something like:

You were so close.  Have a read of the C FAQ -- arrays are a little
fiddly: http://c-faq.com/

Post a follow up if you don't see why this works (or if I've got
the wrong end of the stick).

<snip>
-- 
Ben.

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

#15198

On Dec 29, 6:27 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> someone <newsbo...@gmail.com> writes:
>
> <snip>
>
> > -----------------------------------------------------------------------------
> > typedef float GLfloat; // float = GLfloat
>
> > void setBezierPoint(const double &x, const double &y, const double &z,
> >                     const int &P, GLfloat bezierCTRpts[][3])
>
> This is not C!  Did you intend to remove the references?  If you are
> really writing C++ there may be much better ways to it.

I forgot that &(var) is C++, however I think that is the only thing I
forgot... I even added a typedef in the beginning to avoid someone
telling me that GLfloat "is not part of the C-standard, hence not a
question for this group"...

I am/was looking for the "C-answer", not a "C++-answer", so that's why
I thought it is better to post to here...

.........................

> > Explanation:
>
> > I have a static 2D array: bezierData[4][3], 4 points * xyz-coordinates
> > and I pass it to FindBezierControlPointsND with this call:
>
> >   FindBezierControlPointsND( &N_kontur, Xval, Yval, bezierData);
>
> > and the function takes: GLfloat bezierData[][3] as input.
> > All is ok - the code works, however what I really wanted was to omit
> > the 4th input parameter (const int &P) so it looks like:
>
> > void setBezierPoint(const double &x, const double &y, const double &z,
> >                     GLfloat bezierCTRpts[][3]) // 4th input is GONE !
>
> You need simply to pass a pointer to once bezier tripple, rather than to
> (the start of) an array of them.  Then, in the function, you drop the
> first index.


Aaah, thank you very much!

>   void setBezierPoint(const double &x, const double &y, const double &z,
>                       GLfloat bezierCTRpt[])
>   {
>     bezierCTRpt[0] = x;
>     bezierCTRpt[1] = y;
>     bezierCTRpt[2] = z;
>   }
>
> (I make the name singular since there is now one point being passed).
> Note that the casts are no needed -- they just clutter up the code in my
> opinion.

Thank you!

> > Then I wanted to set the xyz-values by a function call like:
>
> > - for P=0:
> >   setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, bezierData[0][0]);
>
> > - for P=3:
> >   setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, bezierData[3][0]);
>
> Here you drop the second index or add and & operator:
>
>    setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, bezierData[3]);
>    setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, &bezierData[3][0]);

I see...

> > This however doesn't work! I also tried to add "&" in front of
> > bezierData[3][0] etc... Error message is something like:
>
> You were so close.  Have a read of the C FAQ -- arrays are a little
> fiddly:http://c-faq.com/

I tried to google quite some answers but couldn't find exactly this
little problem anywhere... Maybe q.6.18 from the C-faq should've
helped me.

In any case, it's great that there are people to help each other
around in here - thank you very much, Ben!

> Post a follow up if you don't see why this works (or if I've got
> the wrong end of the stick).

I get the idea now, thanks :-)

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

#15190

someone <newsboost@gmail.com> wrote:

Please note that your code is C++ while this is a C newsgroup.
It would be more prudent if you would post to comp.land.c++,
where the C++ experts are to be found. But since there's no
big difference here between C and C++ I'll try to come up
with a proposal:

> -----------------------------------------------------------------------------
> typedef float GLfloat; // float = GLfloat

> void setBezierPoint(const double &x, const double &y, const double &z,
>                     const int &P, GLfloat bezierCTRpts[][3])
> {
>   bezierCTRpts[P][0] = (GLfloat)x;
>   bezierCTRpts[P][1] = (GLfloat)y;
>   bezierCTRpts[P][2] = (GLfloat)z;
> }


> void FindBezierControlPointsND(const int *N_kontur,
>       const double *cpp_X, const double *cpp_Y, GLfloat bezierData[][3])
> {
>   // calculations...
>   // set xyz for point P=0 using 4th input parameter:
>   setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, 0, bezierData);

>   // set xyz for point P=3 using 4th input parameter:
>   setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, 3, bezierData);
> }


> int main(int argc, char** argv)
> {
>   cout << "hi" << endl;
>   GLfloat bezierData[4][3] = {0};

>   // something
>   FindBezierControlPointsND( &N_kontur, Xval, Yval, bezierData);
> }
> -----------------------------------------------------------------------------

> Explanation:

> I have a static 2D array: bezierData[4][3], 4 points * xyz-coordinates
> and I pass it to FindBezierControlPointsND with this call:

>   FindBezierControlPointsND( &N_kontur, Xval, Yval, bezierData);

> and the function takes: GLfloat bezierData[][3] as input.
> All is ok - the code works, however what I really wanted was to omit
> the 4th input parameter (const int &P) so it looks like:

> void setBezierPoint(const double &x, const double &y, const double &z,
>                     GLfloat bezierCTRpts[][3]) // 4th input is GONE !
> {
>   bezierCTRpts[0][0] = (GLfloat)x;
>   bezierCTRpts[0][1] = (GLfloat)y;
>   bezierCTRpts[0][2] = (GLfloat)z;
> }

Why then not make it

void setBezierPoint(const double &x, const double &y, const double &z,
                   GLfloat bezierCTRpts[3])
{
  bezierCTRpts[0] = (GLfloat)x;
  bezierCTRpts[1] = (GLfloat)y;
  bezierCTRpts[2] = (GLfloat)z;
}

Note that the casts to 'GLfloat' are rather likely unnecessary
- why did you put them in? I would recomend to use casts only
when they are really needed (and since you're doing C++ you
also should be using C++-style casts if you have a good reason
to use them.

> Then I wanted to set the xyz-values by a function call like:

> - for P=0:
>   setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, bezierData[0][0]);

> - for P=3:
>   setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, bezierData[3][0]);

With the modified signature of setBezierPoint() you know can
call it like

    setBezierPoint( cpp_X[0], cpp_Y[0], 0.0, bezierData[0]);

    setBezierPoint( cpp_X[0], cpp_Y[0], 0.0, bezierData[3]);

since setBezierPoint() now expects a simple array with 3 elements
and that's what you pass it that way.

                            Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#15199

On Dec 29, 6:34 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> someone <newsbo...@gmail.com> wrote:
>
> Please note that your code is C++ while this is a C newsgroup.

Maybe 1% C++ and 99% C, ok.

> It would be more prudent if you would post to comp.land.c++,
> where the C++ experts are to be found. But since there's no

No, I don't think so.

> big difference here between C and C++ I'll try to come up
> with a proposal:


................


> > Explanation:
> > I have a static 2D array: bezierData[4][3], 4 points * xyz-coordinates
> > and I pass it to FindBezierControlPointsND with this call:
> >   FindBezierControlPointsND( &N_kontur, Xval, Yval, bezierData);
> > and the function takes: GLfloat bezierData[][3] as input.
> > All is ok - the code works, however what I really wanted was to omit
> > the 4th input parameter (const int &P) so it looks like:
> > void setBezierPoint(const double &x, const double &y, const double &z,
> >                     GLfloat bezierCTRpts[][3]) // 4th input is GONE !
> > {
> >   bezierCTRpts[0][0] = (GLfloat)x;
> >   bezierCTRpts[0][1] = (GLfloat)y;
> >   bezierCTRpts[0][2] = (GLfloat)z;
> > }
>
> Why then not make it
>
> void setBezierPoint(const double &x, const double &y, const double &z,
>                    GLfloat bezierCTRpts[3])
> {
>   bezierCTRpts[0] = (GLfloat)x;
>   bezierCTRpts[1] = (GLfloat)y;
>   bezierCTRpts[2] = (GLfloat)z;
>
> }

Thank you very much.

> Note that the casts to 'GLfloat' are rather likely unnecessary
> - why did you put them in? I would recomend to use casts only

Actually I cast double -> float, so I make the intermediate
calculations using double precision, but when it comes to actually
storing the data, I save it as a float (less precision). Normally I
would be doing everything with double precision...

Of some reason, floats seem to be widely used with opengl... Don' ask
me why - I don't know. That's why I cast. I could also cast before
calling the function, of course...

> when they are really needed (and since you're doing C++ you
> also should be using C++-style casts if you have a good reason
> to use them.

I don't see why, if it works and apparently it does work out fine with
C?

> > Then I wanted to set the xyz-values by a function call like:
> > - for P=0:
> >   setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, bezierData[0][0]);
> > - for P=3:
> >   setBezierPoint(cpp_X[0], cpp_Y[0], 0.0, bezierData[3][0]);
>
> With the modified signature of setBezierPoint() you know can
> call it like
>
>     setBezierPoint( cpp_X[0], cpp_Y[0], 0.0, bezierData[0]);
>
>     setBezierPoint( cpp_X[0], cpp_Y[0], 0.0, bezierData[3]);
>
> since setBezierPoint() now expects a simple array with 3 elements
> and that's what you pass it that way.

That's great Jens. Thank you very much. Appreciate your help and
time...

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

#15202

someone <newsboost@gmail.com> wrote:
> On Dec 29, 6:34 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> > someone <newsbo...@gmail.com> wrote:
> >
> > Please note that your code is C++ while this is a C newsgroup.

> Maybe 1% C++ and 99% C, ok.

Well, there are sume subtle differences between C and C++
and when you write C++ (i.e. use a C++ compiler, your program
won't compile with a C compiler) then it's typically better
to ask in the correct group - it may safe you a lot of time
and grieve. And sometimes there are also more elegant so-
lutions to a problem in C++.

> > Note that the casts to 'GLfloat' are rather likely unnecessary
> > - why did you put them in? I would recomend to use casts only

> Actually I cast double -> float, so I make the intermediate
> calculations using double precision, but when it comes to actually
> storing the data, I save it as a float (less precision). Normally I
> would be doing everything with double precision...

All calculations are done in double anyway (even if you
use floats - and on quite a number of architectures even
with an even wider representation than double, i.e. on
x86 you often have 64 bit doubles but computation are all
done with 80 bit) and if you assign to a float the value
will be converted to a float without any cast.

> Of some reason, floats seem to be widely used with opengl...

Probably because the results don't need a high precision (does
it matter if a pixel is shown at position 231.122387267423 or
231.122387267424?) and floats often take only half as much
space as doubles to store.
                             Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#15216

"Jens Thoms Toerring" <jt@toerring.de> wrote in message 
news:9m3ttuFb3eU1@mid.uni-berlin.de...
> someone <newsboost@gmail.com> wrote:


>> Of some reason, floats seem to be widely used with opengl...
>
> Probably because the results don't need a high precision (does
> it matter if a pixel is shown at position 231.122387267423 or
> 231.122387267424?)

When it finally gets to the screen, it doesn't matter. But it might well do 
long before that.

Single precision only gives an accuracy of about 1 in 8 million; if the 
model you're trying to display uses vertices relative to some distant point 
(for example, one particular location in a country), then there could be 
obvious errors in the endpoints of the lines you're trying to draw.

Single precision can still be used, if that is all that is available, but 
might require some extra ingenuity to use with some kinds of model.

-- 
Bartc 

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

#15243

"BartC" <bc@freeuk.com> wrote in message news:jdisku$hbb$1@dont-email.me...
> "Jens Thoms Toerring" <jt@toerring.de> wrote in message 
> news:9m3ttuFb3eU1@mid.uni-berlin.de...
>> someone <newsboost@gmail.com> wrote:
>
>
>>> Of some reason, floats seem to be widely used with opengl...
>>
>> Probably because the results don't need a high precision (does
>> it matter if a pixel is shown at position 231.122387267423 or
>> 231.122387267424?)

> Single precision can still be used, if that is all that is available, but 
> might require some extra ingenuity to use with some kinds of model.

Reading Nobody's reply reminds me that OpenGL probably did offer Double 
options on it's functions (although where supported by graphics hardware, 
this is likely to be limited to single precision).

I must have been thinking about DirectX..

-- 
Bartc 

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

#15224

Jens Thoms Toerring於 2011年12月30日星期五UTC+8上午3時38分38秒寫道：
> someone <news...@gmail.com> wrote:
> > On Dec 29, 6:34 pm, j....@toerring.de (Jens Thoms Toerring) wrote:
> > > someone <news...@gmail.com> wrote:
> > >
> > > Please note that your code is C++ while this is a C newsgroup.
> 
> > Maybe 1% C++ and 99% C, ok.
> 
> Well, there are sume subtle differences between C and C++
> and when you write C++ (i.e. use a C++ compiler, your program
> won't compile with a C compiler) then it's typically better
> to ask in the correct group - it may safe you a lot of time
> and grieve. And sometimes there are also more elegant so-
> lutions to a problem in C++.
> 
> > > Note that the casts to 'GLfloat' are rather likely unnecessary
> > > - why did you put them in? I would recomend to use casts only
> 
> > Actually I cast double -> float, so I make the intermediate
> > calculations using double precision, but when it comes to actually
> > storing the data, I save it as a float (less precision). Normally I
> > would be doing everything with double precision...
> 
> All calculations are done in double anyway (even if you
> use floats - and on quite a number of architectures even
> with an even wider representation than double, i.e. on
> x86 you often have 64 bit doubles but computation are all
> done with 80 bit) and if you assign to a float the value
> will be converted to a float without any cast.
> 

A float can fit in 32 bits. The lifting of two floats into  doubles of 64 or 
 80 bits either does not increase the  precisions of the two sources at all 
in any math operations but can save the result better than a float.




 


> > Of some reason, floats seem to be widely used with opengl...
> 
> Probably because the results don't need a high precision (does
> it matter if a pixel is shown at position 231.122387267423 or
> 231.122387267424?) and floats often take only half as much
> space as doubles to store.
>                              Regards, Jens
> -- 
>   \   Jens Thoms Toerring  ___      j...@toerring.de
>    \__________________________      http://toerring.de

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

#15205

someone <newsboost@gmail.com> writes:
> On Dec 29, 6:34 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
>> someone <newsbo...@gmail.com> wrote:
>>
>> Please note that your code is C++ while this is a C newsgroup.
>
> Maybe 1% C++ and 99% C, ok.

There's a term for code that's 1% CZ++ and 99% C.  We call it "C++".

There are at least 2 C++-specific things in your code: the parameters of
setBezierPoint are C++ references, and you use "cout << ..." in main().

And even if those are corrected, you have no declaration for N_kontur,
Xval, or Yval.

It's not a *huge* deal, but for future reference it's best to post
straight C code here.  Compile it with a C compiler and copy-and-paste
the exact code that you compiled.  Otherwise, it can be difficult to
tell whether your problems are C++-specific and/or whether they're
related to errors you made when you re-typed the code.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#16253

Keith Thompson <kst-u@mib.org> writes:

> someone <newsboost@gmail.com> writes:
>> On Dec 29, 6:34 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
>>> someone <newsbo...@gmail.com> wrote:
>>>
>>> Please note that your code is C++ while this is a C newsgroup.
>>
>> Maybe 1% C++ and 99% C, ok.
>
> There's a term for code that's 1% CZ++ and 99% C.  We call it "C++".
>
> There are at least 2 C++-specific things in your code: the parameters of
> setBezierPoint are C++ references, and you use "cout << ..." in main().
>
> And even if those are corrected, you have no declaration for N_kontur,
> Xval, or Yval.
>
> It's not a *huge* deal, but for future reference it's best to post
> straight C code here.  Compile it with a C compiler and copy-and-paste
> the exact code that you compiled.  Otherwise, it can be difficult to
> tell whether your problems are C++-specific and/or whether they're
> related to errors you made when you re-typed the code.

I think this reaction is somewhat harsh.  Despite the code
having some C++ aspects, the issue underlying the question
is fairly obviously a C question, so someone here should
have been able to help him.  What's more, it seems plausible
that the problem he was having is something that C people
would be better at than C++ people, in which case sending
him over to comp.lang.c++ would have hurt rather than
helped.  I don't think that's what you want.

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

#16254

On 2012-01-26, Tim Rentsch <txr@alumni.caltech.edu> wrote:
> have been able to help him.  What's more, it seems plausible
> that the problem he was having is something that C people
> would be better at than C++ people, in which case sending
> him over to comp.lang.c++ would have hurt rather than
> helped.  I don't think that's what you want.

Also, maybe it's a dialect of C which has C++-like references.

Jacob Navia's Lcc-Win32 has references.

If such a dialect doesn't have a more specific newsgroup of its own,
comp.lang.c is it.

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

#15207

On 12/29/2011 02:03 PM, someone wrote:
> On Dec 29, 6:34 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
>> someone <newsbo...@gmail.com> wrote:
...
>>> Explanation:
>>> I have a static 2D array: bezierData[4][3], 4 points * xyz-coordinates
>>> and I pass it to FindBezierControlPointsND with this call:
>>>   FindBezierControlPointsND( &N_kontur, Xval, Yval, bezierData);
>>> and the function takes: GLfloat bezierData[][3] as input.
>>> All is ok - the code works, however what I really wanted was to omit
>>> the 4th input parameter (const int &P) so it looks like:
>>> void setBezierPoint(const double &x, const double &y, const double &z,
>>>                     GLfloat bezierCTRpts[][3]) // 4th input is GONE !
>>> {
>>>   bezierCTRpts[0][0] = (GLfloat)x;
>>>   bezierCTRpts[0][1] = (GLfloat)y;
>>>   bezierCTRpts[0][2] = (GLfloat)z;
>>> }

There's really no reason for using C++ references here. You're not
changing the thing they refer to. C++ references are just syntactic
sugar for something that could also be done in ordinary C using pointers
(don't get me wrong - I like some kinds of syntactic sugar, and C++
references can be useful). By using a reference, you avoid a copy, but
impose the cost of dereferencing the pointer - it's pretty much a wash,
unless the parameter has a big complicated type - which isn't the case
for double.

>> Why then not make it
>>
>> void setBezierPoint(const double &x, const double &y, const double &z,
>>                    GLfloat bezierCTRpts[3])
>> {
>>   bezierCTRpts[0] = (GLfloat)x;
>>   bezierCTRpts[1] = (GLfloat)y;
>>   bezierCTRpts[2] = (GLfloat)z;
>>
>> }
> 
> Thank you very much.
> 
>> Note that the casts to 'GLfloat' are rather likely unnecessary
>> - why did you put them in? I would recomend to use casts only
> 
> Actually I cast double -> float, so I make the intermediate
> calculations using double precision, but when it comes to actually
> storing the data, I save it as a float (less precision). Normally I
> would be doing everything with double precision...
> 
> Of some reason, floats seem to be widely used with opengl... Don' ask
> me why - I don't know. That's why I cast.

But it doesn't make any difference; the conversion specified by the cast
will occur automatically even if you don't write the cast.

> ... I could also cast before
> calling the function, of course...

With the current declaration, that would be a waste of time; the values
would be converted back to double before executing the function call. If
you changed the function's declaration to have it take float parameters,
the conversion would occur automatically as a result of calling the
function, whether or not you used a cast. It wouldn't make much
difference compared to the current code.

>> when they are really needed (and since you're doing C++ you
>> also should be using C++-style casts if you have a good reason
>> to use them.
> 
> I don't see why, if it works and apparently it does work out fine with
> C?

C++'s specialized casts aren't needed here, for precisely the same
reason that the C casts aren't needed. However, where a cast is needed,
C++'s specialized casts are better because a diagnostic message is
mandatory if the combination of the type of the argument and the result
type violates the requirements of the specialized cast. It's just a
matter of choosing the appropriate specialized cast for the conversion
you want performed - in this case, static_cast<>. The diagnostic makes
it easier to detect problems due to giving the wrong expression or the
wrong result type, or the wrong specialized cast.

If you're certain you'll never make any such mistake, then it doesn't
matter. I don't think it's possible to be sanely certain of such things.
However, it is possible to sanely believe it's too much additional work
to justify bothering with.

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

#15211

James Kuyper <jameskuyper@verizon.net> writes:
> On 12/29/2011 02:03 PM, someone wrote:
>> On Dec 29, 6:34 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
>>> someone <newsbo...@gmail.com> wrote:
[...]
>>>> void setBezierPoint(const double &x, const double &y, const double &z,
>>>>                     GLfloat bezierCTRpts[][3]) // 4th input is GONE !
>>>> {
[...]
>>>> }
>
> There's really no reason for using C++ references here. You're not
> changing the thing they refer to. C++ references are just syntactic
> sugar for something that could also be done in ordinary C using pointers
> (don't get me wrong - I like some kinds of syntactic sugar, and C++
> references can be useful). By using a reference, you avoid a copy, but
> impose the cost of dereferencing the pointer - it's pretty much a wash,
> unless the parameter has a big complicated type - which isn't the case
> for double.

And in this case, it doesn't make much sense to use a reference even in
C++.  You're passing the argument by reference, byt the "const" means
the function can't use the reference to modify the argument anyway.

In either C or C++, you might as well define the function as:

void setBezierPoint(double x, double y, double z,
                    GLfloat bezierCTRpts[][3])
{
[...]
}

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#15246

"Keith Thompson" <kst-u@mib.org> ha scritto nel messaggio
news:lnlipvxe8b.fsf@nuthaus.mib.org...
> James Kuyper <jameskuyper@verizon.net> writes:
>> On 12/29/2011 02:03 PM, someone wrote:
>>> On Dec 29, 6:34 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
>>>> someone <newsbo...@gmail.com> wrote:
> [...]
>>>>> void setBezierPoint(const double &x, const double &y, const double &z,
>>>>>                     GLfloat bezierCTRpts[][3]) // 4th input is GONE !
>>>>> {
> [...]
> void setBezierPoint(double x, double y, double z,
>                    GLfloat bezierCTRpts[][3])
> {
> [...]
> }

here in the C++ case, i think, what is passed is a 32bit pointer each double arg
while in the C just above case is 64 bit double value, each double arg
so more data in the stack in the C case above

if in C++ i would use references in the case as above; something as

i32 setBezierPoint(GLfloat** bezierCTRptsRes, d64 &x, d64 &y, d64 &z) // 4th
input is GONE !

> -- 
> Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
>    Will write code for food.
> "We must do something.  This is something.  Therefore, we must do this."
>    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#15258

io_x於 2011年12月31日星期六UTC+8下午11時32分30秒寫道：
> "Keith Thompson" <ks...@mib.org> ha scritto nel messaggio
> news:lnlipvxe8b.fsf@nuthaus.mib.org...
> > James Kuyper <james...@verizon.net> writes:
> >> On 12/29/2011 02:03 PM, someone wrote:
> >>> On Dec 29, 6:34 pm, j....@toerring.de (Jens Thoms Toerring) wrote:
> >>>> someone <news...@gmail.com> wrote:
> > [...]
> >>>>> void setBezierPoint(const double &x, const double &y, const double &z,
> >>>>>                     GLfloat bezierCTRpts[][3]) // 4th input is GONE !
> >>>>> {
> > [...]
> > void setBezierPoint(double x, double y, double z,
> >                    GLfloat bezierCTRpts[][3])
> > {
> > [...]
> > }
> 
> here in the C++ case, i think, what is passed is a 32bit pointer each double arg
> while in the C just above case is 64 bit double value, each double arg
> so more data in the stack in the C case above
> 
> if in C++ i would use references in the case as above; something as
> 
> i32 setBezierPoint(GLfloat** bezierCTRptsRes, d64 &x, d64 &y, d64 &z) // 4th
> input is GONE !
> 

Doubles in the X86, Mips, ArmX,  Sh-XX, SparcX, LION from ESA 
and  N-64 are all different. 

But I think the 8 core Cell from IBM in PS3 can kill the strange NVIDIA GPA from the PC platform  if Sonny really wanted to do that. 

Sonny sold some boards in  racks  of the Cell cores  in the movie industry,
and GPAS from NVIDIA were not useful at all. 

Perhaps more subtle business concerns in the stock market were framed. 

Japanese always diversify component suppliers in the long run. 
 
  



 
serious enough 


> > -- 
> > Keith Thompson (The_Other_Keith) ks...@mib.org  <http://www.ghoti.net/~kst>
> >    Will write code for food.
> > "We must do something.  This is something.  Therefore, we must do this."
> >    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#15259

88888 Dihedral wrote:

> io_x? 2011?12?31????UTC+8??11?32?30???:
>> "Keith Thompson" <ks...@mib.org> ha scritto nel messaggio
>> news:lnlipvxe8b.fsf@nuthaus.mib.org...
>>> James Kuyper <james...@verizon.net> writes:
>>>> On 12/29/2011 02:03 PM, someone wrote:
>>>>> On Dec 29, 6:34 pm, j....@toerring.de (Jens Thoms Toerring) wrote:
>>>>>> someone <news...@gmail.com> wrote:
>>> [...]
>>>>>>> void setBezierPoint(const double &x, const double &y, const
>>>>>>>                     double &z, GLfloat bezierCTRpts[][3]) //
>>>>>>> 4th input is GONE ! {
>>> [...]
>>> void setBezierPoint(double x, double y, double z,
>>>                    GLfloat bezierCTRpts[][3])
>>> {
>>> [...]
>>> }
>>
>> here in the C++ case, i think, what is passed is a 32bit pointer
>> each double arg while in the C just above case is 64 bit double
>> value, each double arg
>> so more data in the stack in the C case above
>>
>> if in C++ i would use references in the case as above; something as
>>
>> i32 setBezierPoint(GLfloat** bezierCTRptsRes, d64 &x, d64 &y, d64
>> &z) // 4th input is GONE !
>>
>
> Doubles in the X86, Mips, ArmX,  Sh-XX, SparcX, LION from ESA
> and  N-64 are all different.
>
> But I think the 8 core Cell from IBM in PS3 can kill the strange
> NVIDIA GPA from the PC platform  if Sonny really wanted to do that.
>
> Sonny sold some boards in  racks  of the Cell cores  in the movie
> industry,
> and GPAS from NVIDIA were not useful at all.
>
> Perhaps more subtle business concerns in the stock market were framed.
>
> Japanese always diversify component suppliers in the long run.

A bird in the hand is worth two in the bush.

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

#15208

someone <newsboost@gmail.com> writes:

> On Dec 29, 6:34 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
>> someone <newsbo...@gmail.com> wrote:
<snip>
>> > void setBezierPoint(const double &x, const double &y, const double &z,
>> >                     GLfloat bezierCTRpts[][3]) // 4th input is GONE !
>> > {
>> >   bezierCTRpts[0][0] = (GLfloat)x;
>> >   bezierCTRpts[0][1] = (GLfloat)y;
>> >   bezierCTRpts[0][2] = (GLfloat)z;
>> > }
<snip>
>> Note that the casts to 'GLfloat' are rather likely unnecessary
>> - why did you put them in? I would recomend to use casts only
>
> Actually I cast double -> float, so I make the intermediate
> calculations using double precision, but when it comes to actually
> storing the data, I save it as a float (less precision).

You may be confusing "cast" with "convert".  Jens (and I) were saying
that the *casts* are unnecessary, not the conversion.  C's assignment
includes and implicit conversion from the type of the right hand side to
that of the left hand side.  The cast is superfluous.

<snip>
-- 
Ben.

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

#15374

In article <0.dcfd9b0b4291e1147cd8.20111229203726GMT.87vcoz9ks9.fsf@bsb.me.uk>,
Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>The cast is superfluous.

Automatic conversion of 'double' to 'float' is one thing that i would
rather not have in the language.

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

#15376

jgk@panix.com (Joe keane) writes:

> In article <0.dcfd9b0b4291e1147cd8.20111229203726GMT.87vcoz9ks9.fsf@bsb.me.uk>,
> Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>>The cast is superfluous.
>
> Automatic conversion of 'double' to 'float' is one thing that i would
> rather not have in the language.

OK, but it's there, like it or not!  The cast might have been put there
to shut the compiler up, but from the style of the code I doubt it.  gcc
can be asked to warn about implicit demotions from double to float which
is the next best thing to not having them in the language.  If the cast
was added to silence this warning, then I'd say a comment is called for.
The programmer should say why it's OK not to be warned about this
potentially lossy conversion.

-- 
Ben.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web