Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched. Close

Is there any way to remove the warning for having two enumerators with the same value in the same enum?

Joan M
2016-12-21
2016-12-22
  • Joan M - 2016-12-21

    Hello all,

    Can I use any pragma to configure the compiler to avoid it to show a warning for having two enumerators with the same value?

    See:

    TYPE enumA :
    (
       FirstA := 0,
          A_1       := 0,
          A_2       := 1,
          A_3       := 2,
          A_4       := 3,
       LastA := 3
    );
    END_TYPE
    

    As you can see First and A_1 have the same value, also A_4 and Last.

    Doing that it makes it very easy to define arrays and to avoid those typical mistakes that happen when you change everything but the array declarations...

    anyway each time I compile it shows the warning and I'd love getting rid of that.

    PS: I've tried {warning disable C0125} but it has not worked.

    Thank you all.

     
  • Anonymous - 2016-12-21

    Originally created by: scott_cunningham

    First a suggestion following your idea - why not define like this:

    TYPE enumA :
    (
       A_START  := 0,
       A_1,
       A_2,
       A_3,
       A_4,
       A_END
    );
    END_TYPE
    

    You can still define your array like ARRAY[A_START..A_END] OF xxx... simply do not use array entries MyArray[A_Start] and MyArray[A_End]! Or, you can also declare this way: ARRAY[(A_START+1)..(A_END-1)] OF xxx. If you are using an enum for your array index, then it should not matter what "number" is behind the scenes...

    Another solution:

    TYPE enumA :
    (
       A_1    := 0,
       A_2    := 1,
       A_3    := 2,
       A_4    := 3
    );
    END_TYPE
    GVL_ARRAY
    VAR_GLOBAL CONSTANT
       FIRST_A : INT := enumA.A_1;
       LAST_A  : INT := enumA.A_4;
    END_VAR
    PROGRAM PLC_PRG
    VAR
       Test : ARRAY[GVL_ARRAY.FIRST_A..GVL_ARRAY.LAST_A] OF BOOL;
    END_VAR
    

    But this opens you up to forgetting to change the end limits...

    A comment about the enumeration as you have defined it... you may be better off just defining global constants where you can assign a value twice. If your enumeration list is long, then an enumeration fits better.

     
  • Joan M - 2016-12-21

    Thank you Scott,

    All your suggestions are valid, as always.

    The advantage of the method I'm using is that everything is inside the same enumeration and therefore any change there is harder to have strange effects outside.

    Shouldn't the {warning disable C0125} and the {warning restore C0125} work to avoid the compiler to cry about it?

    Something like:

    {attribute 'strict'}
    {warning disable C0125}
    TYPE enumCorteLongitudinalHerramientas :
    (
       PrimeraCuchilla := 0,
          Cuchilla_1       := 0,
          Cuchilla_2       := 1,
          Cuchilla_3       := 2,
          Cuchilla_4       := 3,
       UltimaCuchilla    := 3
    );
    {warning restore C0125}
    END_TYPE
    

    Of course I could uncheck the compiler warning for the project, but I'd love being able to be on the safe side and do it only when I'm aware of what I'm doing... (put any easy joke of your taste here I'm deserving it).

    PS: I've read and I understand all the proposed options, all are ok, but I'd love being able to avoid receiving the warning only. In the worst case I would try to find another way and probably putting the enum values as constants inside the program that is using them would be the chosen one.

    Thank you for your comments.

     
  • Anonymous - 2016-12-21

    Originally created by: scott_cunningham

    I also tried to disable the warning various ways before I created my alternatives... I've disabled other warnings, so I am a bit surprised (and not) that it doesn't work here. This may fall under the "ignore the pretty yellow circles" workflow.

     
  • Joan M - 2016-12-22

    Thank you Scott!

     

Log in to post a comment.