problem in using [ ] operator

[Bangalore]

Hi all,
I have a problem in accessing elements using overloaded operator [].
Consider,
const int SIZE=10;
int FALSE=0;
class Array
{
private:
int x[SIZE];
public:
//overloading []
int& operator [] (int index)
{
if ( index < 10 )
return x;
else
return FALSE;
}
};

class Base
{
private:
int i;
Array *p[2];
public:
Base ()//Here how to initiaze pointer with initialization
list
{
for(i=0; i<SIZE; i++)
//here how to assign value to array x{SIZE] in
class Array
}

void Display()
{
for(i=0; i<SIZE; i++)
//here also how show value
}
};
int main()
{
Base b;
b.Display();
}



I can directly use x[SIZE] in class Base, but with this object size of
Base will
increase drastically if the value of SIZE takes higher value , so I
want to keep size of Base as minimum as possible.

Plz , clarify me with your suggestions,
Thanks in advance
Bangalore

 

[peter.koch.larsen]

Hi all,
I have a problem in accessing elements using overloaded operator [].
Consider,
const int SIZE=10;
int FALSE=0;

Do not use UPPERCASE for constants. UPPERCASE should be use for macroes
only.

class Array
{
private:
int x[SIZE];
public:
//overloading []
int& operator [] (int index)
{
if ( index < 10 )
return x;
else
return FALSE;
}

The compiler is happy with this, I'm not. If you discover an error, you
should normally throw. This is your only option here (except for using
a global variable for passing error-information).

};

class Base
{
private:
int i;
Array *p[2];
public:
Base ()//Here how to initiaze pointer with initialization

You most certainly should not use a pointer here. Probably you meant
Array p[2]?
Also there is no parameter to Base so im uncertain as to what you mean
with "initialization".

list
{
for(i=0; i<SIZE; i++)
//here how to assign value to array x{SIZE] in
class Array
}

void Display()
{
for(i=0; i<SIZE; i++)
//here also how show value
}
};
int main()
{
Base b;
b.Display();
}



I can directly use x[SIZE] in class Base, but with this object size of
Base will
increase drastically if the value of SIZE takes higher value , so I
want to keep size of Base as minimum as possible.

If you want Base to hold a variable number of Array-memberts, I would
recommend that you use std::vector.

Plz , clarify me with your suggestions,
Thanks in advance
Bangalore

/Peter

 

[lokki]

class Array

