How can I declare a array as bool slice[x][y][z];
I want declare this in a class member.
Thanks.

Thunder wrote:

How can I declare a array as bool slice[x][y][z];
I want declare this in a class member.
Thanks.

What are x,y,z? Give some detail as to what you want to do. Have you
tried something? What problems did you have? Is this supposed to be a
dynamic array?



Brian

Thunder wrote:

How can I declare a array as bool slice[x][y][z];
I want declare this in a class member.

So, what's the problem with just declaring it as 'bool slice[x][y][z]'?

--
Best regards,
Andrey Tarasevich

Default User ha scritto:

Thunder wrote:
>

>
>
What are x,y,z? Give some detail as to what you want to do. Have you
tried something? What problems did you have? Is this supposed to be a
dynamic array?

x,y,z are parameters of function member.Yes It's a dynamic array.

I want to do something as this.
void func()
{
int sx=....
int sy=....
int sz=....
slice=new [sx] [sy] [sz];
}

My problem is the following I don't know as I should declare array
slice in member class,
and I don't know as allocate memory for this array.

Thunder wrote:

>
Default User ha scritto:
>

>
>
x,y,z are parameters of function member.Yes It's a dynamic array.
>
I want to do something as this.
void func()
{
int sx=....
int sy=....
int sz=....
slice=new [sx] [sy] [sz];
}

Well, you can't do that. See the FAQs:

<http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.16>

You could do it like this:

int ***slice;

slice = new int**[sx];

for(int i = 0; i < sx; i++)
{
slice[i] = new int*[sy];
for(int j = 0; j < sy; j++)
slice[i][j] = new int[sz];
}

I recommend nesting std::vectors. Easier and less prone to problems.
I'd also look hard at the design that requires a three-dimensional
array.

My problem is the following I don't know as I should declare array
slice in member class,

That's not your problem, it's a design decision, but won't affect how
things are declared and defined.

and I don't know as allocate memory for this array.

That's your big problem. Figure that out first, then figure out where
it goes.




Brian

Default User wrote in message ...

>Thunder wrote:

>
>Well, you can't do that. See the FAQs:
><http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.16>
>
>You could do it like this:
>
>int ***slice = new int**[sx];
>for(int i = 0; i < sx; i++){
slice[i] = new int*[sy];
for(int j = 0; j < sy; j++)
slice[i][j] = new int[sz];
}
>
>I recommend nesting std::vectors. Easier and less prone to problems.
>I'd also look hard at the design that requires a three-dimensional
>array.

Another idea:

{
cout<<"\n --- VecBit test ---"<<std::endl;
size_t const bits(3);
std::vector< std::bitset<bits VecBit( 7, 4 ); // 3x7 init to 4

VecBit.at(0)[0] = true;
VecBit.at(1)[1] = true;
VecBit.at(2) = 5;
VecBit.at(3) = 7;
VecBit.at(4) >>= 1;
std::bitset<bitsmore;
VecBit.push_back( more ); // add more
for(size_t i(0); i < VecBit.size(); ++i){
cout<<"VecBit.at("<<i<<")="<< VecBit.at(i) <<std::endl;
} //for(i)
size_t x(2), y(1), z(0);
if( VecBit.at(2)[y] ){ // if( VecBit.at(2).at(1) ) // no .at() for bitset
cout<<"true"<<std::endl;
}
else{
cout<<"false"<<std::endl;
}
cout<<" x="<<std::boolalpha<<VecBit.at(2)[x]
<<" z="<<VecBit.at(2)[z]<<std::endl;
cout<<" --- VecBit test ---end\n"<<std::endl;
}
/* --- VecBit test ---
VecBit.at(0)=101
VecBit.at(1)=110
VecBit.at(2)=101
VecBit.at(3)=111
VecBit.at(4)=010
VecBit.at(5)=100
VecBit.at(6)=100
VecBit.at(7)=000
false
x=true z=true
--- VecBit test ---end
*/

