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

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

How do I set this type variable?

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

Contents

  How do I set this type variable? Thiago Adams <thiago.adams@gmail.com> - 2016-09-16 13:08 -0700
    Re: How do I set this type variable? BartC <bc@freeuk.com> - 2016-09-16 21:40 +0100
      Re: How do I set this type variable? Thiago Adams <thiago.adams@gmail.com> - 2016-09-16 13:57 -0700
        Re: How do I set this type variable? Thiago Adams <thiago.adams@gmail.com> - 2016-09-16 14:07 -0700
        Re: How do I set this type variable? jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-16 23:32 +0200
          Re: How do I set this type variable? Thiago Adams <thiago.adams@gmail.com> - 2016-09-17 12:05 -0700
            Re: How do I set this type variable? BartC <bc@freeuk.com> - 2016-09-17 20:46 +0100
      Re: How do I set this type variable? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-17 17:19 -0700
        Re: How do I set this type variable? supercat@casperkitty.com - 2016-09-17 22:47 -0700
          Re: How do I set this type variable? luser droog <luser.droog@gmail.com> - 2016-09-18 13:44 -0700
          Re: How do I set this type variable? Ian Collins <ian-news@hotmail.com> - 2016-09-19 17:00 +1200
            Re: How do I set this type variable? David Brown <david.brown@hesbynett.no> - 2016-09-19 09:34 +0200
              Re: How do I set this type variable? supercat@casperkitty.com - 2016-09-19 08:18 -0700
    Re: How do I set this type variable? Richard Damon <Richard@Damon-Family.org> - 2016-09-23 12:07 -0400
      Re: How do I set this type variable? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 11:57 -0700

#93660 — How do I set this type variable?

typedef enum {
  BananaType,
} Type;

typedef struct
{
  const Type type;
} Banana;


 Banana* pBanana = malloc(sizeof *pBanana);

 pBanana->type = BananaType; //<-- ??


But I want Type const by design. So I think the problem is worst.


typedef const enum {
  BananaType,
} Type;

typedef struct
{
  Type type;
} Banana;

 Banana* pBanana = malloc(sizeof *pBanana);

 pBanana->type = BananaType; //<-- ??

[toc] | [next] | [standalone]

#93666

On 16/09/2016 21:08, Thiago Adams wrote:
> typedef enum {
>   BananaType,
> } Type;
>
> typedef struct
> {
>   const Type type;
> } Banana;
>
>
>  Banana* pBanana = malloc(sizeof *pBanana);
>
>  pBanana->type = BananaType; //<-- ??
>
>
> But I want Type const by design. So I think the problem is worst.

Take care that you don't get so overzealous with adding 'const' 
everywhere that you tie yourself up in knots.

With your example, if Banana is immutable, then once initialised you 
will probably want all Banana data const too. But life will quickly 
become difficult.

I suggest keeping 'const' out of these structs. If you have to, use a 
const pointer to them when passing them to functions.

-- 
bartc

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

#93667

On Friday, September 16, 2016 at 5:40:37 PM UTC-3, Bart wrote:
> On 16/09/2016 21:08, Thiago Adams wrote:
> > typedef enum {
> >   BananaType,
> > } Type;
> >
> > typedef struct
> > {
> >   const Type type;
> > } Banana;
> >
> >
> >  Banana* pBanana = malloc(sizeof *pBanana);
> >
> >  pBanana->type = BananaType; //<-- ??
> >
> >
> > But I want Type const by design. So I think the problem is worst.
> 
> Take care that you don't get so overzealous with adding 'const' 
> everywhere that you tie yourself up in knots.
> 
> With your example, if Banana is immutable, then once initialised you 
> will probably want all Banana data const too. But life will quickly 
> become difficult.

No, just the type is immutable. The banana can change its color but it is always banana, so the type is immutable.
If I have a tree of bananas then I think all tree const is useful because I can run multiples algorithms in parallel using the tree at the same time and its thread safe.
But the tree type will be qualified const on the argument for algorithms.

Analyse(const BananaTree * );
MakeBananaTree(BananaTree * )

I qualified const the typedef "Type" because I will use variables "type" just immutable values.

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

#93668

> > Take care that you don't get so overzealous with adding 'const' 
> > everywhere that you tie yourself up in knots.

I understand what you are saying. 
I also don't like too much protection machinery.

I have used javascript recently to create web clients.
Then I change some code to use Typescript (that is a typed version of javascript). "thanks god for creating typed checked languages!" 

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

#93671

