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

[88888 Dihedral]

Jens Thoms Toerringæ–¼ 2011å¹´12月30日星期五UTC+8上åˆ3時38分38秒寫é“：

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++.



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.

 

[James Kuyper]

But it's also a coincidence that it offers the same issues in both languages;
there are lots of changes you might make which wouldn't.

And that's the thing; a lot of the posters here wouldn't know whether the
issues would be the same in C++ or not, and can't test the code as is on a
C compiler...


Oh, that might be. But...

If he's offering something that cannot possibly ever have even been waved in
the direction of a C compiler, the first interpretation that leaps to mind
is not "I am later going to have rewritten large hunks of this into C, at
which point I want to know how I'd do this."

Basically... If the question is about the code as is, it's going to get just
as good answers, or better, in a C++ forum. If it's about a hypothetical
translation of the code to C, it seems premature. Anything that is using
references strikes me as pretty likely to be changed significantly by a
conversion to C.

Not really - if I were handling it, the first step of the conversion
would be to convert the references to pointers, with corresponding
syntax changes in several locations. My second step would have been to
notice that there was no good reason to use pointers; but under the
circumstances, it seems unlikely that the OP would have noticed that
issue. The only other change that seems required is to replace

cout << "hi" << endl;

with
printf("hi\n");

Were there any other changes needed?

 

[Nobody]

Of some reason, floats seem to be widely used with opengl... Don' ask
me why - I don't know.

OpenGL itself either provides both float and double versions, or just a
double version.

Code which uses OpenGL tends to use double because the extra precision is
usually either entirely pointless (if the hardware only uses single
precision) or mostly pointless (any difference will be imperceptible), and
tends to harm performance (twice the memory consumption, either twice or
four times as many GPU cycles).

 

[BartC]

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..

 

[Keith Thompson]

OpenGL itself either provides both float and double versions, or just a
double version.

Code which uses OpenGL tends to use double because the extra precision is ------
usually either entirely pointless (if the hardware only uses single
precision) or mostly pointless (any difference will be imperceptible), and
tends to harm performance (twice the memory consumption, either twice or
four times as many GPU cycles).

Did you mean "Code which uses OpenGL tends to use float ..."?

 

[88888 Dihedral]

io_xæ–¼ 2011å¹´12月31日星期六UTC+8下åˆ11時32分30秒寫é“：

On 12/29/2011 02:03 PM, someone wrote:
On Dec 29, 6:34 pm, (e-mail address removed) (Jens Thoms Toerring) 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 GPAfrom 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

 

[osmium]

io_x? 2011?12?31????UTC+8??11?32?30???:

On 12/29/2011 02:03 PM, someone wrote:
On Dec 29, 6:34 pm, (e-mail address removed) (Jens Thoms Toerring) 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.

 

[Nobody]

Did you mean "Code which uses OpenGL tends to use float ..."?

Yes. Either that or "... tends to avoid double ...".

 

[Joe keane]

The cast is superfluous.

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

 

[Ben Bacarisse]

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.

 

[Phil Carmody]

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

Use your compiler flags to turn it into a warning, and turn warnings into
fatal errors?

Phil

 

[Tim Rentsch]

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])'

Can you answer these questions:

1. What is the type of the expression bezierData[0][0]?

2. What is the type of the expression &bezierData[0][0]?

3. What is the type of the expression bezierData[0]?

4. What is the type of the expression &bezierData[0]?

4. What is the type of the expression bezierData?

5. What is the type of the expression &bezierData?

and finally

6. What is the type of the parameter bezierCTRpts?

If you can answer these questions I believe you will
discover a solution to your problem.

If you like/ask for it, perhaps I can make a minimal working example.

That's a good idea, not just because it helps people on
the newsgroup, but if you do there is a good chance you'll
discover the answer yourself.

However, I hope one of you geniuses out there can spot my mistake
right on

Spotting the mistake is fairly easy. What's harder is
figuring out what makes it unclear to someone asking
the question and how to explain it to them.

 

[Tim Rentsch]

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.

 

[Tim Rentsch]

I'm curious as to why you say this. Your code is obviously C++. Nothing
similar to it has ever been part of C.

Granted that a similar question could apply to C, the mere fact that you're
using references means that the rules for what you're doing are certainly
going to be different.

So the question is: Why *aren't* you looking for a C++ group? Do you think
that they would be unable to answer your question? If so, why?

Just a question here. Did you look at all at the problem
he was having and try to decide if it was C related or
C++ related? I agree that the code is clearly C++ code;
but did you do any looking past that initial impression?
I'm just curious.

 

[Kaz Kylheku]

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.