{
private:
int x[SIZE];
public:
//overloading []
int& operator [] (int index)
{
if ( index < 10 )
return x;
else
return FALSE;
}

Shouldn't be there:
if (index < SIZE )
return x[index];
else
return FALSE;

 

[Thomas Tutone]

Do not use UPPERCASE for constants. UPPERCASE should be use for macroes
only.

This is just a style issue, and many experts would not agree that one should
always follow your rule. For example, in Item 17 of C++ Coding Standards,
Sutter and Alexandrescu use UPPERCASE for namespace-level constants - as the
OP's are.

Best regards,

Tom

 

[peter.koch.larsen]

class Array
{
private:
int x[SIZE];
public:
//overloading []
int& operator [] (int index)
{
if ( index < 10 )
return x;
else
return FALSE;
}

Shouldn't be there:
if (index < SIZE )
return x[index];
else
return FALSE;

Surely you should prefer the use of symbolic names, but that is not the
worst problem here.

/Peter

 

[Bangalore]

Peter thanks for your suggestions,

There is no wrong with Array *p[2] , here I want to declare array of
two class pointers. I made it array because in Base class this
(Array *p[2]) takes only 4 bytes regardless of array size( x[SIZE}
) in Array class.


If it is Array p[2], the size of two objects of class Array will be
added to
the size of Base , which I don't want.

And about constructor "Base()",
Since I am declaring array of two pointers to Array class, I think
these needs
to be initialized using initialization list. I don't know how to
initialize these pointers with initialization list.

overloaded [] operator, which I had given in the source code works
well for the reference object for class Array, but not for array of
pointer to class. I don't know how to implement this ,for array
of pointers.

Plz clarify me.
Thanks,
Bangalore

 

[peter.koch.larsen]

This is just a style issue, and many experts would not agree that one should
always follow your rule. For example, in Item 17 of C++ Coding Standards,
Sutter and Alexandrescu use UPPERCASE for namespace-level constants - as the
OP's are.

This is a purely subjective matter, but I'm positive that there are not
many experts that in general will disagree with me. I don't have
Sutters and Alexandrescus book here, but even if they disagree (which I
doubt), I'm positive that I will still have the majority of experts on
my side.

Kind regards
Peter

 

[Bangalore]

one correction , Array *p[2] , takes 8 bytes
Thanks,
Bangalore

 

[Karl Heinz Buchegger]

[snip]

I am still not sure what all of this should eventually lead to.
So may I ask: What is your real problem?
Don't show us what you think the solution to your problem is and what
problems you have with that solution. What is your first hand problem
that you try to solve with that code?


And yes: I think Peter is still right: Whatever your problem might
be, std::vector most likely would be a solution to it.

 

[peter.koch.larsen]

Peter thanks for your suggestions,

There is no wrong with Array *p[2] , here I want to declare array of
two class pointers. I made it array because in Base class this
(Array *p[2]) takes only 4 bytes regardless of array size( x[SIZE}
) in Array class.

It is unclear how many Array-elements, you might want to store in a
Base. If it is one or two, I do understand you might prefer not to use
the vector, but i still recommend that class. It probably only takes up
twelve bytes on your implementation and this is comparable to what you
use now.
If you always want two Array-objects, the best thing to do is to have
them in Base by value. This gives you the easiest code to manage.
Your idea with pointers is - simply put - difficult to implement and
you are IMHO not qualified to implement that solution yet. I sense you
are learning C++ now, and the best thing you can do is to use the
standard library whenever you can.

If it is Array p[2], the size of two objects of class Array will be
added to
the size of Base , which I don't want.

And about constructor "Base()",
Since I am declaring array of two pointers to Array class, I think
these needs
to be initialized using initialization list. I don't know how to
initialize these pointers with initialization list.

You can't initialise an array in a constructor. You need to do p[0] =
0; p[1] = 0; (or something smarter such as std::fill).

overloaded [] operator, which I had given in the source code works
well for the reference object for class Array, but not for array of
pointer to class. I don't know how to implement this ,for array
of pointers.

It does not work well. Array[47] returns a perfectly fine int and I bet
that is not what the class should do. You can even do Array[47] = 10;
Array[48] = 11;. Guess what the value of Array[47] is now.

Plz clarify me.
Thanks,
Bangalore

/Peter

 

[Thomas Tutone]

This is a purely subjective matter, but I'm positive that there are not
many experts that in general will disagree with me. I don't have
Sutters and Alexandrescus book here, but even if they disagree (which I
doubt), I'm positive that I will still have the majority of experts on
my side.

Ummm... OK, I'll bite. Please cite some experts who state "one should
use uppercase only for macros, and not for global constants." Since
I've already cited two experts who in fact on occasion use uppercase
for global constants - and in a book that's less than a year old -
you're going to need to come up at least three to have any chance at a
"majority."

My point was simply that you presented as an objective truth something
that, as you now state, is purely subjective.

Cheers!

Tom

 

[peter.koch.larsen]

Thomas Tutone skrev:

Ummm... OK, I'll bite. Please cite some experts who state "one should
use uppercase only for macros, and not for global constants." Since
I've already cited two experts who in fact on occasion use uppercase
for global constants - and in a book that's less than a year old -
you're going to need to come up at least three to have any chance at a
"majority."

My point was simply that you presented as an objective truth something
that, as you now state, is purely subjective.

Surely this is a subjective matter as there's nothing in the C++
standard that mandates that this should be so. Still I believe to be in
very good company. If you look at Item 16 in C++ Coding Standards,
you'll notice this advice:
"... always give them [macroes] SCREAMING_UPPERCASE_AND_UGLY names" and
"never ever even consider starting to think about writing a macro that
is a common word or abbreviation"." While they do not directly state
that non-macroes shouldn't be all uppercase, it is clearly the
intention that the naming convention is made to avoid nameclashes with
nonmacroes. As for item 17, I could imagine that the example is a
header where #defines have been changed to consts and thus the original
names have been preserved.
Apart from that I believe to have lots of respected folks who share my
opinion - a quick Google-search on comp.lang.c++ gave me names such as
Alf Steinberg, Rolf Magnus, Paul Mensonides and Rob Williscroft. Never
ever have I seen advice to have non-macro names in all-upppercase.

Cheers!

Tom

/Peter

 

[Squeamizh]

Never ever have I seen advice to have non-macro names in all-upppercase.

You're kidding me.

 

[Rui Maciel]

This is a purely subjective matter, but I'm positive that there are not
many experts that in general will disagree with me. I don't have
Sutters and Alexandrescus book here, but even if they disagree (which I
doubt), I'm positive that I will still have the majority of experts on
my side.

The existence of an hypotetical swarm of experts claiming that uppercase
names are evil is of absolutely no value to this suject. This
pseudo-problem does not have it's base on technical issues. It is a matter
of code style and personal taste and until proven otherwise (a simple "I
don't know where but there are tons of experts that agree with me" doesn't
cut it) this isn't a problem at all.


Best regards
Rui Maciel

 

[Alf P. Steinbach]

* Rui Maciel:

* Peter Koch Larsen:


The existence of an hypotetical swarm of experts claiming that uppercase
names are evil is of absolutely no value to this suject. This
pseudo-problem does not have it's base on technical issues.

It is in fact a real problem, or set of problems, and the original problem is
in fact a problem rooted in a clear technical issue, namely that macros are
simple text substitutions that don't respect namespaces or scopes, or type
rules. A secondary, derived problem is that Java adopted the C naming
convention for constants, where, since C didn't have typed constants, that was
the convention for macros. One aspect of this derived problem is that it
makes it difficult to have one common coding standard for a multi-language
project, and another aspect is that Java programmers who migrate to C++ keep
their conventions that worked well in Java, but just wreak havoc in C++.

Anyway, I think you should listen to the experts also in matters of judgement.
If you don't agree after having considered their advice & opinions, then that
might bring the state of knowledge one bit further. But first consider.

E.g., check out <url: http://www.research.att.com/~bs/bs_faq2.html#macro>,
where "bs" does not stand for an 8-letter word but for "Bjarne Stroustrup".

Or you might check the macro names in e.g. the C++ FAQ.

Curiously this issue isn't explicitly discussed in the FAQ, AFAICS, but the
naming convention adopted speaks for itself, as well as tidbits such item 33.5
having been updated in the 12/02 release, "renamed the macro to all-caps",
which presumably wouldn't have been done if it didn't matter.

It is a matter
of code style and personal taste and until proven otherwise

Consider it proven otherwise (see above). ;-)

 

[Jim Langston]

* Rui Maciel:

It is in fact a real problem, or set of problems, and the original problem
is
in fact a problem rooted in a clear technical issue, namely that macros
are
simple text substitutions that don't respect namespaces or scopes, or type
rules. A secondary, derived problem is that Java adopted the C naming
convention for constants, where, since C didn't have typed constants, that
was
the convention for macros. One aspect of this derived problem is that it
makes it difficult to have one common coding standard for a multi-language
project, and another aspect is that Java programmers who migrate to C++
keep
their conventions that worked well in Java, but just wreak havoc in C++.

Anyway, I think you should listen to the experts also in matters of
judgement.
If you don't agree after having considered their advice & opinions, then
that
might bring the state of knowledge one bit further. But first consider.

E.g., check out <url: http://www.research.att.com/~bs/bs_faq2.html#macro>,
where "bs" does not stand for an 8-letter word but for "Bjarne
Stroustrup".

Or you might check the macro names in e.g. the C++ FAQ.

Curiously this issue isn't explicitly discussed in the FAQ, AFAICS, but
the
naming convention adopted speaks for itself, as well as tidbits such item
33.5
having been updated in the 12/02 release, "renamed the macro to all-caps",
which presumably wouldn't have been done if it didn't matter.



Consider it proven otherwise (see above). ;-)

