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

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

is there a way to ask a variable what it is?

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

Contents

  is there a way to ask a variable what it is? T <T@invalid.invalid> - 2020-01-28 19:19 -0800
    Re: is there a way to ask a variable what it is? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-29 03:47 +0000
      Re: is there a way to ask a variable what it is? T <T@invalid.invalid> - 2020-01-28 20:20 -0800
        Re: is there a way to ask a variable what it is? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-29 19:18 +0000
          Re: is there a way to ask a variable what it is? Bart <bc@freeuk.com> - 2020-01-29 20:58 +0000
            Re: is there a way to ask a variable what it is? nobody@example.org (Scott) - 2020-01-30 15:59 +0000
              Re: is there a way to ask a variable what it is? scott@slp53.sl.home (Scott Lurndal) - 2020-01-30 16:35 +0000
      Re: is there a way to ask a variable what it is? Siri Cruise <chine.bleu@yahoo.com> - 2020-01-28 21:55 -0800
        Re: is there a way to ask a variable what it is? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-30 00:24 +0000
          solved: Re: is there a way to ask a variable what it is? T <T@invalid.invalid> - 2020-01-29 21:51 -0800
            Re: solved: Re: is there a way to ask a variable what it is? fir <profesor.fir@gmail.com> - 2020-01-30 03:16 -0800
    Re: is there a way to ask a variable what it is? Ian Collins <ian-news@hotmail.com> - 2020-01-29 17:28 +1300
      Re: is there a way to ask a variable what it is? T <T@invalid.invalid> - 2020-01-28 20:55 -0800
        Re: is there a way to ask a variable what it is? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-29 06:49 +0000
        Re: is there a way to ask a variable what it is? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-29 08:08 +0100
        Re: is there a way to ask a variable what it is? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-30 00:14 +0000
          solved: Re: is there a way to ask a variable what it is? T <T@invalid.invalid> - 2020-01-29 21:51 -0800
          Re: is there a way to ask a variable what it is? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-18 08:56 -0800
            Re: is there a way to ask a variable what it is? already5chosen@yahoo.com - 2020-02-19 01:19 -0800
              Re: is there a way to ask a variable what it is? chad <cdalten@gmail.com> - 2020-02-19 02:53 -0800
              Re: is there a way to ask a variable what it is? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-19 12:45 +0000
              Re: is there a way to ask a variable what it is? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-19 07:55 -0500
              Re: is there a way to ask a variable what it is? Bart <bc@freeuk.com> - 2020-02-19 13:02 +0000
                Re: is there a way to ask a variable what it is? chad <cdalten@gmail.com> - 2020-02-19 07:27 -0800
              Re: is there a way to ask a variable what it is? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 09:42 -0800
    Re: is there a way to ask a variable what it is? Robert Wessel <robertwessel2@yahoo.com> - 2020-01-28 22:36 -0600
      Re: is there a way to ask a variable what it is? T <T@invalid.invalid> - 2020-01-28 20:55 -0800
        Re: is there a way to ask a variable what it is? Manfred <noname@add.invalid> - 2020-01-29 13:22 +0100
          Re: is there a way to ask a variable what it is? David Brown <david.brown@hesbynett.no> - 2020-01-29 13:57 +0100
            Re: is there a way to ask a variable what it is? Manfred <noname@add.invalid> - 2020-01-29 17:47 +0100
              Re: is there a way to ask a variable what it is? David Brown <david.brown@hesbynett.no> - 2020-01-30 12:06 +0100
      Re: is there a way to ask a variable what it is? scott@slp53.sl.home (Scott Lurndal) - 2020-01-29 15:10 +0000
        Re: is there a way to ask a variable what it is? Manfred <noname@add.invalid> - 2020-01-29 17:07 +0100
    Re: is there a way to ask a variable what it is? Siri Cruise <chine.bleu@yahoo.com> - 2020-01-28 21:52 -0800
    Re: is there a way to ask a variable what it is? Bart <bc@freeuk.com> - 2020-01-29 11:11 +0000
      Re: is there a way to ask a variable what it is? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-29 13:30 +0100
        Re: is there a way to ask a variable what it is? Bart <bc@freeuk.com> - 2020-01-29 12:44 +0000
          Re: is there a way to ask a variable what it is? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-29 14:03 +0100
            Re: is there a way to ask a variable what it is? gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-29 14:03 +0000
            Re: is there a way to ask a variable what it is? Bart <bc@freeuk.com> - 2020-01-29 14:30 +0000
              Re: is there a way to ask a variable what it is? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-29 15:45 +0100
                Re: is there a way to ask a variable what it is? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-29 16:28 +0100
                  Re: is there a way to ask a variable what it is? T <T@invalid.invalid> - 2020-01-29 08:35 -0800
                  Re: is there a way to ask a variable what it is? Bart <bc@freeuk.com> - 2020-01-29 17:34 +0000
                    Re: is there a way to ask a variable what it is? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-29 18:48 +0100
      Re: is there a way to ask a variable what it is? Thiago Adams <thiago.adams@gmail.com> - 2020-01-29 04:43 -0800
        Re: is there a way to ask a variable what it is? David Brown <david.brown@hesbynett.no> - 2020-01-29 14:46 +0100
          Re: is there a way to ask a variable what it is? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-29 15:15 +0000
            Re: is there a way to ask a variable what it is? fir <profesor.fir@gmail.com> - 2020-01-29 08:11 -0800
            Re: is there a way to ask a variable what it is? T <T@invalid.invalid> - 2020-01-29 08:38 -0800
    Re: is there a way to ask a variable what it is? Bart <bc@freeuk.com> - 2020-01-29 11:23 +0000
    Re: is there a way to ask a variable what it is? John Bode <jfbode1029@gmail.com> - 2020-01-29 11:55 -0800
    Re: is there a way to ask a variable what it is? jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-19 12:23 +0100
    Re: is there a way to ask a variable what it is? jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-19 12:23 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#150080

