Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #143205 > unrolled thread

Auto-incrementing or auto-decrementing values at compile-time

Back to article view | Back to comp.lang.c

Contents

  Auto-incrementing or auto-decrementing values at compile-time "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-18 15:51 -0400
    Re: Auto-incrementing or auto-decrementing values at compile-time scott@slp53.sl.home (Scott Lurndal) - 2019-04-18 20:07 +0000
      Re: Auto-incrementing or auto-decrementing values at compile-time "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-18 16:42 -0400
      Re: Auto-incrementing or auto-decrementing values at compile-time jacobnavia <jacob@jacob.remcomp.fr> - 2019-04-18 23:37 +0200
        Re: Auto-incrementing or auto-decrementing values at compile-time fir <profesor.fir@gmail.com> - 2019-04-18 14:46 -0700
    Re: Auto-incrementing or auto-decrementing values at compile-time Ian Collins <ian-news@hotmail.com> - 2019-04-19 08:18 +1200
    Re: Auto-incrementing or auto-decrementing values at compile-time Bart <bc@freeuk.com> - 2019-04-18 21:25 +0100
    Re: Auto-incrementing or auto-decrementing values at compile-time Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-18 21:37 +0100
      Re: Auto-incrementing or auto-decrementing values at compile-time "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-18 16:45 -0400
        Re: Auto-incrementing or auto-decrementing values at compile-time Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-18 21:59 +0100
    Re: Auto-incrementing or auto-decrementing values at compile-time Richard Damon <Richard@Damon-Family.org> - 2019-04-19 09:13 -0400
      Re: Auto-incrementing or auto-decrementing values at compile-time "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-19 09:25 -0400
        Re: Auto-incrementing or auto-decrementing values at compile-time Richard Damon <Richard@Damon-Family.org> - 2019-04-19 12:37 -0400
          Re: Auto-incrementing or auto-decrementing values at compile-time "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-19 12:52 -0400
    Re: Auto-incrementing or auto-decrementing values at compile-time Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-04-19 17:16 -0600

#143205 — Auto-incrementing or auto-decrementing values at compile-time

I have a need fairly often to return distinct values for a return value.
I don't particularly care what the values are, but they just need to be
distinct and unique so that if they are returned later I can identify
the exact cause of the error, where it failed.

Something like this:

     int my_function(void)
     {
         if (!test_condition1)
             return -1;  // Indicate it failed at this test

         // Arbitrary code

         if (!test_condition2)
             return -2;  // Indicate it failed at this test

         // Arbitrary code

         if (!test_condition3)
             return -3;  // Indicate it failed at this test

         // If we get here, we're good
     }

Is there an existing way in C/C++ to automatically create some value
that would allow me to add a new test and have it inject the new
value?  Ideally, I'd like for the compiler abilities to be sticky,
meaning once you put in the token/whatever to identify you need a
locally scoped automatically incrementing or decrementing value, that
it bakes it into source code during the compile.

Something like coding it this way initially:

     int my_function(void)
     {
         if (!test_condition1)
             return #autodec;  // Indicate it failed at this test

         if (!test_condition2)
             return #autodec;  // Indicate it failed at this test

         if (!test_condition3)
             return #autodec;  // Indicate it failed at this test

         // If we get here, we're good
     }

And during compilation it automatically translates it to this for, baking
in the number:

     int my_function(void)
     {
         if (!test_condition1)
             return #autodec[-1];  // Indicate it failed at this test

         if (!test_condition2)
             return #autodec_[-2];  // Indicate it failed at this test

         if (!test_condition3)
             return #autodec_[-3];  // Indicate it failed at this test

         // If we get here, we're good
     }

This would allow new code to be added later without a hard-value, and
it would automatically adjust to the value inside the scope:

     int my_function(void)
     {
==>     if (!test_condition0)
==>         return #autodec;  // Indicate it failed at this test

         if (!test_condition1)
             return #autodec[-1];  // Indicate it failed at this test

         if (!test_condition2)
             return #autodec_[-2];  // Indicate it failed at this test

         if (!test_condition3)
             return #autodec_[-3];  // Indicate it failed at this test

         // If we get here, we're good
     }

