In general data structure and especially C++ OOP, data encapsulation is essential. Otherwise, consider a structure.
Kuphryn
Printable View
In general data structure and especially C++ OOP, data encapsulation is essential. Otherwise, consider a structure.
Kuphryn
If all we are doing is setting up an array of constant struct-like objects, I think my solution is better.Quote:
So which one is more elegant?
It is scalable and keeps your code clean. You always have to have a source for your consts, but if it is large, move it to some data file. The OS will have to map your data in if you don't, so there will be no real performance hit doing it yourself explicitly (maybe one extra page or something). Of course, it would be best to wrap up the type conversion in a typesafe manner for large projects, etc. but that would be normal c++ design standards.Code:// load data file to pSomewhere
A *myAArray;
myAArray = pSomewhere;
Peace all.
Mai, I made the numbers up. In fact, I enclosed that wholeQuote:
Originally posted by AnthonyMai
Where did you get the 0.33% and 1.8% figure? Are you sure it is not 0.1%, or more, or less?
So which one is more elegant? Is it JUST 0.33% faster and takes 1.8% less memory?
portion of my sentence in double quotes to indicate that it
was not a definite thing, but rather a concept:
[QUOTE]
So, this approach is not generically elegant, but it's elegant in
the "specific-tailored my solution performs 0.33% faster than
yours and consumes 1.8% less memory" line of thought.
[/QUOTE
Whether you see this now or not is irrelevant. It's already
obvious that your solution will be faster; is it BETTER though?
Should your changes be made everywhere? Should they even be
made to a class that is this simple? I'd argue no. Unless you
really need every bit of performance, I wouldn't bother with
what you suggest.
Like I said earlier, you can quibble with ridiculous semantics all
you want, but you'll never admit to the fact that your solution
simply isn't suitable for large-scale reuse. Fine, your solution
might have some use in some limited circumstances, but it's
certainly not for the vast majority of cases.
The thing that kills me is that you had the audacity to lambast
the responses of others for not being "straight" [which you define
differently than any other english-speaker].
--Paul
For the records:
I compiled following code under VC++6.0, release mode, optimized for maximum speed, debug information enabled.
The loop is there only to simulate a non-trivial program - or else the compiler would have optimized out both A_array and B_array. The disassembly is this:Code:#include <iostream>
class A
{
public:
int x;
int y;
public:
A(int a, int b):x(a),y(b){}
void init(int a, int b){x=a;y=b;}
void show() const {printf("%d %d\r\n", x, y);}
};
class B
{
public:
int x;
int y;
public:
void init(int a, int b){x=a;y=b;}
void show() const {printf("%d %d\r\n", x, y);}
};
int main(int argc, char* argv[])
{
int i;
A A_array[5] = {A(1,1),A(2,2),A(3,3),A(4,4),A(5,5)};
B B_array[5] = {{1,1},{2,2},{3,3},{4,4},{5,5}};
for(i=0; i<5; i++){
std::cout<<A_array[i].x+B_array[i].y<<std::endl;
}
return 0;
}
I think I don't have to comment on this any further.Code:24: int main(int argc, char* argv[])
25: {
00401000 sub esp,50h
00401003 push ebp
00401004 push esi
00401005 push edi
26: int i;
27: A A_array[5] = {A(1,1),A(2,2),A(3,3),A(4,4),A(5,5)};
00401006 mov esi,1
0040100B mov edx,2
00401010 mov ecx,3
00401015 mov edi,4
0040101A mov eax,5
0040101F mov dword ptr [esp+34h],esi
00401023 mov dword ptr [esp+38h],esi
00401027 mov dword ptr [esp+3Ch],edx
0040102B mov dword ptr [esp+40h],edx
0040102F mov dword ptr [esp+44h],ecx
00401033 mov dword ptr [esp+48h],ecx
00401037 mov dword ptr [esp+4Ch],edi
0040103B mov dword ptr [esp+50h],edi
0040103F mov dword ptr [esp+54h],eax
00401043 mov dword ptr [esp+58h],eax
28: B B_array[5] = {{1,1},{2,2},{3,3},{4,4},{5,5}};
00401047 mov dword ptr [esp+0Ch],esi
0040104B mov dword ptr [esp+10h],esi
0040104F mov dword ptr [esp+14h],edx
00401053 mov dword ptr [esp+18h],edx
00401057 mov dword ptr [esp+1Ch],ecx
0040105B mov dword ptr [esp+20h],ecx
0040105F mov dword ptr [esp+24h],edi
00401063 mov dword ptr [esp+28h],edi
00401067 mov dword ptr [esp+2Ch],eax
0040106B mov dword ptr [esp+30h],eax
29: for(i=0; i<5; i++){
0040106F xor ebp,ebp
30: std::cout<<A_array[i].x+B_array[i].y<<std::endl;
...........
Well, looks like another faux pas by Mai.
This and other threads reminds me of those old Road Runner / Wile E. Coyote cartoons where the Coyote (a self-proclaimed "super genius") tries to catch the Road Runner with all sorts of inventions, gadgets, contraptions, etc. He never catches the Road Runner, instead all of the inventions and gadgets backfire on the Coyote.
Just a thought.
Regards,
Paul McKenzie
The truth of the record is, we are talking about objects initialize using CONSTANTS and objects that is meants to provide access to those constant numbers so they stay constant once initialize.Quote:
For the records:
I compiled following code under VC++6.0, release mode, optimized for maximum speed, debug information enabled.
Code://..
int main(int argc, char* argv[])
{
int i;
A A_array[5] = {A(1,1),A(2,2),A(3,3),A(4,4),A(5,5)};
B B_array[5] = {{1,1},{2,2},{3,3},{4,4},{5,5}};
//...
Such objects should be put in the heap memory. That means they should NOT be declared as local variables that sit in the stack. They should be declared as either globals or static variables within functions. Declaring them as regular variables within the function scope forces them to be put on the stack and forces them to be initialized again and again for each iteration of function calls.
[Yves : removed useless bit
Antony, you read my warning, so apply it]
Anthony,
Whether or not the variables are supposed to be constants or statics or whatever has not been specified by the OP, so let's not assume that.
And by the way, when you define a global constant, it doesn't get put into the heap ;)
May I suggest to close this thread at this point. This discussion most-likely does not have much to do with the original question but rather turned into a religious and to my mind senseless discussion like it happens with most of the threads one specific guy is involved.
The answer(s) were given a long time ago and I really do not see any need to go on with this thread since there will never be a reasonable agreement on this topic.
I am not ASSUMING that. I am giving advice that under such circumstance it is best to declare a constant global array or at least make it static within the function, unless the OP has some specific reasons not to. And I have not see any one presenting a reason not to.Quote:
Whether or not the variables are supposed to be constants or statics or whatever has not been specified by the OP, so let's not assume that.
It does when you are talking about global constant arrays. If it is just a const int, double or char, the compiler may just compile it in place instead of allocating storage for the variable in the heap. But when it is an array, the compiler would rather prefer to leave it in the heap, instead of compile them directly in place.Quote:
And by the way, when you define a global constant, it doesn't get put into the heap
Fine, it wasn't clear to me that this was a suggestion ;)Quote:
Originally posted by AnthonyMai
I am not ASSUMING that. I am giving advice that under such circumstance it is best to declare a constant global array or at least make it static within the function, unless the OP has some specific reasons not to. And I have not see any one presenting a reason not to.
And different compilers might handle different cases differently ;)Quote:
It does when you are talking about global constant arrays. If it is just a const int, double or char, the compiler may just compile it in place instead of allocating storage for the variable in the heap. But when it is an array, the compiler would rather prefer to leave it in the heap, instead of compile them directly in place.