Umm... "Conventions such as having macros (and only macros) in ALLCAPS
helps, but there is no language-level protection against macros." is proof?
No where does that line say it should be done. Nor does it even suggest it.
It just says "helps".

Personally I tend to make all Global variables (macro or not) all caps
because I hate all caps and it gives me more incentive to find some better
way to do it as soon as I can.

But it also lets me know that if I see something in all caps the scope is
greater than the current function/method and I better be careful with it.

 

[Alf P. Steinbach]

* Jim Langston, quoting Bjarne Stroustrup's C++ FAQ:

Umm... "Conventions such as having macros (and only macros) in ALLCAPS
helps, but there is no language-level protection against macros." is proof?
No where does that line say it should be done. Nor does it even suggest it.

If you don't count that as even a suggestion, then you have what I consider a
very odd notion of what constitutes a suggestion.

Personally I tend to make all Global variables (macro or not) all caps
because I hate all caps and it gives me more incentive to find some better
way to do it as soon as I can.

How about finding a convention that is not all caps and that you hate just as
much or more? Try e.g. "g_l_o_b_a_l_" as a prefix. That will really hurt (I
hope), and then really expedite the get-rid-of-em response, and also lower the
probability of name collision with macros: it's win win all the way.

But it also lets me know that if I see something in all caps the scope is
greater than the current function/method and I better be careful with it.