It would change to this during compile, and write the source file
back out:

         if (!test_condition0)
             return #autodec[-4];  // Indicate it failed at this test

I can see doing this in an external tool, but is there some way to do
it in C/C++?

And if not, does anyone have any idea for a good syntax on how to do it?

-- 
Rick C. Hodgin

[toc] | [next] | [standalone]

#143206

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

>This would allow new code to be added later without a hard-value, and
>it would automatically adjust to the value inside the scope:

There are two sides to every function call - how do the callers of that
function know, a priori, which return code matches which (pre)condition
failure; particularly when subsequently code gets inserted into the existing set
such that successive autogenerated return codes are shifted by one?

Just use a #define, static const uint32_t  or enum and update them as needed.

[toc] | [prev] | [next] | [standalone]

#143211

On 4/18/2019 4:07 PM, Scott Lurndal wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
>> This would allow new code to be added later without a hard-value, and
>> it would automatically adjust to the value inside the scope:
> 
> There are two sides to every function call - how do the callers of that
> function know, a priori, which return code matches which (pre)condition
> failure;

The functions pretty much always return 0 or a positive value if
there were no errors.

It's contextual.  how_long_is_this_text() will return a negative
value if you don't pass in a valid parameter, or 0 or a larger
value if there is content there, etc.

> particularly when subsequently code gets inserted into the existing set
> such that successive autogenerated return codes are shifted by one?

I don't have any autogenerated code in most projects.  Some, but not many.

> Just use a #define, static const uint32_t or enum and update them as needed.

I write enough new code that it's becoming tedious to keep track of
all the unique values.

I will probably write an external tool and add a pre-build processing
step during compilation.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#143215

Le 18/04/2019 à 22:07, Scott Lurndal a écrit :
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
>> This would allow new code to be added later without a hard-value, and
>> it would automatically adjust to the value inside the scope:
> 
> There are two sides to every function call - how do the callers of that
> function know, a priori, which return code matches which (pre)condition
> failure; particularly when subsequently code gets inserted into the existing set
> such that successive autogenerated return codes are shifted by one?
> 

And why are we discussing this brain-dead ideas from this known spammer?

Why people here feel happy answering this kind of rubbish?

Just looking at this kind of "proposal" for his vaporware leads a sane 
reader to deduce that:

1) The brain of the poster is malfunctioning badly.
2) He is just posting nonsense, vaguely related to C, to start 
"discussions" to cover up his spamming.

> Just use a #define, static const uint32_t  or enum and update them as needed.
> 

That would work, but you forgot something:

Before coding (and also before posting rubbish) he should TURN HIS BRAIN 
ON...

But apparently he can't.

[toc] | [prev] | [next] | [standalone]

#143216

W dniu czwartek, 18 kwietnia 2019 23:37:17 UTC+2 użytkownik jacobnavia napisał:
> Le 18/04/2019 à 22:07, Scott Lurndal a écrit :
> > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > 
> >> This would allow new code to be added later without a hard-value, and
> >> it would automatically adjust to the value inside the scope:
> > 
> > There are two sides to every function call - how do the callers of that
> > function know, a priori, which return code matches which (pre)condition
> > failure; particularly when subsequently code gets inserted into the existing set
> > such that successive autogenerated return codes are shifted by one?
> > 
> 
> And why are we discussing this brain-dead ideas from this known spammer?
> 
> Why people here feel happy answering this kind of rubbish?
> 
> Just looking at this kind of "proposal" for his vaporware leads a sane 
> reader to deduce that:
> 
> 1) The brain of the poster is malfunctioning badly.
> 2) He is just posting nonsense, vaguely related to C, to start 
> "discussions" to cover up his spamming.
> 
> > Just use a #define, static const uint32_t  or enum and update them as needed.
> > 
> 
> That would work, but you forgot something:
> 
> Before coding (and also before posting rubbish) he should TURN HIS BRAIN 
> ON...
> 
> But apparently he can't.

