Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Other Discussions
  3. The Weird and The Wonderful
  4. Iterating an Enum?

Iterating an Enum?

Scheduled Pinned Locked Moved The Weird and The Wonderful
question
6 Posts 3 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J Offline
    J Offline
    justastupidgurl
    wrote on last edited by
    #1

    Coding horror?

    private System.IO.Ports.StopBits stopBitsFromString(string stopBitsAsString)
    {
    System.IO.Ports.StopBits stopBits = StopBits.None;
    foreach (StopBits sb in Enum.GetValues(typeof(StopBits)))
    {
    if(sb.ToString()== stopBitsAsString)
    {
    return sb;
    }
    }
    return stopBits;
    }

    Is this better?

    private System.IO.Ports.StopBits stopBitsFromString2(string stopBitsAsString)
    {
    try
    {
    return (StopBits)Enum.Parse(typeof(StopBits), stopBitsAsString, true);
    }
    catch {return StopBits.None;}
    }

    JustAStupidGurl

    P 1 Reply Last reply
    0
    • J justastupidgurl

      Coding horror?

      private System.IO.Ports.StopBits stopBitsFromString(string stopBitsAsString)
      {
      System.IO.Ports.StopBits stopBits = StopBits.None;
      foreach (StopBits sb in Enum.GetValues(typeof(StopBits)))
      {
      if(sb.ToString()== stopBitsAsString)
      {
      return sb;
      }
      }
      return stopBits;
      }

      Is this better?

      private System.IO.Ports.StopBits stopBitsFromString2(string stopBitsAsString)
      {
      try
      {
      return (StopBits)Enum.Parse(typeof(StopBits), stopBitsAsString, true);
      }
      catch {return StopBits.None;}
      }

      JustAStupidGurl

      P Offline
      P Offline
      PIEBALDconsult
      wrote on last edited by
      #2

      Yes, and yes. But if you do that frequently, better to cache the names and values; may I suggest my EnumTransmogrifier[^]? And in the spirit of the season I won't complain about the multiple return statements. :-D

      J N 2 Replies Last reply
      0
      • P PIEBALDconsult

        Yes, and yes. But if you do that frequently, better to cache the names and values; may I suggest my EnumTransmogrifier[^]? And in the spirit of the season I won't complain about the multiple return statements. :-D

        J Offline
        J Offline
        justastupidgurl
        wrote on last edited by
        #3

        Well I've tried to stay out of that. I think it's a mistake to become obsessive about 'programming rules' in cases where they are of marginal benefit. There is of course a difference between this (the two returns are pretty obvious) and yards of obscure code salted with multiple return statements.

        JustAStupidGurl

        P 1 Reply Last reply
        0
        • J justastupidgurl

          Well I've tried to stay out of that. I think it's a mistake to become obsessive about 'programming rules' in cases where they are of marginal benefit. There is of course a difference between this (the two returns are pretty obvious) and yards of obscure code salted with multiple return statements.

          JustAStupidGurl

          P Offline
          P Offline
          PIEBALDconsult
          wrote on last edited by
          #4

          justastupidgurl wrote:

          There is of course a difference between this (the two returns are pretty obvious) and yards of obscure code salted with multiple return statements.

          Yes indeed. Definitely easier to take this way.

          1 Reply Last reply
          0
          • P PIEBALDconsult

            Yes, and yes. But if you do that frequently, better to cache the names and values; may I suggest my EnumTransmogrifier[^]? And in the spirit of the season I won't complain about the multiple return statements. :-D

            N Offline
            N Offline
            notmasteryet
            wrote on last edited by
            #5

            You are right. Building of lookup table improves performance.

                static Dictionary<string, StopBits> parsedStopBits = new Dictionary<string, StopBits>();
            
                static ClassName()
                {
                    foreach (StopBits sb in Enum.GetValues(typeof(StopBits)))
                    {
                        parsedStopBits.Add(sb.ToString(), sb);
                    }
                }
            
                static StopBits stopBitsFromString3(string stopBitsAsString) 
                { 
                    StopBits result; 
                    if (!parsedStopBits.TryGetValue(stopBitsAsString, out result)) 
                        result = StopBits.None;
                    return result;
                }
            

            Difference between performance of this code and Enum.Parse one is 10 times faster. Difference between perfromance of this code and horror one is 100 times faster. It is not multiple return you should worry about. It's try-catch. If non-enum value name will be passed in the stopBitsFromString2 function, it's performance will be the same as stopBitsFromString's. Knowing when not to use try-catch is priceless. :)

            modified on Monday, December 15, 2008 12:32 PM

            P 1 Reply Last reply
            0
            • N notmasteryet

              You are right. Building of lookup table improves performance.

                  static Dictionary<string, StopBits> parsedStopBits = new Dictionary<string, StopBits>();
              
                  static ClassName()
                  {
                      foreach (StopBits sb in Enum.GetValues(typeof(StopBits)))
                      {
                          parsedStopBits.Add(sb.ToString(), sb);
                      }
                  }
              
                  static StopBits stopBitsFromString3(string stopBitsAsString) 
                  { 
                      StopBits result; 
                      if (!parsedStopBits.TryGetValue(stopBitsAsString, out result)) 
                          result = StopBits.None;
                      return result;
                  }
              

              Difference between performance of this code and Enum.Parse one is 10 times faster. Difference between perfromance of this code and horror one is 100 times faster. It is not multiple return you should worry about. It's try-catch. If non-enum value name will be passed in the stopBitsFromString2 function, it's performance will be the same as stopBitsFromString's. Knowing when not to use try-catch is priceless. :)

              modified on Monday, December 15, 2008 12:32 PM

              P Offline
              P Offline
              PIEBALDconsult
              wrote on last edited by
              #6

              notmasteryet wrote:

              It is not multiple return you should worry about.

              That's about maintainability, not performance.

              notmasteryet wrote:

              Knowing when not to use try-catch is priceless

              Have you read this[^] article?

              1 Reply Last reply
              0
              Reply
              • Reply as topic
              Log in to reply
              • Oldest to Newest
              • Newest to Oldest
              • Most Votes


              • Login

              • Don't have an account? Register

              • Login or register to search.
              • First post
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • World
              • Users
              • Groups