If it isn't all caps, then it isn't global, hence the scope isn't greater than
the current function, and hence more careless programming is indicated, which
is good. Hum. I'm not sure I followed that, but if it works, by all means.

 

[peter.koch.larsen]

Rui Maciel skrev:

The existence of an hypotetical swarm of experts claiming that uppercase
names are evil is of absolutely no value to this suject. This
pseudo-problem does not have it's base on technical issues. It is a matter
of code style and personal taste and until proven otherwise (a simple "I
don't know where but there are tons of experts that agree with me" doesn't
cut it) this isn't a problem at all.

First of all, this is not a pseudo-problem. Anyone who has tried using
std::max or std::min while including windows know that.
For the technical merit, the advantage of adhering to the convention of
using only all-caps for macroes manifests itself as the consequence of
this is that macroes then will not interfere with any language parts.
The only interference is between competing macroes.

Best regards
Rui Maciel
--

/Peter

 

[Bangalore]

I am still not sure what all of this should eventually lead to.
So may I ask: What is your real problem?
Don't show us what you think the solution to your problem is and what
problems you have with that solution. What is your first hand problem
that you try to solve with that code?

Actually I am facing this problem in my project, Here if at all ,I
include those array elements in my Base class ,size of the base class
will increase,this leads to change in architecture of that object , If
I change that object, it has a huge impact on my code.

With rererence vaibles , there is code snippet
--------- Before slipt: -----------
class B
{
public:
B(){};
A a;
}

++++++++ After split +++

#include<iostream.h>

class A
{
public:
A():i(9){};
int i; //I want to declare int i[10] as private, for data
hiding purpose
};

class B
{
public:
B():a(*(new A())){};
A& a; //Desperately I want to use array of two pointers
};

main()
{
B b;
cout << b.a.i;
}
)

{

B b;

cout << b.a.i;

}




And yes: I think Peter is still right: Whatever your problem might
be, std::vector most likely would be a solution to it.

I don't want to use vectors here.

 

[Bangalore]

Bangalorewrote
I am still not sure what all of this should eventually lead to

So may I ask: What is your real problem
Don't show us what you think the solution to your problem is an wha
problems you have with that solution. What is your first han proble
that you try to solve with that code

Actually I am facing this problem in my project, Here if at all ,

include those array elements in my Base class ,size of the base clas
will increase,this leads to change in architecture of that object , I
I change that object, it has a huge impact on my code

With rererence vaibles , there is code snippe
--------- Before slipt: ----------
class

public
B(){}
A a


++++++++ After split ++

#include<iostream.h

class

public
A():i(9){}
int i; //I want to declare int i[10] as private, for dat hiding purpos
}

class

public
B():a(*(new A())){}
A& a; //Desperately I want to use array of two pointer
}

main(

B b
cout << b.a.i





B b

cout << b.a.i






And yes: I think Peter is still right: Whatever your problem migh
be, std::vector most likely would be a solution to it

I don't want to use vectors here