the reality is like is - those users are sort half trolls, extreme stupidity seems not disgust them so they legitimize/forward it

it gives me to think.. though i got no conclusions yet

[toc] | [prev] | [next] | [standalone]

#143208

On 19/04/2019 07:51, Rick C. Hodgin wrote:
> I have a need fairly often to return distinct values for a return value.
> I don't particularly care what the values are, but they just need to be
> distinct and unique so that if they are returned later I can identify
> the exact cause of the error, where it failed.
> 
> Something like this:
> 
>       int my_function(void)
>       {
>           if (!test_condition1)
>               return -1;  // Indicate it failed at this test
> 
>           // Arbitrary code
> 
>           if (!test_condition2)
>               return -2;  // Indicate it failed at this test
> 
>           // Arbitrary code
> 
>           if (!test_condition3)
>               return -3;  // Indicate it failed at this test
> 
>           // If we get here, we're good
>       }
> 
> Is there an existing way in C/C++ to automatically create some value
> that would allow me to add a new test and have it inject the new
> value?

An enum.

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#143209

On 18/04/2019 20:51, Rick C. Hodgin wrote:
> I have a need fairly often to return distinct values for a return value.
> I don't particularly care what the values are, but they just need to be
> distinct and unique so that if they are returned later I can identify
> the exact cause of the error, where it failed.
> 
> Something like this:
> 
>      int my_function(void)
>      {
>          if (!test_condition1)
>              return -1;  // Indicate it failed at this test
> 
>          // Arbitrary code
> 
>          if (!test_condition2)
>              return -2;  // Indicate it failed at this test
> 
>          // Arbitrary code
> 
>          if (!test_condition3)
>              return -3;  // Indicate it failed at this test
> 
>          // If we get here, we're good
>      }
> 
> Is there an existing way in C/C++ to automatically create some value
> that would allow me to add a new test and have it inject the new
> value?  Ideally, I'd like for the compiler abilities to be sticky,
> meaning once you put in the token/whatever to identify you need a
> locally scoped automatically incrementing or decrementing value, that
> it bakes it into source code during the compile.

Not really sure what you're getting at. But this function:

     int test(int n) {

         switch (n) {
         enum {base=__LINE__};

         case 1:
             return base-__LINE__;
         case 2:
             return base-__LINE__;
         case 3:
             return base-__LINE__;
         }
         return 0;
     }


Returns -3, -5, -7 when called with n = 1,2,3.