already5chosen@yahoo.com writes:

> On Tuesday, February 18, 2020 at 6:56:18 PM UTC+2, Tim Rentsch wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> 
>> > [...] C is a statically typed language so all type information,
>> > and everything easily derived from type information, is known at
>> > compile time.
>> 
>> I don't think that's right exactly.  For one example, some type
>> information may be known in one translation unit but not known
>> in another.  A declaration like
>> 
>>     extern int special_values[];
>> 
>> offers partial but not complete type information in this TU, and so
>> is not known at compile time.
>
> What is "a real type", if there is such thing, is unknown, but what
> compiler think about the type when it deals with this specific
> translation unit is know.

I was not going to reply because I was deliberately simplifying for the
OP and hoping that no one would ask me to justify what I'd wrote!.

I am with you here.  The type of special_values is known in this TU --
it's an incomplete array type.  The same identifier may have a different
type in another TU.

>> A second example is variable length
>> arrays.  Here the type information is not known until run time, and
>> usually is not fixed but varies with different invocations. 
>
> Here we are at philosophical question of "what is considered a type?".
> You appear to come from school of original Pascal, where length of
> array is considered part of its type. That's not how traditional 'C'
> sees it.

No, the size of an array, when known, has always been part of the type,
right back to K&R C.  You don't often get to see this fact because of
the array to pointer conversion, but try:

  int a[4];
  int (*ap)[3] = &a;

and you'll see.

> Anyway, VLA are already optional in the latest Standard and
> hopefully will be marked deprecated in the next one. I am of opinion
> that their addition in c99 was a mistake.

Certainly debatable, but I think the committee has thrown the baby out
with the bath water.  Variably modified types are very useful and have
none of the issue that so rile people up about variable length arrays,
but I think both have been made optional together.

>> A third
>> example pertains to structures and unions in dynamically allocated
>> memory, where code inspects a tag using the "one special guarantee"
>> for structure member access, to select a specific struct type (using
>> a cast) at run time.  
>
> That is similar to the first case: the "real" type is unknown, but the
> type, assumed by compiler at any given point/statement is known.