Le 16/09/2016 à 22:57, Thiago Adams a écrit :
> If I have a tree of bananas then I think all tree const is useful because

I can run multiples algorithms in parallel using the tree at the same 
time and its thread safe.

If the tree doesn't change, yes, it is immutable

:-)

If no thread modifies the tree, it is thread safe since the data is 
parallel.

But if you run an algorithm, is to find out something about the data 
isn't it? How do you add information to a const tree? Difficult.

Yes, you can do a separation between added data (calculated) and 
original data (const).

Or, you do not modify the tree and rebuild a new non const tree with the 
new calculated data for each node.

The type is no longer const since you can have either a const or non 
const tree of the same shape.

There are many solutions and what is important is to try to be aware of 
the practical problems, the compiler and the computer language used are 
just aid/nuisance whatever.

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

#93686

On Friday, September 16, 2016 at 6:32:10 PM UTC-3, jacobnavia wrote:
> Le 16/09/2016 à 22:57, Thiago Adams a écrit :
> > If I have a tree of bananas then I think all tree const is useful because
> 
> I can run multiples algorithms in parallel using the tree at the same 
> time and its thread safe.
> 
> If the tree doesn't change, yes, it is immutable
> 
> :-)
> 
> If no thread modifies the tree, it is thread safe since the data is 
> parallel.
> 
> But if you run an algorithm, is to find out something about the data 
> isn't it? How do you add information to a const tree? Difficult.
> 
> Yes, you can do a separation between added data (calculated) and 
> original data (const).
> 
> Or, you do not modify the tree and rebuild a new non const tree with the 
> new calculated data for each node.
> 
> The type is no longer const since you can have either a const or non 
> const tree of the same shape.
> 
> There are many solutions and what is important is to try to be aware of 
> the practical problems, the compiler and the computer language used are 
> just aid/nuisance whatever.


On Friday, September 16, 2016 at 6:32:10 PM UTC-3, jacobnavia wrote:
> Le 16/09/2016 à 22:57, Thiago Adams a écrit :
> > If I have a tree of bananas then I think all tree const is useful because
> 
> I can run multiples algorithms in parallel using the tree at the same 
> time and its thread safe.
> 
> If the tree doesn't change, yes, it is immutable
> 
> :-)
> 
> If no thread modifies the tree, it is thread safe since the data is 
> parallel.
> 
> But if you run an algorithm, is to find out something about the data 
> isn't it? How do you add information to a const tree? Difficult.
> 
> Yes, you can do a separation between added data (calculated) and 
> original data (const).
> 
> Or, you do not modify the tree and rebuild a new non const tree with the 
> new calculated data for each node.
> 
> The type is no longer const since you can have either a const or non 
> const tree of the same shape.
> 
> There are many solutions and what is important is to try to be aware of 
> the practical problems, the compiler and the computer language used are 
> just aid/nuisance whatever.

In my case, I will build the tree first, and then run algorithms without change it any more. (tree is parser AST)
I known, some parsers need to build and change the AST while we type in the IDE. (That is not my case for now)

I realized that the problem with const and my tree is worst than that.
When we add the const qualifier for a struct, and this struct has pointers too (my case), then content of these pointers are not const, so it doesn't help too much.

Sample:

typedef struct {  int i; } Child1;
typedef struct { Child1* child1; } Tree;

int main()
{
    Child1 child1;
    Tree tree;
    tree.child1 = &child1;
    
    const Tree* pTree = &tree;
    pTree->child1->i = 1; //ok, works
    return 0;
}

So in this case, everything should be const. But, at some point I need to build the tree.

Const in a variable, as you pointed out, doesn't mean immutable.
To archive immutability in C/C++ the best thing is qualify everything const in a type. 

Sample:

typedef const struct
{
    int x;
    int y;
} Vector;

Vector Sum(Vector* v1, Vector* v2)
{
    return (Vector) { v1->x + v2->x, v1->y + v2->y };
}

int main()
{
    Vector v1 = { 1, 3 };
    Vector v2 = { 2, 4 };
    Vector v3 = Sum(&v1, &v2);
}

I will do some experiments now, but probably I will keep the final code without consts. 
Let´s see. 

The solution for my question, probability is a memcopy from stack object to heap.

for instance, for this Vector sample:

    Vector * pVec = malloc(sizeof * pVec);    
    memcpy((void*)pVec, &v3, sizeof *pVec);


So, C now has very sophisticated ways to initialize objects on the stack, but for the heap the problem still there.

