On template method to obtain the size of an array. Was: [OT] Re: 2 stupid array questions!!

[Zygmunt Krynicki]

Yes. And it will produce a compile error when mis-used.
As stated in my comment, this is much safer than the classic sizeof trick.

I agree.

YET: the original problem was diffetent, to quote you if I may:

The size of the array needs to be passed as a second parameter.
No other way in C (C++ allows what you need, through templates...).

End of quote. So what we had problems with is to know the size of an array
inside a function without passing extra parameters. See below.

There is no such thing as a one true way to code in C++.

True, what I wanted to show was there are some good guidelines avalaible
that I agree with.

Let me get back to your original comment: you said that the usage
of templates would be overkill. Why ?
If they provide a safer alternative to C macro tricks,
why should one avoid them ?

As you didn't specify, at the time of responding to OP's question, that
you had this particular technique on mind. I assumed you were talking
about something like:

template <class T, int N>
void fill(T &a[N], const T &value)
{
for (int i=0; i<N; ++i) a = value;
}

which I still regard as an overkill due to uneccessary code bloating.

When I do some embedded programming, I feel my code can truly
benefit from some C++ techniques, including those that rely on
templates, even when standard library containers are not only
overkill, but totally of the question (i.e. w/ only 4Kb of RAM).

I'm not experienced in embedded programming but I'd rather stick to C in
your situation.

Regards
zygmunt Krynicki

 

[Ivan Vecerina]

Hi Zygmunt -- thank you for moving the thread out of clc

On Fri, 10 Oct 2003 23:23:45 +0200, Ivan Vecerina wrote:
I agree.

YET: the original problem was diffetent, to quote you if I may:

The size of the array needs to be passed as a second parameter.
No other way in C (C++ allows what you need, through templates...).

End of quote. So what we had problems with is to know the size of an array
inside a function without passing extra parameters. See below.

Yes, and I think that this is what I described: functions
that could know the size of an array being passed to them.

There is no such thing as a one true way to code in C++.

True, what I wanted to show was there are some good guidelines
avalaible that I agree with.

Let me get back to your original comment: you said that the usage
of templates would be overkill. Why ?
If they provide a safer alternative to C macro tricks,
why should one avoid them ?

As you didn't specify, at the time of responding to OP's question, that
you had this particular technique on mind. I assumed you were talking
about something like:

template <class T, int N>
void fill(T &a[N], const T &value)
{
for (int i=0; i<N; ++i) a = value;
}

which I still regard as an overkill due to uneccessary code bloating.

This is an example I gave - but as an inline function. Not without
mentioning that, if code bloat was of concern, this function could
"call a back-end function that takes a pointer and an array size as
parameters". But in some cases, the compiler might produce better
code when the array size is known at compile time.
Anyway, this was only an example among many possible ones.

I'm not experienced in embedded programming but I'd rather
stick to C in your situation.

[ NB: 4Kb RAM doesn't mean you can't have a hundred kilobytes
of code and a processor as powerful as an original pentium ].

C has real advantages in such situations (e.g. portability),
so I do usually stick with C for such work -- or to a subset of C
and C++ that allows code to be used on both embedded devices
and PC workstations that interact together (i.e. for compression
and encryption protocols).


What I had intended to say, however, was that a C++ feature such
as templates could be useful in combination with idiomatic C code.
It does improve the expressiveness of the language in potentially
useful ways, and does not have to create any run-time overhead.


Well, I do not think that we have any technical disagreement.
Just different perspectives on what was meant by each other.
So all should be fine, and I can go sleep in peace

Kind regards,
Ivan