Hmm... What C always knows is the type of any expression used to access
an object.  This is probably what you mean by the "real" type (but do
correct me if that's not what you mean).  C adds to this the notion of
the effective type of an object, and makes certain accesses undefined
when mismatches occur between these two types.  The effective type of an
allocated object is genuine run-time type information but the standard
makes sure no implementation needs to track it.

<cut>
-- 
Ben.

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

#150081

On 2/19/20 4:19 AM, already5chosen@yahoo.com wrote:
> On Tuesday, February 18, 2020 at 6:56:18 PM UTC+2, Tim Rentsch wrote:
...
> Here we are at philosophical question of "what is considered a type?".
> You appear to come from school of original Pascal, where length of array is considered part of its type. That's not how traditional 'C' sees it. 
> Anyway, VLA are already optional in the latest Standard and hopefully will be marked deprecated in the next one. I am of opinion that their addition in c99 was a mistake.

I'm curious. Given the following declarations:

  int a[2][3];
  int b[3][2];
  int (*p)[3] = a;
  int (*q)[2] = b;

What do you think is the element type of the array a? What is the
element type of array b? What type does p point at? What type does q
point at? Does the expression q = a violate a constraint? If so, which
one, and why? See 6.7.6.1p2 and 6.7.6.2p6.

>> A third
>> example pertains to structures and unions in dynamically allocated
>> memory, where code inspects a tag using the "one special guarantee"
>> for structure member access, to select a specific struct type (using
>> a cast) at run time.  
> 
> That is similar to the first case: the "real" type is unknown, but the type, assumed by compiler at any given point/statement is known.

The standard doesn't use the term "real type" with anything like the
meaning you're thinking of here. It only uses the term to divide
arithmetic types into real, imaginary, and complex types. _Bool, int,
and float are examples of real types, while double _Imaginary is an
imaginary type, and long double _Complex is a complex types.

The standard does have the concepts of the "effective type" of an
object, the "declared type" of that object, and the type of an lvalue
used to access the object. See 6.5p6 and 6.5p7 to see how those terms
are used. I think that the declared type of an object, if it has one, is
the concept that comes closest to being what you're thinking of as the
"real type".

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

#150082

On 19/02/2020 09:19, already5chosen@yahoo.com wrote:

> Here we are at philosophical question of "what is considered a type?".
> You appear to come from school of original Pascal, where length of array is considered part of its type. That's not how traditional 'C' sees it.

It is in C too:

     int (*p)[10];     // pointer to array 10 of int
     int (*q)[20];     // pointer to array 20 of int

     p=q;

This assignment should give at least a warning about incompatible types.

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

#150083

Some languages call all of this "apparent type" and "actual type"

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

#150154

already5chosen@yahoo.com writes:

> On Tuesday, February 18, 2020 at 6:56:18 PM UTC+2, Tim Rentsch wrote:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> [...] C is a statically typed language so all type information,
>>> and everything easily derived from type information, is known at
>>> compile time.
>>
>> I don't think that's right exactly.  For one example, some type
>> information may be known in one translation unit but not known
>> in another.  A declaration like
>>
>>     extern int special_values[];
>>
>> offers partial but not complete type information in this TU, and
>> so is not known at compile time.
>
> What is "a real type", if there is such thing, is unknown, but
> what compiler think about the type when it deals with this
> specific translation unit is know.
>
>> A second example is variable length arrays.  Here the type
>> information is not known until run time, and usually is not fixed
>> but varies with different invocations.
>
> Here we are at philosophical question of "what is considered a
> type?".

There are two meanings of "type" that come into play here.  One
meaning is the type of an identifier (or an expression).  The
second meaning is the type of an object, irrespective of the type
of an expression used to designate the object.  These two
meanings are sometimes called "static type" and "dynamic type",
respectively.  Most of what I was pointing out is that the two
need not be the same, even if in most situations they are.

By the way I am sure that Ben Bacarisse knows all this.  I see in
a later response that his earlier posting was simplified for the
benefit of who he was responding to, and I misunderstood the
intended context of his statement.  Sorry for the confusion.

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

#149467

On Tue, 28 Jan 2020 19:19:38 -0800, T <T@invalid.invalid> wrote:

>Hi All,
>
>Trivia question:
>
>In C, after you declare a variable, is there a way
>to turn around and ask it what that variable is?
>
>Some thing like Raku's
>
>     > my uint $u; say $u.^name
>     Int
>
>only correct?


As Ben mentioned, there's no such feature in C.  Reflection was
considered for C++20, but was deferred until the next major revision.

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

#149469

On 2020-01-28 20:36, Robert Wessel wrote:
> On Tue, 28 Jan 2020 19:19:38 -0800, T <T@invalid.invalid> wrote:
> 
>> Hi All,
>>
>> Trivia question:
>>
>> In C, after you declare a variable, is there a way
>> to turn around and ask it what that variable is?
>>
>> Some thing like Raku's
>>
>>      > my uint $u; say $u.^name
>>      Int
>>
>> only correct?
> 
> 
> As Ben mentioned, there's no such feature in C.  Reflection was
> considered for C++20, but was deferred until the next major revision.
> 

Dang!

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

#149476

On 1/29/2020 5:55 AM, T wrote:
> On 2020-01-28 20:36, Robert Wessel wrote:
>> On Tue, 28 Jan 2020 19:19:38 -0800, T <T@invalid.invalid> wrote:
>>
>>> Hi All,
>>>
>>> Trivia question:
>>>
>>> In C, after you declare a variable, is there a way
>>> to turn around and ask it what that variable is?
>>>
>>> Some thing like Raku's
>>>
>>>      > my uint $u; say $u.^name
>>>      Int
>>>
>>> only correct?
>>
>>
>> As Ben mentioned, there's no such feature in C.  Reflection was
>> considered for C++20, but was deferred until the next major revision.
>>
> 
> Dang!

It may be worth noting (as Bart mentioned) that C has a static type 
system, so the type of each variable is always known. For this reason C 
does not need reflection.
The type system of C++ is statically checked as well, however, being 
considerably richer than C, it features RTTI, and may have some use for 
reflection. No urge for it though, as it can be deduced from Robert's 
comment.

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

#149480

On 29/01/2020 13:22, Manfred wrote:
> On 1/29/2020 5:55 AM, T wrote:
>> On 2020-01-28 20:36, Robert Wessel wrote:
>>> On Tue, 28 Jan 2020 19:19:38 -0800, T <T@invalid.invalid> wrote:
>>>
>>>> Hi All,
>>>>
>>>> Trivia question:
>>>>
>>>> In C, after you declare a variable, is there a way
>>>> to turn around and ask it what that variable is?
>>>>
>>>> Some thing like Raku's
>>>>
>>>>      > my uint $u; say $u.^name
>>>>      Int
>>>>
>>>> only correct?
>>>
>>>
>>> As Ben mentioned, there's no such feature in C.  Reflection was
>>> considered for C++20, but was deferred until the next major revision.
>>>
>>
>> Dang!
> 
> It may be worth noting (as Bart mentioned) that C has a static type
> system, so the type of each variable is always known. For this reason C
> does not need reflection.
> The type system of C++ is statically checked as well, however, being
> considerably richer than C, it features RTTI, and may have some use for
> reflection. No urge for it though, as it can be deduced from Robert's
> comment.

Actually, there are many good uses for reflection even in a statically
typed language.  In particular, it allows more generic coding.  A clear
example would be a JSON encoder/decoder - with reflection, you could
write templated functions that take a struct and do the encoding or
decoding, without needing the details of the type.  Another common
example would be matching database tables to type structures.

The two main reasons reflection haven't made it into C++ yet are not
about lack of interest, lack of use-cases, or lack of urgency in getting
it into the language.  The first reason is that it is hard to design the
feature - there are just so many complications and corner cases.  The
second is that the next big step is to combine it with code generation,
and even if that takes another few years to appear, it is important that
reflection is made in a way that will work with the code generation later.

But this is mainly a C++ idea - C does not have the same kind of generic
coding support.

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

#149495

On 1/29/2020 1:57 PM, David Brown wrote:
> On 29/01/2020 13:22, Manfred wrote:
>> On 1/29/2020 5:55 AM, T wrote:
>>> On 2020-01-28 20:36, Robert Wessel wrote:
>>>> On Tue, 28 Jan 2020 19:19:38 -0800, T <T@invalid.invalid> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Trivia question:
>>>>>
>>>>> In C, after you declare a variable, is there a way
>>>>> to turn around and ask it what that variable is?
>>>>>
>>>>> Some thing like Raku's
>>>>>
>>>>>       > my uint $u; say $u.^name
>>>>>       Int
>>>>>
>>>>> only correct?
>>>>
>>>>
>>>> As Ben mentioned, there's no such feature in C.  Reflection was
>>>> considered for C++20, but was deferred until the next major revision.
>>>>
>>>
>>> Dang!
>>
>> It may be worth noting (as Bart mentioned) that C has a static type
>> system, so the type of each variable is always known. For this reason C
>> does not need reflection.
>> The type system of C++ is statically checked as well, however, being
>> considerably richer than C, it features RTTI, and may have some use for
>> reflection. No urge for it though, as it can be deduced from Robert's
>> comment.
> 
> Actually, there are many good uses for reflection even in a statically
> typed language.  In particular, it allows more generic coding.  A clear
> example would be a JSON encoder/decoder - with reflection, you could
> write templated functions that take a struct and do the encoding or
> decoding, without needing the details of the type.
At first thought it looks like encoding is a possibility, but decoding 
would substantially require the struct to be assembled at runtime, i.e. 
dynamic type support, I believe.

   Another common
> example would be matching database tables to type structures.
Also requiring dynamic support as above.

Now, a runtime supporting dynamic type checking and reflection can be 
implemented in a statically typed language (in fact I believe that Java, 
C#, Perl and friends do implement it in C - or C++) so it may as well 
end up in the standard library at some point in some form.

When I wrote "some use" I was also thinking of e.g. template code that 
may enumerate members of a template argument (your JSON encoder). 
However a static type system cannot anticipate type information that is 
not available until run time (e.g. in a JSON stream), hence my tepid 
attitude.

> 
> The two main reasons reflection haven't made it into C++ yet are not
> about lack of interest, lack of use-cases, or lack of urgency in getting
> it into the language.  The first reason is that it is hard to design the
> feature - there are just so many complications and corner cases.  The
> second is that the next big step is to combine it with code generation,
> and even if that takes another few years to appear, it is important that
> reflection is made in a way that will work with the code generation later.

My thought is that it is going to require substantial runtime support 
anyway, and the similarity with GC comes to mind.

> 
> But this is mainly a C++ idea - C does not have the same kind of generic
> coding support.
> 

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

#149519

On 29/01/2020 17:47, Manfred wrote:
> On 1/29/2020 1:57 PM, David Brown wrote:
>> On 29/01/2020 13:22, Manfred wrote:
>>> On 1/29/2020 5:55 AM, T wrote:
>>>> On 2020-01-28 20:36, Robert Wessel wrote:
>>>>> On Tue, 28 Jan 2020 19:19:38 -0800, T <T@invalid.invalid> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Trivia question:
>>>>>>
>>>>>> In C, after you declare a variable, is there a way
>>>>>> to turn around and ask it what that variable is?
>>>>>>
>>>>>> Some thing like Raku's
>>>>>>
>>>>>>       > my uint $u; say $u.^name
>>>>>>       Int
>>>>>>
>>>>>> only correct?
>>>>>
>>>>>
>>>>> As Ben mentioned, there's no such feature in C.  Reflection was
>>>>> considered for C++20, but was deferred until the next major revision.
>>>>>
>>>>
>>>> Dang!
>>>
>>> It may be worth noting (as Bart mentioned) that C has a static type
>>> system, so the type of each variable is always known. For this reason C
>>> does not need reflection.
>>> The type system of C++ is statically checked as well, however, being
>>> considerably richer than C, it features RTTI, and may have some use for
>>> reflection. No urge for it though, as it can be deduced from Robert's
>>> comment.
>>
>> Actually, there are many good uses for reflection even in a statically
>> typed language.  In particular, it allows more generic coding.  A clear
>> example would be a JSON encoder/decoder - with reflection, you could
>> write templated functions that take a struct and do the encoding or
>> decoding, without needing the details of the type.
> At first thought it looks like encoding is a possibility, but decoding
> would substantially require the struct to be assembled at runtime, i.e.
> dynamic type support, I believe.

If you are thinking of decoding a JSON message and producing a matching
struct, then yes, that would need dynamic typing of some sort.  But it
is common to have incoming JSON messages where you know the structure
(or can quickly identify it) and you want to coerce it into an existing
struct type.  That can be done without dynamic typing.

> 
>   Another common
>> example would be matching database tables to type structures.
> Also requiring dynamic support as above.

Matching structs to existing tables requires dynamic typing - matching
tables to existing structs does not.

> 
> Now, a runtime supporting dynamic type checking and reflection can be
> implemented in a statically typed language (in fact I believe that Java,
> C#, Perl and friends do implement it in C - or C++) so it may as well
> end up in the standard library at some point in some form.

Yes.  It is questionable how useful it would be (compared to the
alternative of using hashmaps, vectors, variants, etc.) in a language
like C++.

> 
> When I wrote "some use" I was also thinking of e.g. template code that
> may enumerate members of a template argument (your JSON encoder).
> However a static type system cannot anticipate type information that is
> not available until run time (e.g. in a JSON stream), hence my tepid
> attitude.

Often you know exactly what should be in the incoming data - or at
least, you know about the parts that are interesting to you.  Your
parser would have to deal with missing data and extra data, of course.

> 
>>
>> The two main reasons reflection haven't made it into C++ yet are not
>> about lack of interest, lack of use-cases, or lack of urgency in getting
>> it into the language.  The first reason is that it is hard to design the
>> feature - there are just so many complications and corner cases.  The
>> second is that the next big step is to combine it with code generation,
>> and even if that takes another few years to appear, it is important that
>> reflection is made in a way that will work with the code generation
>> later.
> 
> My thought is that it is going to require substantial runtime support
> anyway, and the similarity with GC comes to mind.
> 
>>
>> But this is mainly a C++ idea - C does not have the same kind of generic
>> coding support.
>>
> 

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

#149486

Robert Wessel <robertwessel2@yahoo.com> writes:
>On Tue, 28 Jan 2020 19:19:38 -0800, T <T@invalid.invalid> wrote:
>
>>Hi All,
>>
>>Trivia question:
>>
>>In C, after you declare a variable, is there a way
>>to turn around and ask it what that variable is?
>>
>>Some thing like Raku's
>>
>>     > my uint $u; say $u.^name
>>     Int
>>
>>only correct?
>
>
>As Ben mentioned, there's no such feature in C.  Reflection was
>considered for C++20, but was deferred until the next major revision.

Although many compilers offer extensions, e.g. gcc's  typeof keyword.

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

#149489

On 1/29/2020 4:10 PM, Scott Lurndal wrote:
> Robert Wessel <robertwessel2@yahoo.com> writes:
>> On Tue, 28 Jan 2020 19:19:38 -0800, T <T@invalid.invalid> wrote:
>>
>>> Hi All,
>>>
>>> Trivia question:
>>>
>>> In C, after you declare a variable, is there a way
>>> to turn around and ask it what that variable is?
>>>
>>> Some thing like Raku's
>>>
>>>      > my uint $u; say $u.^name
>>>      Int
>>>
>>> only correct?
>>
>>
>> As Ben mentioned, there's no such feature in C.  Reflection was
>> considered for C++20, but was deferred until the next major revision.
> 
> Although many compilers offer extensions, e.g. gcc's  typeof keyword.
> 

typeof is more of use in macros (somewhat curiously Bart was mentioning 
_Generic also in the context of macros). It looks to me as being still 
quite far from actual reflection.

Something that may be close to what the OP is asking for is 
type_info::name() (still C++ though, however standard C++; also of more 
limited use in C++ than its counterpart in Perl)

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

#149470

In article <r0qtkb$3qj$1@dont-email.me>, T <T@invalid.invalid> 
wrote:

> Hi All,
> 
> Trivia question:
> 
> In C, after you declare a variable, is there a way
> to turn around and ask it what that variable is?
> 
> Some thing like Raku's
> 
>      > my uint $u; say $u.^name
>      Int
> 
> only correct?
> 
> Many thanks,
> -T

You should be able to compile your C with ObjC. ObjC has an 
@encode to return a string describing the compiled type.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
The first law of discordiamism: The more energy   This post         / \
to make order is nore energy made into entropy.   insults Islam.  Mohammed

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

#149474

On 29/01/2020 03:19, T wrote:
> Hi All,
> 
> Trivia question:
> 
> In C, after you declare a variable, is there a way
> to turn around and ask it what that variable is?
> 
> Some thing like Raku's
> 
>      > my uint $u; say $u.^name
>      Int
> 
> only correct?
> 
> Many thanks,
> -T
> 

Only in a limited way, eg: (macro copied from stackoverflow article):

#include <stdio.h>
#include <stddef.h>
#include <stdint.h>

#define typename(x) _Generic((x),\
   _Bool: "_Bool",\
   unsigned char: "unsigned char",          \
   char: "char",\
   signed char: "signed char",            \
   short int: "short int",\
   unsigned short int: "unsigned short int",     \
   int: "int",\
   unsigned int: "unsigned int",           \
   long int: "long int",\
   unsigned long int: "unsigned long int",      \
   long long int: "long long int",\
   unsigned long long int: "unsigned long long int", \
   float: "float",\
   double: "double",                 \
   long double: "long double",\
   char *: "pointer to char",        \
   void *: "pointer to void",\
   int *: "pointer to int",         \
  default: "other")

int main(void) {
   int a;
   float b;
   char* c;
   int d[10];

   printf("a is %s\n",typename(a));
   printf("b is %s\n",typename(b));
   printf("c is %s\n",typename(c));
   printf("d is %s\n",typename(d));
}

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

#149477

Printing the typename is almost useless.
Reflection is usually used for serialization,
and your example is far away from that.

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

#149479

On 29/01/2020 12:30, Bonita Montero wrote:
> Printing the typename is almost useless.
> Reflection is usually used for serialization,
> and your example is far away from that.

You have A which may be any of 8/16/32/64 bits, signed or unsigned.

And B which may also be any of those. Or maybe one is also a float.

What is the type of A+B or A/B? (Eg you need to know what print format 
to use.) Easier to just print the type than to try and figure it out.

More so on a much more complex expression, or one involving variables 
with opaque types.

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

#149481

> What is the type of A+B or A/B? (Eg you need to know what print format 
> to use.) Easier to just print the type than to try and figure it out.

Then I "use auto x = A / B" in C++ and use typeid(x).name(), that's much
more elegant than your macro-mess.

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

#149483

In article <r0rvra$v5$1@news.albasani.net>,
Bonita Montero  <Bonita.Montero@gmail.com> wrote:
>> What is the type of A+B or A/B? (Eg you need to know what print format 
>> to use.) Easier to just print the type than to try and figure it out.
>
>Then I "use auto x = A / B" in C++ and use typeid(x).name(), that's much
>more elegant than your macro-mess.

You seem to keep forgetting what newsgroup you are posting in.

I'd want to get this checked out.  Early onset Alzheimers, maybe?

-- 
Debating creationists on the topic of evolution is rather like trying to
play chess  with a pigeon  --- it knocks the  pieces over, craps  on the
board, and flies back to its flock to claim victory.

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

#149484

On 29/01/2020 13:03, Bonita Montero wrote:
>> What is the type of A+B or A/B? (Eg you need to know what print format 
>> to use.) Easier to just print the type than to try and figure it out.
> 
> Then I "use auto x = A / B" in C++ and use typeid(x).name(), that's much
> more elegant than your macro-mess.

I tried:

     int A; float B; int C; long long int D;
     int (*E)[];

     std::cout<<typeid(A+B).name() << std::endl;
     std::cout<<typeid(A+C).name() << std::endl;
     std::cout<<typeid(A+D).name() << std::endl;
     std::cout<<typeid(E).name() << std::endl;

(you don't need the intermediate variable.) It prints:

     f
     i
     x
     PA_i;

'x' for a long long int result? That is very mysterious.

This is how it works in my own language:

     int A; real32 B; int C; int128 D
     ref[]int E

     println (A+B).typestr
     println (A+C).typestr
     println (A+D).typestr
     println E.typestr

Output is

     r64
     i64
     i128
     ref [0]i64

Using more explicit (and normalised) type representations (which 
actually can be directly used in code).

As for C, my own C compiler allows this (non-standard extensions):

     int A; float B; int C; long long int D;
     int (*E)[];

     puts(strtype(typeof(A+B)));
     puts(strtype(typeof(A+C)));
     puts(strtype(typeof(A+D)));
     puts(strtype(typeof(E)));

Output:

     float
     int
     llong
     ref []int

Both working better out-of-the-box than your C++ solution. Compare these 
two lots of output with what C++ displays.

The C _Generic solution is messy, but no more so than your C++ templates.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web