«

On Fri, 2011-10-14, A wrote:
>> The above sounds as if you're asking about how to define functions, but
>> then in the text you indicate that you are familiar with that. So it does
>> not make sense as given. You need to provide a more clear example.
>
> If I call a function that would imply after compilation - storing registers
> on stack, a call to function, then returning registers from stack and
> return. All of that takes CPU cycles for time-critical loops. With inline
> code it would be compilers job to kind of "paste" a code defined in the
> template. And no, I don't really want to use inline assembly.

You use the term "inline" over and over, but you seem to overlook
inline functions. All the (relatively) costly things you mention above,
plus the missed optimization opportunities, go away with inline
functions.

....
> So that's what I'm looking a way for to do. Like I said, I know how to use
> functions.

Not if you equate calling a function with heavy stack/register
operations.

/Jorgen

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

> #define DEFINE_I_TO_1 int i=1;

so it is a macro... this looks like something what i had in mind

will something like this work for more than a single line of code?

> *Please don't snip attributions, it is rude.* I'll ignore you if you do
> it again.

Sorry, don't have idea what you're talking about here. Just cutting out the
relevant part for the answer. All newsreaders have in-reference-to header so
it is groupped as it should be.

>> How is a macro list thing more convenient than a function?

Because in this particular case it would be more useful. I have overloaded
function that calls something like this:

- a block of always the same block of code here
- something different
- a different block of the same code here

and it is repeated in overloaded functions over and over. if I make a simple
change in one or the other block I have to copy-paste them in each
overloaded function. maintaining this would be easier if this code is placed
in a function or... a kind of macro like i asked for in above explanations.

>> do with macros or templates or any other way except functions?
> Why? You haven't provided any justification for this new construct.

I am informing myself of other ways of doing things. I already explained I
can do it with functions but in this particular case a macro thing would be
way more practical. No solution fits purposes.

I tried this (as an dumb example) and it seems to work...
I think I'll be learning a bit more about macros.

The only drawback I see so far is the fact I can't debug the CODEPART1 and
CODEPART2 but except that it is working as intented.

#define CODEPART1 \
std::vector<int> abc(5); \
for (int i = 0; i < abc.size(); i++) \
{ \
abc[i] = i; \
}

#define CODEPART2 \
return abc[4];

int overload(int a)
{
CODEPART1
abc[0] = 0;
CODEPART2
}

int overload(__int64 a)
{
CODEPART1
abc[1] = 0;
CODEPART2
}

On 10/15/11 11:54 AM, A wrote:
> I tried this (as an dumb example) and it seems to work...
> I think I'll be learning a bit more about macros.
>
> The only drawback I see so far is the fact I can't debug the CODEPART1 and
> CODEPART2 but except that it is working as intented.
>
> #define CODEPART1 \
> std::vector<int> abc(5); \
> for (int i = 0; i< abc.size(); i++) \
> { \
> abc[i] = i; \
> }
>
> #define CODEPART2 \
> return abc[4];
>
> int overload(int a)
> {
> CODEPART1
> abc[0] = 0;
> CODEPART2
> }
>
> int overload(__int64 a)
> {
> CODEPART1
> abc[1] = 0;
> CODEPART2
> }
>
>

The limitations on debugging are a function of the debugger. A good
debugger will at least let you switch into an assembly view of the code
to see what is happening.

If you are having trouble with a macro expansion, replacing the macro
with its expanded text temporarily normally will make it easier to debug
(and then if you needed to change the code, go back and fix the original
macro to match, but ideally you would have debugged the snippet as
independent code before pushing it into a macro.

On Sat, 2011-10-15, A wrote:
>> *Please don't snip attributions, it is rude.* I'll ignore you if you do
>> it again.
>
> Sorry, don't have idea what you're talking about here.

What you just did -- skip the line "Ian Collins wrote:". It's that
thing which lets people look at your posting *only* and know who wrote
what.

The rest of your quoting seems fine to me.

/Jorgen

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