«

On 11/26/11 11:08 AM, Joe keane wrote:
> "nm" gives you some help although not what OP asked for.
>
> "gprof" gives you some help although not what OP asked for.

Which OP?

> You can try something like:
>
> #define malloc(SZ) ((SZ)< 512 ? malloc_some_small_thing(SZ) :
> (SZ)< 8192 ? malloc_some_medium_thing(SZ) :
> malloc_some_big_thing(SZ))

Which will fail as soon as you include <stdlib.h>

--
Ian Collins

On 11/25/2011 3:06 PM, James Kuyper wrote:
> On 11/25/2011 06:01 AM, Jean-Michel Hautbois wrote:
>> On Nov 24, 6:00�pm, James Kuyper<jameskuy...@verizon.net> wrote:
>>> On 11/24/2011 04:06 AM, Philipp Klaus Krause wrote:
> ...
>>>> Am 23.11.2011 21:41, schrieb James Kuyper:
> ...
>>>>> The C standard does not mandate the existence of any feature that would
>
> Note the use of the word "not".
>
>>>>> produce such output at compile time. The only output that normally
>>>>> appears at compile time and is mandated by the C standard is diagnostic
>>>>> messages, the text of which is not specified by the standard, nor under
>>>>> the control of the developer - with the exception of the #error
>>>>> directive. However, the #error directive is executed during phase 4;
>>>>> sizeof expressions cannot be evaluated until phase 7, so the value of
>>>>> such expressions cannot appear in #error output.
>
> Note the use of the word "cannot".
>
>>>> Well, sizeof, unless applied to a variable-length array, yields an
>>>> integer constant. Which AFAIK, can be used e.g. as array bound. That's
>>>> how I understood the OP's "would like, at compile time ideally, [�], to
>>>> know the footprint in memory" requirement.
>>>
>>> I agree that, when VLAs are not involved, the compiler has sufficient
>>> information to produce the result that he wants; I'm just letting him
>>> know the C standard doesn't mandate support for any feature that would
>
> Note the use of the word "doesn't".
>
>>> have the desired effect.
> ...
>> Taking both of your remarks into account, I am understanding that
>> #error with sizeof can produce the output I want at compile time.
>
> I curious how you reached that conclusion, because what I said was
> almost precisely the opposite. Well, not exactly - the standard doesn't
> mandate support for any features that could be counted on to produce the
> result that you want at compile time, but neither does it prohibit them.
I of course goofed up in my previous post and James (thanks!) corrected
me alright.
What I meant (and what works) is to manually create a bunch of const
size_t objects initialized with sizes of your structures, using sizeof,
offsetof and other goodies as necessary, as long as they yield integer
constant expression (6.6p6). You can compile them in conditionally
(#ifdef MYDEBUG) and print them out or inspect in the debugger at runtime.
If I am guessing it right that you want to ensure that some size is
equal to another: that "some size" can be coded as sizeof(another).
--
Ark

On Thu, 2011-11-24, BartC wrote:
>
>
> "Jorgen Grahn" <grahn+> wrote in message
> news:slrnjcs7d1.1bk.grahn+. ..
>> On Wed, 2011-11-23, Vincenzo Mercuri wrote:
>
>>> I'm confused, but the fact that you are not interested in memory
>>> dynamically allocated (i.e. "malloced") makes me think that you only
>>> need to know the total size of the structures.
>>
>> It's quite common IME to want to get a feel for the size of structs.
>> If the nesting level is deep and you didn't write the code yourself,
>> it can be time-consuming and error-prone to figure out manually if
>> something takes 1000 bytes or 50,000 bytes ...
>
> You write a one-line program, or one-line extension, to simply print the
> static size, of the top-most struct.

I'm often cross-compiling and/or doing experimental changes to the
data structures which break other parts of the code ... so that
solution isn't the first I think of.

> But OP wants the sizes to be displayed in a tree-format, without the effort
> of writing, and having to maintain in parallel, a long sequence of
> printf/sizeof lines.

Of course he does. I want that too.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

In article <>,
Ian Collins <ian-> wrote:
>Which will fail as soon as you include <stdlib.h>

No, i found it useful, maybe someone else will find it useful as well.

Of course it is extra-legal; so is using "gprof" since there is no such
thing in the standard.