--
Bob R
POVrookie

Thunder:

How can I declare a array as bool slice[x][y][z];

I've seen elsethread that you're talking about dynamic allocation. You
could try something like the following:

#include <cstddef>

template<class ArrElemT>
class Arr3D {
private:

typedef std::size_t size_t;

size_t const s1,s2;

ArrElemT *const p;

public:

Arr3D(size_t const a,size_t const b,size_t const c)
: s1(b*c),s2(c),p(new ArrElemT[a*b*c]) {}

~Arr3D() { delete [] p; }

ArrElemT &GetElem(size_t const a,size_t const b,
size_t const c)
{
return *(p + a*s1 + b*s2 + c);
}
};


#include <iostream>
#include <cstdlib>

int main()
{
std::size_t x,y,z;

std::cin >x >y >z;

if (x<5 || y<5 || z<5) return EXIT_FAILURE;

Arr3D<doubleobj(x,y,z);

obj.GetElem(4,4,4) = 89.234;
}

--

Frederick Gotham

Frederick Gotham:

Arr3D(size_t const a,size_t const b,size_t const c)
: s1(b*c),s2(c),p(new ArrElemT[a*b*c]) {}

That would be better as:

new ArrElemT{a*s1)

--

Frederick Gotham

Frederick Gotham:

new ArrElemT{a*s1)