One option could be
    
    Vector * pVec2 = memcpy(malloc(sizeof * pVec),
                            &((Vector) { 1, 2 }),
                            sizeof *pVec);

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

#93688

On 17/09/2016 20:30, Stefan Ram wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> So in this case, everything should be const. But, at some
>> point I need to build the tree.
>
>   You can build a struct and then make it const.
>   The client will not be able to change the struct.
>
> #include <stdio.h>
>
> struct s { int i; };
>
> struct s constructor(){ struct s s; s.i = 2; return s; }
>
> void client( struct s const c )
> { /* c.i = 3; /* assignment of member 'i' in read-only object */
>   printf( "%d\n", c.i ); }
>
> int main( void )
> { struct s const c = constructor();
>   client( c ); }

But in this example, it wouldn't matter if client() changed the struct, 
as it would be doing so in its own copy.

-- 
Bartc

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

#93718

On Friday, September 16, 2016 at 9:40:37 PM UTC+1, Bart wrote:
> 
> > But I want Type const by design. So I think the problem is worst.
> 
> Take care that you don't get so overzealous with adding 'const' 
> everywhere that you tie yourself up in knots.
> 
> With your example, if Banana is immutable, then once initialised you 
> will probably want all Banana data const too. But life will quickly 
> become difficult.
> 
> I suggest keeping 'const' out of these structs. If you have to, use a 
> const pointer to them when passing them to functions.
> 
You have two policies. One is "const correctness", whereby everything
is const unless the function actually needs to change it. The
other is rigorous elimination and deprecation of const as an
undesirable programming construct.

The problems are created in between. However const correctness
creates complication after complication. For example early C++
compiler allowed operator overloading so you could implement a
"safe array". Great fun. But what when the array is const? Now
does the return by reference propagate the constness? The C++
rules get more and more convoluted and elaborate to deal with
that sort of thing. Nowadays you can end up binding two entirely
different functions because of a const keyword, and it's no
longer true that a correct program cannot be made incorrect by
removing const. Nightmare.

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

#93723

On Saturday, September 17, 2016 at 7:19:21 PM UTC-5, Malcolm McLean wrote:
> You have two policies. One is "const correctness", whereby everything
> is const unless the function actually needs to change it. The
> other is rigorous elimination and deprecation of const as an
> undesirable programming construct.
> 
> The problems are created in between.

Many programming languages fail to recognize the concepts of a readable
pointer, a read-only pointer, and a pointer to an immutable object.  All
three of them could be characterized as a "SomeType const *", but they
should have distinct meanings.

Some libraries accept pointers from client code and later give those same
pointers back to client code.  The libraries won't write through the 
pointers, but won't care if client code does so with the originals or the
passed-back copies.  Such pointers should be "readable".

Some libraries accept pointers from client code and pass them on to other
code, and the copies of the pointers should never be written through.  The
supplier of the pointers, however, may retain the right to write through
them, especially after the called function returns.  Such pointers should
be "read-only".

Some libraries may cache information read through pointers they receive,
and may malfunction if any code ever writes through them.  The targets of
such pointers should be "immutable".

Some ambiguities with pointer qualifiers could be resolved by having a
"return" qualifier, such that e.g.

    char *strchr(char return const *src, int match);

would indicate that if the first past argument has a const qualifier,
the return value should be regarded as having one also, but if the
source argument does not have one, the return value shouldn't either.
Had such a qualifier been available when strchr was defined, that would
have avoided a lot of difficulties with functions like strchr.  It would
not solve all such difficulties, especially in cases where a library
needs to store passed-in pointers between function calls, but it would
have helped many.

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

#93757

On Sunday, September 18, 2016 at 12:48:12 AM UTC-5, supe...@casperkitty.com wrote:
> On Saturday, September 17, 2016 at 7:19:21 PM UTC-5, Malcolm McLean wrote:
> > You have two policies. One is "const correctness", whereby everything
> > is const unless the function actually needs to change it. The
> > other is rigorous elimination and deprecation of const as an
> > undesirable programming construct.
> > 
> > The problems are created in between.
> 
> Many programming languages fail to recognize the concepts of a readable
> pointer, a read-only pointer, and a pointer to an immutable object.  All
> three of them could be characterized as a "SomeType const *", but they
> should have distinct meanings.
> 
> Some libraries accept pointers from client code and later give those same
> pointers back to client code.  The libraries won't write through the 
> pointers, but won't care if client code does so with the originals or the
> passed-back copies.  Such pointers should be "readable".
> 
> Some libraries accept pointers from client code and pass them on to other
> code, and the copies of the pointers should never be written through.  The
> supplier of the pointers, however, may retain the right to write through
> them, especially after the called function returns.  Such pointers should
> be "read-only".
> 
> Some libraries may cache information read through pointers they receive,
> and may malfunction if any code ever writes through them.  The targets of
> such pointers should be "immutable".
> 
> Some ambiguities with pointer qualifiers could be resolved by having a
> "return" qualifier, such that e.g.
> 
>     char *strchr(char return const *src, int match);
> 
> would indicate that if the first past argument has a const qualifier,
> the return value should be regarded as having one also, but if the
> source argument does not have one, the return value shouldn't either.
> Had such a qualifier been available when strchr was defined, that would
> have avoided a lot of difficulties with functions like strchr.  It would
> not solve all such difficulties, especially in cases where a library
> needs to store passed-in pointers between function calls, but it would
> have helped many.

