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

Groups > comp.lang.c > #401666

Re: if else is not readable

Show all headers | View raw

bart pisze:
> On 06/09/2026 11:12, fir wrote:
>> David Brown pisze:
>>> On 06/09/2026 01:06, bart wrote:
>>>> On 05/09/2026 18:03, Janis Papanagnou wrote:
>>>>> On 2026-09-05 16:16, David Brown wrote:
>>>>>> On 05/09/2026 14:10, bart wrote:
>>>
>>>>>>>
>>>>>>>    #define sdodge(x) slog("%s" x "dodged attack...", being[k], name)
>>>>>
>>>>> (It's beyond me why one would prefer macros to a function here.
>>>>> But your basic idea to extract the invariant is of course sensible.)
>>>> There isn't enough info to see how to write an effective function.
>>>>
>>>> But if 'being[]' and 'name' are locals (or 'k' if 'being' is 
>>>> global), then the function will need those extra parameters. In that 
>>>> case, the sdodge calls will not be so different from the original 
>>>> slog calls.
>>>>
>>>>
>>>
>>> All we can do is suggest different ideas and ways to arrange such 
>>> code, and maybe the OP will see something he feels is a good fit for 
>>> his needs.  As you say, we are missing a lot of information about the 
>>> rest of the code - we don't know what data is "global" or local, when 
>>> any of these parts might be re-used, how likely it is that the 
>>> details or boundary points will be changed, and countless other details.
>>>
>>> In general, I am very sceptical about using macros for this kind of 
>>> thing.  It is correct that they let you implicitly pass local data 
>>> into the macro in a way that functions do not - but that can make the 
>>> structure a lot harder to follow, and becomes fragile for changes.  
>>> So while it is definitely something that can occasionally be helpful, 
>>> I think it is rarely the best solution.
>>>
>>> If the OP is happy with compiler extensions, a possibility here is 
>>> gcc nested functions - these can capture such local variables in a 
>>> safer and more structured manner, keeping the details within the 
>>> function itself. (Or he could use C++ and lambdas for a similar 
>>> effect.  There are proposals to add lambdas to C, but they are not 
>>> standardised yet.)
>>>
>> lol, adding almbdas to c that would be a trash... if the populist will 
>> touch c it would be a heavy disaster (they touched it already too much)
>>
>> what i strongly need is those long t = 'somethin'; here to this tags 
>> could work up to 8 length  (or 16 if some cpu has 128 bit ints)
> 
> I used to have both of those (in my language), so I could write 
> 'ABCDEFGHIJKLMNOP' which had an u128 type. I've now dropped 128-bit 
> types as they were not that useful to me (only for implementing 
> 128-types within the compiler!).
> 
> I still have 'ABCDEFGH'.
> 
> C however limits such constants to the size of 'int', which is rarely 
> bigger than 32 bits, so it can only have 'ABCD' (and C itself may only 
> guarantee 'A').
> 
> (My C compiler is different, in allowing 'ABCDEFGH'; I think it yields a 
> 64-bit type in this case.)
> 
> 
> So, given the current limitations, then what are you suggesting? Are 
> these just ideas for C extensions, or for a new language?
> 
> If you need such features now, then putting these ideas out there is not 
> going to be of immediate help.
> 
> I suggest, if you really need those features soon (this is including the 
> new 'match' statements), that you write a special preprocessor which 
> takes programs written in this enhanced C, and generates standard C.
> 
> So, 'ABCDEFGH' will be converted to perhaps 0x4847464544434241.
> 
> 

I STRONGLY NEED IT AND C STRONGLY NEED IT

IT OR YET BETTER SOME GENERALISATION OF IT

i already was writing on it but may repeat

i name it adhoc enum : 'sjhbshj' is an adhoc enum i mean you could
write anyting (though possibly alphanumeric) between '' and compare it 
to another ''

if the compiler stores it in ascii or tabelarize it internally its
secondary here

you cald also maybe name this type (which i name adhoc enum)
as a tag type (you may use 2 tyes one is this asci storaged and second
is tabelarized and represented internally as numbers

foo(tag x)
{
   if(x=='ala') dosomething();
   if(x=='bala') dosomething2();
}


this tags are extremally needed and that i must use four at most is one 
of top c annoyances  - close to that i  dont see declatrations dwn and 
must prototype ...and to tahat that "," instead of {} often dont work as 
it should, and that i must end lines with ";"

thise mentioned are one of top C anoyances

should probably make list of my top 10 anoyances but lack of tags and 
need to predeclare is maybe 2 worst

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

if else is not readable fir <profesor.fir@gmail.com> - 2026-09-05 13:43 +0200
  Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-05 13:51 +0200
  Re: if else is not readable bart <bc@freeuk.com> - 2026-09-05 13:10 +0100
    Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-05 14:26 +0200
      Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-05 14:43 +0200
        Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-05 14:51 +0200
          Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-05 14:59 +0200
            Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-05 15:09 +0200
              Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-05 15:15 +0200
                Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-05 15:21 +0200
    Re: if else is not readable David Brown <david.brown@hesbynett.no> - 2026-09-05 16:16 +0200
      Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-05 16:38 +0200
      Re: if else is not readable Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-05 19:03 +0200
        Re: if else is not readable Lane W <cactus_DAC@yahoo.com> - 2026-09-05 12:09 -0600
          Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-05 20:45 +0200
          Re: if else is not readable Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-06 00:36 +0200
            Re: if else is not readable Lane W <cactus_DAC@yahoo.com> - 2026-09-08 19:51 -0600
        Re: if else is not readable bart <bc@freeuk.com> - 2026-09-06 00:06 +0100
          Re: if else is not readable David Brown <david.brown@hesbynett.no> - 2026-09-06 11:57 +0200
            Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-06 12:12 +0200
              Re: if else is not readable bart <bc@freeuk.com> - 2026-09-06 13:54 +0100
                Re: if else is not readable bart <bc@freeuk.com> - 2026-09-06 14:02 +0100
                Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-06 16:29 +0200
                Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-06 15:25 +0200
                Re: if else is not readable bart <bc@freeuk.com> - 2026-09-06 16:42 +0100
                Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-09 14:11 +0200
                Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-09 14:22 +0200
                Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-09 14:27 +0200
                Re: if else is not readable fir <profesor.fir@gmail.com> - 2026-09-09 14:51 +0200
                Re: enums (was Re: if else is not readable) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-19 01:33 +0000
                Re: enums (was Re: if else is not readable) "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-19 16:18 +0800
                Re: if else is not readable David Brown <david.brown@hesbynett.no> - 2026-09-06 19:58 +0200

csiph-web