(, not {.

--

Frederick Gotham

Frederick Gotham wrote:

Thunder:
>

>
I've seen elsethread that you're talking about dynamic allocation. You
could try something like the following:
>
#include <cstddef>
>
template<class ArrElemT>
class Arr3D {
private:
>
typedef std::size_t size_t;
>
size_t const s1,s2;
>
ArrElemT *const p;
>
public:
>
Arr3D(size_t const a,size_t const b,size_t const c)
: s1(b*c),s2(c),p(new ArrElemT[a*b*c]) {}
>
~Arr3D() { delete [] p; }
>
ArrElemT &GetElem(size_t const a,size_t const b,
size_t const c)
{
return *(p + a*s1 + b*s2 + c);
}
};

A copy constructor and assignment operator are also needed, or it those
operations need to be disabled.

Gavin Deane

Frederick Gotham wrote:

Frederick Gotham:
>
>

>
>
That would be better as:
>
new ArrElemT{a*s1)

I think it is clearer as you had it originally.

Gavin Deane

Frederick Gotham wrote:

>

>
>
(, not {.
...

That way you'd make your code to depend critically on the order of class
data member declaration. If someone accidentally (or intentionally)
changed the order to

...
ArrElemT *const p;
size_t const s1,s2;
...

the initialization would fail. That's one thing to remember about
initialization lists.

--
Best regards,
Andrey Tarasevich

Gavin Deane:

>
I think it is clearer as you had it originally.

Yes, I would agree that it is clearer, but efficiency takes precedence for me
99% of the time (i.e. the code only evaluates "b*c" once rather than twice).

--

Frederick Gotham

Andrey Tarasevich:

That way you'd make your code to depend critically on the order of class
data member declaration. If someone accidentally (or intentionally)
changed the order to
>
...
ArrElemT *const p;
size_t const s1,s2;
...
>
the initialization would fail. That's one thing to remember about
initialization lists.

I remember one time a few years back, I was writing some C++ code. I think I
changed compiler, or maybe simply upgraded compiler, but when I re-compiled
my program after the install, I got a new warning telling me that the
initialisation list order didn't match the declaration order. This was the
first I had heard of it! My intuition at the time made me assume that they're
initialised in order of their appearance in the initialisation list.

Which begs the question...

Why is it determined by declaration order rather than initialition list
order? The latter would seem to make _a lot_ more sense.

--

Frederick Gotham

Frederick Gotham wrote:

Why is it determined by declaration order rather than initialition list
order? The latter would seem to make _a lot_ more sense.

Does a class require a constructor? - No
Does a class require a definition? - Yes
Need a member be initialised in the member initialiser list? - No
Need a member be defined to be a member? - Yes.

I suppose there are more reasons, but the above seems to be reasons for
me. I do agree that a good compiler can (perhaps should) warn about
this, especially when there is some form of interdependence.

Another thing to consider is, is it right to provide weak associations
at construction time, or should the be realized after construction? Any
thoughts on this?

My thoughts are, requiring weak associates to exist at construction
time imposes more restrictions on the client. Usually (IME) the setting
of weak associations do not involve the possibility of exceptions. I do
not see why they have to be specified in the member initialiser list.
Giving the client an option is always good, but that could involve
writing many constructors. Ownership, of course is another matter.

Regards,

Werner

Frederick Gotham wrote:

...
Why is it determined by declaration order rather than initialition list
order? The latter would seem to make _a lot_ more sense.
...

There is an important rule strictly followed in most of C++: objects
must be destructed in the order that is reverse of the order of their
construction. This rule applies to class subobjects as well.

If C++ allowed "custom" subobject construction order (determined by
constructor initialization list, for example), compilers would have to
memorize that order at run-time for each object somehow, and then use it
later in each object's destructor in order to satisfy the
reverse-order-destruction requirement. That would take certain amount of
additional housekeeping data in each object and more complicated
housekeeping code in constructors and destructors. In order to avoid all
these extra expenses the order of construction (and destruction) was
made pre-determined at compile-time by the order of subobject declaration.

--
Best regards,
Andrey Tarasevich

Frederick Gotham wrote:

Gavin Deane:
>

>
>
Yes, I would agree that it is clearer, but efficiency takes precedence for me
99% of the time (i.e. the code only evaluates "b*c" once rather than twice).

Fair enough. That's up to you. There is also Andrey Tarasevich's point
that your constructor becomes critically reliant on the order of member
object declarations not changing.

For the benefit of the OP, if you are programming in a collaborative
environment (ie working with other programmers on the same project),
professionally or otherwise, your fellow programmers will not, in
general, thank you for sacrificing readability in this kind of way.
Their ability to do their job (ie develop and maintain code without
introducing bugs) depends on their ability to read all the code they
are working on - theirs and yours. If you are programming on your own,
you can, of course, do whatever you like.

Gavin Deane

Andrey Tarasevich:

If C++ allowed "custom" subobject construction order (determined by
constructor initialization list, for example), compilers would have to
memorize that order at run-time for each object somehow, and then use it
later in each object's destructor in order to satisfy the
reverse-order-destruction requirement.

My first thought was: So why not just use the initialisation list order
rather than the declaration order, when it occurred to me: You can have
more than one constructor, and therefore more than one initialisation list,
and therefore more than one order in which to construct the sub-objects.

Am I right in thinking that this is the reason why they went with
declaration order?

Anyhow, I suppose we'll just have to do with comments:

class Whatever {
private:

/* Don't change the declaration order below! */
int a;
double b;
char *c;
/* Don't change the declaratino order above! */

};

--

Frederick Gotham

Gavin Deane:

For the benefit of the OP, if you are programming in a collaborative
environment (ie working with other programmers on the same project),
professionally or otherwise, your fellow programmers will not, in
general, thank you for sacrificing readability in this kind of way.

If they're that heart broken, we can give them comments:

new ArrElemT[a*s1] /* s1 == b*c */

--

Frederick Gotham

Frederick Gotham wrote:

Gavin Deane:
>

>
>
If they're that heart broken, we can give them comments:
>
new ArrElemT[a*s1] /* s1 == b*c */

Indeed. Whenever performance considerations require you to obfuscate
your code, the next best thing is documentation to clarify your reasons
and intent.

Gavin Deane

Gavin Deane:

Indeed. Whenever performance considerations require you to obfuscate
your code, the next best thing is documentation to clarify your reasons
and intent.

Agreed.

--

Frederick Gotham