Excellent. Parsimonious!
Superlative feline.

-- 
treats and tummy-rub!

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

#93775

On 09/18/16 05:47 PM, supercat@casperkitty.com wrote:
> On Saturday, September 17, 2016 at 7:19:21 PM UTC-5, Malcolm McLean wrote:
>> You have two policies. One is "const correctness", whereby everything
>> is const unless the function actually needs to change it. The
>> other is rigorous elimination and deprecation of const as an
>> undesirable programming construct.
>>
>> The problems are created in between.
>
> Many programming languages fail to recognize the concepts of a readable
> pointer, a read-only pointer, and a pointer to an immutable object.  All
> three of them could be characterized as a "SomeType const *", but they
> should have distinct meanings.
>
> Some libraries accept pointers from client code and later give those same
> pointers back to client code.  The libraries won't write through the
> pointers, but won't care if client code does so with the originals or the
> passed-back copies.  Such pointers should be "readable".
>
> Some libraries accept pointers from client code and pass them on to other
> code, and the copies of the pointers should never be written through.  The
> supplier of the pointers, however, may retain the right to write through
> them, especially after the called function returns.  Such pointers should
> be "read-only".
>
> Some libraries may cache information read through pointers they receive,
> and may malfunction if any code ever writes through them.  The targets of
> such pointers should be "immutable".
>
> Some ambiguities with pointer qualifiers could be resolved by having a
> "return" qualifier, such that e.g.
>
>      char *strchr(char return const *src, int match);
>
> would indicate that if the first past argument has a const qualifier,
> the return value should be regarded as having one also, but if the
> source argument does not have one, the return value shouldn't either.
> Had such a qualifier been available when strchr was defined, that would
> have avoided a lot of difficulties with functions like strchr.  It would
> not solve all such difficulties, especially in cases where a library
> needs to store passed-in pointers between function calls, but it would
> have helped many.

Function overloading is a more elegant solution for this.

-- 
Ian

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

#93779

On 19/09/16 07:00, Ian Collins wrote:
> On 09/18/16 05:47 PM, supercat@casperkitty.com wrote:
>> On Saturday, September 17, 2016 at 7:19:21 PM UTC-5, Malcolm McLean
>> wrote:
>>> You have two policies. One is "const correctness", whereby everything
>>> is const unless the function actually needs to change it. The
>>> other is rigorous elimination and deprecation of const as an
>>> undesirable programming construct.
>>>
>>> The problems are created in between.
>>
>> Many programming languages fail to recognize the concepts of a readable
>> pointer, a read-only pointer, and a pointer to an immutable object.  All
>> three of them could be characterized as a "SomeType const *", but they
>> should have distinct meanings.
>>
>> Some libraries accept pointers from client code and later give those same
>> pointers back to client code.  The libraries won't write through the
>> pointers, but won't care if client code does so with the originals or the
>> passed-back copies.  Such pointers should be "readable".
>>
>> Some libraries accept pointers from client code and pass them on to other
>> code, and the copies of the pointers should never be written through. 
>> The
>> supplier of the pointers, however, may retain the right to write through
>> them, especially after the called function returns.  Such pointers should
>> be "read-only".
>>
>> Some libraries may cache information read through pointers they receive,
>> and may malfunction if any code ever writes through them.  The targets of
>> such pointers should be "immutable".
>>
>> Some ambiguities with pointer qualifiers could be resolved by having a
>> "return" qualifier, such that e.g.
>>
>>      char *strchr(char return const *src, int match);
>>
>> would indicate that if the first past argument has a const qualifier,
>> the return value should be regarded as having one also, but if the
>> source argument does not have one, the return value shouldn't either.
>> Had such a qualifier been available when strchr was defined, that would
>> have avoided a lot of difficulties with functions like strchr.  It would
>> not solve all such difficulties, especially in cases where a library
>> needs to store passed-in pointers between function calls, but it would
>> have helped many.
> 
> Function overloading is a more elegant solution for this.
> 

