Help you C++ Debuggers!

Help you C++ Debuggers!

[Macarthur Drake]

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
		

2. 
ld:
Can't have archive/object only 0 bytes long: displayer3.o 

3. 

ld:
Fatal error in writing to final object file (<\x1c)
Fatal error in writing to final object file (<\x1c)
16.983u 5.929s 1:09.16 33.1% 0+0k 1736+538io 270pf+0w

	now I am convinced that my error is related to this array in some way
because if I change the size of the array to say  900 by 10 by 10 then I
don't have any problems. Am I declaring this array properly? I have
plenty of RAM and i don't think that a 900K element array of floats is
too big. Can I dynamically allocate this array somehow?

	 What is really strange is that sometimes the code compiles and runs
with no problem....and then I turn around and compile it with no changes
and I get an compilation error. Furthermore my problem is not that I am
trying to write to an element that does not exist (like if i were trying
to write to element objects[9001][10][10]) because an error like that
would be a run time error not an compilation error.....any help it truly
appreciated.........thanks alot,



	


-- 
Macarthur Drake jr.
Biomedical Engineering
The Cleveland Clinic Foundation
Phone (216) 445 3411, Fax (216) 444 9198
drake.79@postbox.acs.ohio-state.edu, drake@bme.ri.ccf.org

Re: Help you C++ Debuggers!

[Tore Lund]

Macarthur Drake wrote:
> 
> 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?
> 
> (snip)

Cannot you PLEASE send this stuff to comp.lang.c++ ONLY and not smear it
across 9 groups like you have done. And, by the way, there is no group
called comp.lang.java.

Tore
-- 
Tore Lund <tl001@sn.no>

Re: Help you C++ Debuggers!

[Gautier]

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:

1. 
   Make an 1-dim array and handle the 3 dims with multiplications

2.
   Download a good Ada compiler... N.B.: your message was posted in
   comp.lang.ada . Was it premonitory ? ;)-
                                           

Re: Help you C++ Debuggers!

[Tanmoy Bhattacharya]

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 ]

Re: Help you C++ Debuggers!

[Bradley A. Burns]

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.
> 

Re: Help you C++ Debuggers!

[David Emery]

>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'

Re: Help you C++ Debuggers!

[Chris Engebretson]

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.

Re: Help you C++ Debuggers!

[Chris Engebretson]

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.

Re: Help you C++ Debuggers!

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

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.

Re: Help you C++ Debuggers!

[David Emery]

    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'

Re: Help you C++ Debuggers!

[Michael Chapman]

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 ;-)

Re: Help you C++ Debuggers!

[Tansel Ersavas]

Alan J. Livingston wrote:
> 
> Tore Lund wrote:
> >
> > And, by the way, there is no group called comp.lang.java.
> 
> Yes there is!

No there isn't!. 
comp.lang.java has been divided into a few newsgroups. 
Among them, some might be of interest:
comp.lang.java.advocate
comp.lang.java.programmer,
...
Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: Help you C++ Debuggers!

[Tansel Ersavas]

Tansel Ersavas wrote:

> comp.lang.java.advocate
                 ^^^^^^^^
correction:      advocacy

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: Help you C++ Debuggers!

[Danette & Murray Root]

On Thu, 23 Jan 1997 01:01:09 -0500, Tansel Ersavas <tansel@rase.com> wrote in
comp.lang.c:

=> No there isn't!. 
=> comp.lang.java has been divided into a few newsgroups. 
=> Among them, some might be of interest:
=> comp.lang.java.advocate
=> comp.lang.java.programmer,
=> ...

My news server lists a comp.lang.java, but it's empty. It also shows all the
spinoffs, which I didn't explore, not being into Java, yet.
Minor nit:
 comp.lang.java.advocate
should be
 comp.lang.java.advocacy


<><><><><><><><><><><><><><><><><><><><>

Wizard's First Rule:
    People are stupid.
Wizard's Second Rule:
    Never depend on the first rule.

<><><><><><><><><><><><><><><><><><><><>

Re: Help you C++ Debuggers!

[Tore Lund]

> > > Tore Lund wrote:
> > > >
> > > > And, by the way, there is no group called comp.lang.java.
> > >
> > > Yes there is!
> >
> > No there isn't!.
>
> (etc.)

The point about all this is that people should please not post anything
to comp.lang.java because it is a bogus newsgroup. Unfortunately, these
groups continue to live a sort of tenuous afterlife even after they have
been voted out of existence. As far as I now, all articles to the group
in question are automatically rerouted to comp.lang.java.misc. Period.

Tore
-- 
Tore Lund <tl001@sn.no>

Re: Help you C++ Debuggers!

[Lawrence Kirby]

In article <01bc093e$9992fa60$966d6f9e@Defualt.DVRD.CDC.GOV>
           jgm6@cdc.gov "Jim McFarland" writes:

>> No there isn't!. 
>> comp.lang.java has been divided into a few newsgroups. 
>> Among them, some might be of interest:
>> comp.lang.java.advocate
>> comp.lang.java.programmer,
>> ...
>
>Well both news servers that I access have comp.lang.java, and I just
>downloaded 300+ recent headers from that group.  Yes there are many
>"subgroups", but comp.lang.java is still a (much less)active group.

I believe comp.lang.java has been officially removed. However if it
is still active on your system and people are still cross-posting to it
then it may appear to still exist. How many of the articles you downloaded
for it are cross-posts?

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------