Click to See Complete Forum and Search --> : Obscure code help
xargon
February 26th, 2003, 12:41 PM
Came across the following:
typedef double (*COMPLEX_ARRAY)[2];
What does this do??
Thanks for any help you might give me,
Pankaj
dude_1967
February 26th, 2003, 02:45 PM
Evidently the type define of COMPLEX_ARRAY is a pointer to an array of two doubles. The example below should clear it up somewhat.
Chris.
:)
#include <iostream>
#include <iomanip>
typedef double (*COMPLEX_ARRAY)[2];
int main(int argc, char* argv[])
{
double d[2] = { 1.0, 2.0 };
COMPLEX_ARRAY ca = &d;
std::cout.precision(15);
std::cout << std::fixed << (*ca)[0] << std::endl;
std::cout << std::fixed << (*ca)[1] << std::endl;
return 1;
}
Graham
February 26th, 2003, 04:45 PM
I sincerely hope that that typedef comes from a C source file and not a C++ source file.....
Are you sure, dude? I had thought that, given the name, it's supposed to represent what you said: an array of pairs of doubles. But then I had to ask myself whether the parentheses change that? Does it actually declare a two-element array of pointers to double?
The point I'm trying to make is that, even for experienced programmers, you have to think really hard about whether it actually does what it appears to say. The author of that line should be hauled up in front of the whole workforce and publically humiliated for perpetrating an obfuscation. As an absolute minimum, the code ought to be:
typedef double COMPLEX[2];
typedef COMPLEX *COMPLEX_ARRAY;
A simple change and it's immediately obvious whether or not it does what it says on the tin.
Of course if we're talking C++ here, the offending coder needs shooting.
xargon
February 27th, 2003, 03:22 AM
You would not believe it, the line comes from a C++ source file. Ex-C coders, I guess. It is crazy maintaining all this code though. Thank you so much guys for the explanations :) Really appreciate it.
Xargon
xargon
February 27th, 2003, 05:12 AM
Hi,
If I change the typedef to
typedef double COMPLEX[2];
typedef COMPLEX *COMPLEX_ARRAY;
How would I go about initializing a COMPLEX_ARRAY. Here is what I do:
COMPLEX_ARRAY comp = new double[2 * length];
But when I do this, the compiler gices errors:
for (size_t i = 0; i < length; i++)
{
comp[i][0] = someVar;
comp[i][1] = 0;
}
Compiler throws the following errors:
error C2109: subscript requires array or pointer type
C2106: '=' : left operand must be l-value
Any idea on what I might be doing wrong?
Thanks,
Xargon
xargon
February 27th, 2003, 05:28 AM
Never mind the previous post. I am STUPID! :D
Xargon
Graham
February 27th, 2003, 05:52 AM
Given that this is C++, the best definition would be:
typedef std::vector<std::complex> complex_array;
Do it the C++ way, not as "C with objects".
xargon
February 27th, 2003, 05:57 AM
I know!
However, this is for code maintainance. We are taking small steps at a time. I would like to see everything converted to STL containers and objects in the next few months. I hate going through C code. It is really unnerving.
Thanks for your reply :)
Xargon
dude_1967
February 27th, 2003, 08:27 AM
and I mean a mental complex.
Indeed, I was a bit unsure of this typedef.
Graham, I think your two typedef's should do the trick. Upon reading the post, it seems like the original code authors wanted to define some type for an array of complex numbers. It looks like it should be possible to maintain the original C-style character of the legacy code using the typedef's suggested by Graham.
This has been worked into a second example below.
Chris.
:)
#include <iostream>
#include <iomanip>
typedef double COMPLEX[2];
typedef COMPLEX* COMPLEX_ARRAY;
int main(int argc, char* argv[])
{
COMPLEX_ARRAY ca = new COMPLEX[10];
int i;
for(i = 0; i < 10; i++)
{
ca[i][0] = static_cast<double>(i);
ca[i][1] = 1.5 * i;
}
for(i = 0; i < 10; i++)
{
std::cout << std::fixed
<< std::setprecision(15)
<< ca[i][0]
<< ", "
<< ca[i][1]
<< std::endl;
}
delete [] ca;
return 1;
}
xargon
February 27th, 2003, 08:40 AM
Yeah, I got it to work with Graham's typedef :) Kudos to him.
The sad part is that it is part of a C++ file :(
I cannot believe people still code like that.
Xargon
xargon
February 27th, 2003, 08:43 AM
Check out the memory allocation in the old code:
COMPLEX_ARRAY someArr = NULL;
someArr = new double[2 * length];
where it could be someArr = new COMPLEX[length] as you guys pointed out.
2 for two doubles for the array. Makes the whole thing soooooo confusing! So, you have "magical" numbers all over the place.
Xargon.
Graham
February 27th, 2003, 09:08 AM
xargon: I sympathise with your position. I look back on the amount of dreadful code I've had to maintain and think about the frustration of not being able to just do it properly.
The key thing to learn here, I think, is the importance of clarity, even if that means more typing (longer identifiers that explain what the object is, two simple typedefs rather than one obscure one).
xargon
February 27th, 2003, 09:22 AM
Yeah, I guess it is the problem with discipline and habit. I am assuming the previous guy was a hard-core C programmer and just used C style code wrapped inside classes.
Anyways, we have a new project starting soon and I will get a chance to work on something new. Really looking forward to that.
Xargon
Paul McKenzie
February 27th, 2003, 11:07 AM
Originally posted by xargon
Yeah, I guess it is the problem with discipline and habit. I am assuming the previous guy was a hard-core C programmer and just used C style code wrapped inside classes.Ugh.
In many organizations, this would lead to a reprimand by the project leader, and in the extreme case, termination of employment.
Personally, I would have a fit if he/she had <complex> available and proceeded to code their own complex number library. Hopefully the person was willing to learn proper C++ techniques later on. However, there are some who never want to learn proper C++ techniques and will take the path of least resistance, and that is to resort to what they feel comfortable with -- 'C' style coding. Many times they do this without knowing that the code they are writing is not necessary, hard(er) to maintain, and in a lot of cases, just plain old invalid i.e. not guaranteed to work with respect to the rules of ANSI C++.
Regards,
Paul McKenzie
xargon
February 28th, 2003, 04:23 AM
Yup Paul, you got it. Well, the guy is not working here anymore. I am guessing they got fed up with him after complaints from fellow programmers.
Xargon
codeguru.com
Copyright Internet.com Inc., All Rights Reserved.