In C, you have:

	char *strchr(const char *s, int c);

In C++, function overloading means you have:

	const char* strchr(const char* s, int c);
	char* strchr(char* s, int c);

Function overloading gives you a const-safe system for this, but it is
/not/ elegant in cases like this.  In particular, it is pure code
duplication - the bodies of the two functions will be identical except
for the "const".  That means either you write two copies of the
function, or you use templates (with extra code to limit it to just
these two types), or you have to write a wrapper function with
const_cast for one of them.

With Supercat's idea, you could have just one function

	char* strchr(return_const char* src, int c);

One function declaration, one function definition, and const consistency
and safety.

I am sure the details would get complicated (in either C or C++), but
the idea is not bad at all.

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

#93806

On Monday, September 19, 2016 at 2:34:55 AM UTC-5, David Brown wrote:
> With Supercat's idea, you could have just one function
> 
> 	char* strchr(return_const char* src, int c);
> 
> One function declaration, one function definition, and const consistency
> and safety.
> 
> I am sure the details would get complicated (in either C or C++), but
> the idea is not bad at all.

It would be an improvement over the present semantics, but it still
wouldn't handle all cases.  For practicality, there would still need to
be types which can accept pointers to "const"-qualified objects, but
which would not forbid objects from being in written in cases where
user code knew, via whatever means, that the objects in question weren't
subject to a "const" restriction.  On the other hand, the "return const"
syntax would probably eliminate 90%+ of the need for such types.

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

#93954

On 9/16/16 4:08 PM, Thiago Adams wrote:
> typedef enum {
>   BananaType,
> } Type;
>
> typedef struct
> {
>   const Type type;
> } Banana;
>
>
>  Banana* pBanana = malloc(sizeof *pBanana);
>
>  pBanana->type = BananaType; //<-- ??
>
>
> But I want Type const by design. So I think the problem is worst.
>
>
> typedef const enum {
>   BananaType,
> } Type;
>
> typedef struct
> {
>   Type type;
> } Banana;
>
>  Banana* pBanana = malloc(sizeof *pBanana);
>
>  pBanana->type = BananaType; //<-- ??
>
>
>

I would have to check if this is valid C code, because as you have 
found, it would be hard to use a const member of a struct. In C++, you 
have a constructor to initialize the value, and thus set the member. In 
C, if it allows const members, the only time you would be able to set 
that member would be a declaration/initialization time, something like

Banana banana = {BananaType]:

The big issue here as that for heap based objects, there isn't any such 
definition so no opportunity for such an initialization.

If C does allow for Banana to be declared something like

typedef struct {
   const Type type;
}  Banana;


(I am not sure it does, an implementation that also support C++ might 
allow it as an extension)

Then you could use a union like:

union BananaOrType {
   Type type;
   Banana banana;
}

union BananaOrType * bort = malloc(sizeof BananaOrType);
bort->type = BananaType;

pBanana = &bort->banana;

THis does run slightly afoul of the aliasing rules, so a 
hyper-optimizing compiler might be able to mess you up (so make sure you 
turn off hyper-optimization for this bit of code), as const Type and 
Type are not identical common initial sequences.

You could also use a hack of taking the address of the type field, and 
cast away the const and write to it, again, this is technically 
undefined behavior, so avoid hyper-optimizations in this area.

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

#93962

Richard Damon <Richard@Damon-Family.org> writes:

> On 9/16/16 4:08 PM, Thiago Adams wrote:
> [how may one initialize a const member of a struct, where the
>  struct has been dynamically allocated]
>
> If C does allow for Banana to be declared something like
>
> typedef struct {
>   const Type type;
> }  Banana;
>
>
> (I am not sure it does, [...])

Yes, this is allowed.

> Then you could use a union like:
>
> union BananaOrType {
>   Type type;
>   Banana banana;
> }
>
> union BananaOrType * bort = malloc(sizeof BananaOrType);
> bort->type = BananaType;
>
> pBanana = &bort->banana;
>
> THis does run slightly afoul of the aliasing rules, [...]

Does it?  Can you be more specific about which rule you think is
violated (or which non-constraint "shall" requirement is not met)?

[toc] | [prev] | [standalone]

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

csiph-web