* Re: Help you C++ Debuggers!
1997-01-20 0:00 ` Gautier
@ 1997-01-20 0:00 ` Tanmoy Bhattacharya
1997-01-21 0:00 ` David Emery
` (5 subsequent siblings)
6 siblings, 0 replies; 16+ messages in thread
From: Tanmoy Bhattacharya @ 1997-01-20 0:00 UTC (permalink / raw)
Gautier.DeMontmollin@maths.unine.ch (Gautier) writes:
> The C compilers are known to have problems with multi-dim arrays.
> Remember that C is near to a macro assembler (-> segmentation...)!
Huh? Which class of C compilers are you talking about? Most C
compilers I have seen have no problems at all with multi-dimensional
arrays. I thinik as a general statement what you are saying is
absolutely incorrect.
Some compilers can have bugs (though I have seen none with something
to do with declaration of multi-dimensional arrays), but to
characterize in general is highly improper: justifying it by its near
`macro assembler'-ness is ridiculous.
C does not support objects greater than 32767 bytes portably.
Cheers
Tanmoy
--
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003 voice: 1 (505) 665 4733 [ Home: 1 (505) 662 5596 ]
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Help you C++ Debuggers!
1997-01-20 0:00 ` Gautier
1997-01-20 0:00 ` Tanmoy Bhattacharya
@ 1997-01-21 0:00 ` David Emery
1997-01-21 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB
` (4 subsequent siblings)
6 siblings, 0 replies; 16+ messages in thread
From: David Emery @ 1997-01-21 0:00 UTC (permalink / raw)
>C does not support objects greater than 32767 bytes portably.
Huh? Where in the C Language Definition is this specified? Given the
limitations of Intel 80x86 16-bit architectures, I could understand
this being a possible limitation of poor PC C compilers. But I can't
see this as being a shortcoming of the C -language-.
As a programming language, C has lots of shortcomings, but this isn't
one (any) of them...
dave
--
Note: if email to me bounces, use 'emery@grebyn.com'
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Help you C++ Debuggers!
1997-01-20 0:00 ` Gautier
1997-01-20 0:00 ` Tanmoy Bhattacharya
1997-01-21 0:00 ` David Emery
@ 1997-01-21 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB
1997-01-21 0:00 ` Bradley A. Burns
1997-01-21 0:00 ` Chris Engebretson
` (3 subsequent siblings)
6 siblings, 1 reply; 16+ messages in thread
From: Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1997-01-21 0:00 UTC (permalink / raw)
In article <1997Jan20.144447.5581@news> Gautier.DeMontmollin@maths.unine.ch (Gautier) writes:
Macarthur Drake <drake@bme.ri.ccf.org> writes:
> I am in the mist of completing a major piece of code in C++. However I
> keep comming across a particularly difficult bug. Can you help?
>
> I am simply trying to declare a three D array:
>
>
> float objects[9000][10][10];
>
> However, sometimes while compiling I get a strange compilation error
> like one of the following:
>
> 1. segmentation violation
>
The C compilers are known to have problems with multi-dim arrays.
Remember that C is near to a macro assembler (-> segmentation...)!
Remedy:
You must use some pretty strange C compilers.....
1.
Make an 1-dim array and handle the 3 dims with multiplications
Download gcc if your C compiler is broken.
2.
Download a good Ada compiler... N.B.: your message was posted in
comp.lang.ada . Was it premonitory ? ;)-
Yes.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Help you C++ Debuggers!
1997-01-21 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB
@ 1997-01-21 0:00 ` Bradley A. Burns
0 siblings, 0 replies; 16+ messages in thread
From: Bradley A. Burns @ 1997-01-21 0:00 UTC (permalink / raw)
This type of data capsule in C++ would best be declared dynamically. Look
into the standard NEW and DELETE operators. You will need to use type
pointers but that's not a problem at all.
For example:
float* f_var = new float[9000];
This will dynamically allocate an array of 9000 floats. You access these by
using the standard array reference notation, for example:
float f_temp = f_var[1280];
// returns 1 float value at array index 1280.
// (actually 1279) since the index is 0 based.
...and remember, you can delete this singular array in one easy step:
delete[] f_var;
Now, all you have to do is apply it to a 3 dimensional array. By the way,
the way you are doing it below, with some (most?) C++ compilers, even the
smart ones, will reserve actual space in the .EXE file for 900,000 floats,
therefore making your application much larger than it has to be, both in
memory and on the hard disk. One other advantage of dynamic allocations is,
say your application has many different areas (modules?) and you only need
that large array of floats for one of those modules, you can perform a
delete[] when the user leaves that module to go into another one. This, of
course, is assuming that you're allocating these 900,000 locally (allocated
and used only within a specific function or class), but somehow I think
that this array is being allocated globally, for the entire application.
Hope this helps,
Brad.
Ole-Hjalmar Kristensen FOU.TD/DELAB <ohk@ultra.tfdt-o.nta.no> wrote in
article <OHK.97Jan21093610@ultra.tfdt-o.nta.no>...
> In article <1997Jan20.144447.5581@news>
Gautier.DeMontmollin@maths.unine.ch (Gautier) writes:
>
> Macarthur Drake <drake@bme.ri.ccf.org> writes:
> > I am in the mist of completing a major piece of code in C++. However
I
> > keep comming across a particularly difficult bug. Can you help?
> >
> > I am simply trying to declare a three D array:
> >
> >
> > float objects[9000][10][10];
> >
> > However, sometimes while compiling I get a strange compilation
error
> > like one of the following:
> >
> > 1. segmentation violation
> >
> The C compilers are known to have problems with multi-dim arrays.
> Remember that C is near to a macro assembler (-> segmentation...)!
> Remedy:
>
> You must use some pretty strange C compilers.....
>
> 1.
> Make an 1-dim array and handle the 3 dims with multiplications
>
> Download gcc if your C compiler is broken.
>
> 2.
> Download a good Ada compiler... N.B.: your message was posted in
> comp.lang.ada . Was it premonitory ? ;)-
>
> Yes.
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Help you C++ Debuggers!
1997-01-20 0:00 ` Gautier
` (2 preceding siblings ...)
1997-01-21 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB
@ 1997-01-21 0:00 ` Chris Engebretson
1997-01-21 0:00 ` Chris Engebretson
` (2 subsequent siblings)
6 siblings, 0 replies; 16+ messages in thread
From: Chris Engebretson @ 1997-01-21 0:00 UTC (permalink / raw)
David Emery wrote:
> >C does not support objects greater than 32767 bytes portably.
>
> Huh? Where in the C Language Definition is this specified?
Tanmoy's correct. The size of an object is measured by the sizeof
operator, which yields type size_t. More specifically, the
Standard defines size_t (in <stddef.h>) to be a constant of
unsigned integral type. Beyond that, the Standard also says:
2.2.4.1 Translation limits
The implementation shall be able to translate and execute at least
one program that contains at least one instance of every one of the
following limits:
[ snip unrelated limits ]
* 32767 bytes in an object (in a hosted environment only)
Seems pretty clear-cut to me. :-)
It's helpful not to confuse pointers with objects; if I write
char *ptr;
ptr = malloc (8 * 1024 * 1024);
I now have a pointer to an eight-megabyte region of allocated
memory (provided, of course, that the allocation succeeds.) But
despite what noted fools such as Herbert Schildt would have you
believe, sizeof (ptr) == sizeof (char*), not (8 * 1024 * 1024).
In other words, the size of a pointer is just that: the size of
the pointer. It isn't the size of the region it points to.
On the other hand, if you write
char array[8 * 1024 * 1024];
you may very well run into problems, depending on the definition
of size_t. Since declaring an automatic array of this size is
completely ridiculous, though, I'd hardly consider this a fault.
> Given the
> limitations of Intel 80x86 16-bit architectures, I could understand
> this being a possible limitation of poor PC C compilers. But I can't
> see this as being a shortcoming of the C -language-.
> As a programming language, C has lots of shortcomings, but this isn't
> one (any) of them...
Whether or not it's a shortcoming is a matter of opinion, but the
fact remains that it's a part of the language.
PS: Also note Tanmoy's phrase "portably"; 32767 bytes is all that
the Standard guarantees, although you may be able to "get away
with" a larger object. But again, in cases where an object larger
than this is needed, it only makes sense to use an allocated
region, as opposed to an automatic/static object. And at least
within the realm of c.l.c, this "limitation" should be respected.
Regards,
--
Chris Engebretson -- e8ag@sdsumus.sdstate.edu
Linux -- The choice of a GNU generation!
I'm at home, so what my employer thinks is irrelevant.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Help you C++ Debuggers!
1997-01-20 0:00 ` Gautier
` (3 preceding siblings ...)
1997-01-21 0:00 ` Chris Engebretson
@ 1997-01-21 0:00 ` Chris Engebretson
1997-01-22 0:00 ` Michael Chapman
1997-01-22 0:00 ` David Emery
6 siblings, 0 replies; 16+ messages in thread
From: Chris Engebretson @ 1997-01-21 0:00 UTC (permalink / raw)
I wrote:
> It's helpful not to confuse pointers with objects ...
Just to avoid confusion, this really should have been "It's helpful
not to confuse pointers with *what they point to*." Proofreading
ability is a virtue.
Brought to you by the What I Meant To Say Department.
--
Chris Engebretson -- e8ag@sdsumus.sdstate.edu
Linux -- The choice of a GNU generation!
I'm at home, so what my employer thinks is irrelevant.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Help you C++ Debuggers!
1997-01-20 0:00 ` Gautier
` (4 preceding siblings ...)
1997-01-21 0:00 ` Chris Engebretson
@ 1997-01-22 0:00 ` Michael Chapman
1997-01-22 0:00 ` David Emery
6 siblings, 0 replies; 16+ messages in thread
From: Michael Chapman @ 1997-01-22 0:00 UTC (permalink / raw)
Chris Engebretson wrote:
[snip]
> On the other hand, if you write
>
> char array[8 * 1024 * 1024];
>
> you may very well run into problems, depending on the definition
> of size_t. Since declaring an automatic array of this size is
> completely ridiculous, though, I'd hardly consider this a fault.
>
This is not at all ridiculous.
I have had good reasons in the past to declare considerably bigger
automatic arrays.
The above after all only uses up 23 of your 64 address bits if you
are on a real machine ;-)
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Help you C++ Debuggers!
1997-01-20 0:00 ` Gautier
` (5 preceding siblings ...)
1997-01-22 0:00 ` Michael Chapman
@ 1997-01-22 0:00 ` David Emery
6 siblings, 0 replies; 16+ messages in thread
From: David Emery @ 1997-01-22 0:00 UTC (permalink / raw)
2.2.4.1 Translation limits
The implementation shall be able to translate and execute at least
one program that contains at least one instance of every one of the
following limits:
[ snip unrelated limits ]
* 32767 bytes in an object (in a hosted environment only)
OK, I stand corrected...
dve
--
Note: if email to me bounces, use 'emery@grebyn.com'
^ permalink raw reply [flat|nested] 16+ messages in thread