A new case would return a different error (ie. negative value), with no 
enums to maintain (assuming it's on a different line). Alternatively 
just return -__LINENO__ for an absolute line number to pinpoint where it 
went wrong in the function.

[toc] | [prev] | [next] | [standalone]

#143210

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> I have a need fairly often to return distinct values for a return value.
> I don't particularly care what the values are, but they just need to be
> distinct and unique so that if they are returned later I can identify
> the exact cause of the error, where it failed.
<cut>
> Something like coding it this way initially:
>
>     int my_function(void)
>     {
>         if (!test_condition1)
>             return #autodec;  // Indicate it failed at this test
>
>         if (!test_condition2)
>             return #autodec;  // Indicate it failed at this test
>
>         if (!test_condition3)
>             return #autodec;  // Indicate it failed at this test
>
>         // If we get here, we're good
>     }

This ties the correctness of every calling function into the order in
which these tests are written.  I think it should be added to your
language ASAP.

<cut>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#143212

On 4/18/2019 4:37 PM, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
>> I have a need fairly often to return distinct values for a return value.
>> I don't particularly care what the values are, but they just need to be
>> distinct and unique so that if they are returned later I can identify
>> the exact cause of the error, where it failed.
> <cut>
>> Something like coding it this way initially:
>>
>>      int my_function(void)
>>      {
>>          if (!test_condition1)
>>              return #autodec;  // Indicate it failed at this test
>>
>>          if (!test_condition2)
>>              return #autodec;  // Indicate it failed at this test
>>
>>          if (!test_condition3)
>>              return #autodec;  // Indicate it failed at this test
>>
>>          // If we get here, we're good
>>      }
> 
> This ties the correctness of every calling function into the order in
> which these tests are written.

You missed the part where the idea I'm looking for bakes the values
first encountered with the naked #autodec into solid values which
are later identified as #autodec[-1] ... #autodec[-Nn], which allows
later #autodec portions to be added and they'll automatically insert
the next value in that location.

> I think it should be added to your language ASAP.

You're such a hateful person to me, Ben.  You said previously in a
private email that you were going to try to refrain from responding
to my posts.  Please try harder.  Your failures are unbecoming.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#143214

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On 4/18/2019 4:37 PM, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>
>>> I have a need fairly often to return distinct values for a return value.
>>> I don't particularly care what the values are, but they just need to be
>>> distinct and unique so that if they are returned later I can identify
>>> the exact cause of the error, where it failed.
>> <cut>
>>> Something like coding it this way initially:
>>>
>>>      int my_function(void)
>>>      {
>>>          if (!test_condition1)
>>>              return #autodec;  // Indicate it failed at this test
>>>
>>>          if (!test_condition2)
>>>              return #autodec;  // Indicate it failed at this test
>>>
>>>          if (!test_condition3)
>>>              return #autodec;  // Indicate it failed at this test
>>>
>>>          // If we get here, we're good
>>>      }
>>
>> This ties the correctness of every calling function into the order in
>> which these tests are written.
>
> You missed the part where the idea I'm looking for bakes the values
> first encountered with the naked #autodec into solid values which
> are later identified as #autodec[-1] ... #autodec[-Nn], which allows
> later #autodec portions to be added and they'll automatically insert
> the next value in that location.

Yes, you are right, I did.  But that part looks even worse.  As far as I
can make out you end up with the source code not being the source code,
but I am sure I have missed something.  I would advocate for an enum
that can be defined like Go's enums.

>> I think it should be added to your language ASAP.
>
> You're such a hateful person to me, Ben.  You said previously in a
> private email that you were going to try to refrain from responding
> to my posts.  Please try harder.  Your failures are unbecoming.

Yes I should.  I was filled with the joys of spring and forgot myself.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#143220

On 4/18/19 3:51 PM, Rick C. Hodgin wrote:
> I have a need fairly often to return distinct values for a return value.
> I don't particularly care what the values are, but they just need to be
> distinct and unique so that if they are returned later I can identify
> the exact cause of the error, where it failed.
> 
> Something like this:
> 
>     int my_function(void)
>     {
>         if (!test_condition1)
>             return -1;  // Indicate it failed at this test
> 
>         // Arbitrary code
> 
>         if (!test_condition2)
>             return -2;  // Indicate it failed at this test
> 
>         // Arbitrary code
> 
>         if (!test_condition3)
>             return -3;  // Indicate it failed at this test
> 
>         // If we get here, we're good
>     }
> 
> Is there an existing way in C/C++ to automatically create some value
> that would allow me to add a new test and have it inject the new
> value?  Ideally, I'd like for the compiler abilities to be sticky,
> meaning once you put in the token/whatever to identify you need a
> locally scoped automatically incrementing or decrementing value, that
> it bakes it into source code during the compile.
> 
> Something like coding it this way initially:
> 
>     int my_function(void)
>     {
>         if (!test_condition1)
>             return #autodec;  // Indicate it failed at this test
> 
>         if (!test_condition2)
>             return #autodec;  // Indicate it failed at this test
> 
>         if (!test_condition3)
>             return #autodec;  // Indicate it failed at this test
> 
>         // If we get here, we're good
>     }
> 
> And during compilation it automatically translates it to this for, baking
> in the number:
> 
>     int my_function(void)
>     {
>         if (!test_condition1)
>             return #autodec[-1];  // Indicate it failed at this test
> 
>         if (!test_condition2)
>             return #autodec_[-2];  // Indicate it failed at this test
> 
>         if (!test_condition3)
>             return #autodec_[-3];  // Indicate it failed at this test
> 
>         // If we get here, we're good
>     }
> 
> This would allow new code to be added later without a hard-value, and
> it would automatically adjust to the value inside the scope:
> 
>     int my_function(void)
>     {
> ==>     if (!test_condition0)
> ==>         return #autodec;  // Indicate it failed at this test
> 
>         if (!test_condition1)
>             return #autodec[-1];  // Indicate it failed at this test
> 
>         if (!test_condition2)
>             return #autodec_[-2];  // Indicate it failed at this test
> 
>         if (!test_condition3)
>             return #autodec_[-3];  // Indicate it failed at this test
> 
>         // If we get here, we're good
>     }
> 
> It would change to this during compile, and write the source file
> back out:
> 
>         if (!test_condition0)
>             return #autodec[-4];  // Indicate it failed at this test
> 
> I can see doing this in an external tool, but is there some way to do
> it in C/C++?
> 
> And if not, does anyone have any idea for a good syntax on how to do it?
> 

This is NOT an operation that seems valid for a compiler, as the
compiler should NEVER go back and change the source code.

It might make sense for a developement platform (like an IDE).

Personally, it defies the rule against magic numbers, so what I would do
is have something like an enum in the header defining the interface to
the function, defining the return values for the error codes, and when I
need to add a new error code, I add an entry to the enum and return that
entry. This says that calling code has names for the various error
codes, rather than having to be littered with all the magic numbers.

[toc] | [prev] | [next] | [standalone]

#143221

On 4/19/2019 9:13 AM, Richard Damon wrote:
> This is NOT an operation that seems valid for a compiler, as the
> compiler should NEVER go back and change the source code.

I've had that thought, but I've also had the thought that the tools
we use should be accommodating to the needs of some required syntax
and operations at times.  We shouldn't have to diversify very far
for some features that are oft-used.

I use that pattern in pretty much every function I write that is
visible outwardly through an API.  And it becomes tedious to have
to manually set the values.

Being as I code that way pretty much every day, it seems that it
would be of benefit.

> It might make sense for a developement platform (like an IDE).

I can see that applying to specific things, like in Windows we have
to make sure return handles are not set to the INVALID_HANDLE_VALUE
constant, but that same constant isn't valid on other OSes... so
there would be value there for having platform-dependent features
added to the development platform.

But for cases that transcend OS barriers, I think it would be more
desirable to have a language-level solution.

> Personally, it defies the rule against magic numbers, so what I would do
> is have something like an enum in the header defining the interface to
> the function, defining the return values for the error codes, and when I
> need to add a new error code, I add an entry to the enum and return that
> entry. This says that calling code has names for the various error
> codes, rather than having to be littered with all the magic numbers.

I am unaware of the rule of magic numbers.

I think the ability to receive source code, and have it have a user-
specified (in source code) request to assign something mechanically
rather than manually, and then re-write the altered source code back
out, is a desirable feature that the language should possess, especially
when the language is recognizing that it's working in concert with a
live developer who is coding at various times, and the compiler is not
just seeing static code that is more or less stable from a mature code
base.

Having this new ability would allow us to introduce a slew of features
which bake-in on the first compile, and are then viewed as constants
after that.  The machine would do it reliably, and we wouldn't have
to get bogged down in defining extra minutia details.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#143224

On 4/19/19 9:25 AM, Rick C. Hodgin wrote:
> 
>> Personally, it defies the rule against magic numbers, so what I would do
>> is have something like an enum in the header defining the interface to
>> the function, defining the return values for the error codes, and when I
>> need to add a new error code, I add an entry to the enum and return that
>> entry. This says that calling code has names for the various error
>> codes, rather than having to be littered with all the magic numbers.
> 
> I am unaware of the rule of magic numbers.
> 

The basic rule is that a 'magic number' should appear at most once in
any program, generally to assign it to some named constant of some sort
to be used elsewhere.

Basically, if you have code that does something like:

if(error == -2) ...

You have a magic number there and you need to dig into the documentation
to have any idea what that number means (there is nothing inherent in
the value -2 that tells you what the error would be).

A second problem with magic numbers is that if you need to change what
the value is of that magic number at its source (perhaps you started
with two distinct sets of error codes with overlapping values, and now
you need them to be distinct), you now need to go through you whole
source code and change the value, and determine if that use of the value
was this magic value, or some other magic value, or maybe something that
just happened to have that value mathematically.

If every use of that magic number used a symbolic name, than changing it
is easy, you just need to change the value assigned to that symbolic name.

[toc] | [prev] | [next] | [standalone]

#143226

On 4/19/2019 12:37 PM, Richard Damon wrote:
> On 4/19/19 9:25 AM, Rick C. Hodgin wrote:
>> I am unaware of the rule of magic numbers.
> 
> The basic rule is that a 'magic number' should appear at most once in
> any program, generally to assign it to some named constant of some sort
> to be used elsewhere.
> 
> Basically, if you have code that does something like:
> 
> if(error == -2) ...
> 
> You have a magic number there and you need to dig into the documentation
> to have any idea what that number means (there is nothing inherent in
> the value -2 that tells you what the error would be).

Got it.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#143239

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> I have a need fairly often to return distinct values for a return value.
> I don't particularly care what the values are, but they just need to be
> distinct and unique so that if they are returned later I can identify
> the exact cause of the error, where it failed.
>
> Something like this:
>
>     int my_function(void)
>     {
>         if (!test_condition1)
>             return -1;  // Indicate it failed at this test
>
>         // Arbitrary code
>
>         if (!test_condition2)
>             return -2;  // Indicate it failed at this test
>
>         // Arbitrary code
>
>         if (!test_condition3)
>             return -3;  // Indicate it failed at this test
>
>         // If we get here, we're good
>     }
>
> Is there an existing way in C/C++ to automatically create some value
> that would allow me to add a new test and have it inject the new
> value?  Ideally, I'd like for the compiler abilities to be sticky,
> meaning once you put in the token/whatever to identify you need a
> locally scoped automatically incrementing or decrementing value, that
> it bakes it into source code during the compile.
>
> Something like coding it this way initially:
>
>     int my_function(void)
>     {
>         if (!test_condition1)
>             return #autodec;  // Indicate it failed at this test
>
>         if (!test_condition2)
>             return #autodec;  // Indicate it failed at this test
>
>         if (!test_condition3)
>             return #autodec;  // Indicate it failed at this test
>
>         // If we get here, we're good
>     }
>
> And during compilation it automatically translates it to this for, baking
> in the number:
>
>     int my_function(void)
>     {
>         if (!test_condition1)
>             return #autodec[-1];  // Indicate it failed at this test
>
>         if (!test_condition2)
>             return #autodec_[-2];  // Indicate it failed at this test
>
>         if (!test_condition3)
>             return #autodec_[-3];  // Indicate it failed at this test
>
>         // If we get here, we're good
>     }
>
> This would allow new code to be added later without a hard-value, and
> it would automatically adjust to the value inside the scope:
>
>     int my_function(void)
>     {
> ==>     if (!test_condition0)
> ==>         return #autodec;  // Indicate it failed at this test
>
>         if (!test_condition1)
>             return #autodec[-1];  // Indicate it failed at this test
>
>         if (!test_condition2)
>             return #autodec_[-2];  // Indicate it failed at this test
>
>         if (!test_condition3)
>             return #autodec_[-3];  // Indicate it failed at this test
>
>         // If we get here, we're good
>     }
>
> It would change to this during compile, and write the source file
> back out:
>
>         if (!test_condition0)
>             return #autodec[-4];  // Indicate it failed at this test
>
> I can see doing this in an external tool, but is there some way to do
> it in C/C++?
>
> And if not, does anyone have any idea for a good syntax on how to do it?

This really doesn't seem like a good idea to me.  Not only are you using
"magic numbers", you're using magic numbers you haven't defined
yourself, and whose value will change if additional if's get added at
some later time.

I'd much rather use an enum and typedef
typedef enum {SUCCESS, OOPS, FATAL_ERR, ...} ReturnCode;

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web