Create an object to call a static method



  • Found while perusing my company intranet's codebase:

    // create a User object to make a static method call
    User gt = new User();
    List<Int32> TRAVELING = gt.GetTraveling();

    I checked, User.GetTravelling() is not a static method, but does not access any instance fields, properties or methods. I changed it to a static and everything worked fine. (aside from fixing the other 45 places where this method was being called in exactly the same manner)



  • Oh shit!  I just hope for your sake that hoodaticus doesn't see this post or he'll get all OOP on your ass.



  • You've now just broken TravelingUser.getTraveling()



  • @C-Octothorpe said:

    Oh shit!  I just hope for your sake that hoodaticus doesn't see this post or he'll get all OOP on your ass.

    He'll unleash a can of OOP == ass?



  • @pkmnfrk said:

    @C-Octothorpe said:

    Oh shit!  I just hope for your sake that hoodaticus doesn't see this post or he'll get all OOP on your ass.

    He'll unleash a can of OOP == ass?

    That's how it's pronounced?  Here I am enunciating three syllables like a sucker...

    BTW-I haven't seen hoodacticus around here for a while.



  • @Sutherlands said:

    You've now just broken TravelingUser.getTraveling()

    That's the TRWTF.  Refactoring that breaks everything isn't refactoring at all...



  • @frits said:

    @pkmnfrk said:

    @C-Octothorpe said:

    Oh shit!  I just hope for your sake that hoodaticus doesn't see this post or he'll get all OOP on your ass.

    He'll unleash a can of OOP == ass?

    That's how it's pronounced?  Here I am enunciating three syllables like a sucker...

    BTW-I haven't seen hoodacticus around here for a while.

    I'm guessing @pkmnfrk is pronouncing is as "(wh)oop-ass"...

    I just threw his name in there because doing so might summon him.



  • @C-Octothorpe said:

    @frits said:

    @pkmnfrk said:

    @C-Octothorpe said:

    Oh shit!  I just hope for your sake that hoodaticus doesn't see this post or he'll get all OOP on your ass.

    He'll unleash a can of OOP == ass?

    That's how it's pronounced?  Here I am enunciating three syllables like a sucker...

    BTW-I haven't seen hoodacticus around here for a while.

    I'm guessing @pkmnfrk is pronouncing is as "(wh)oop-ass"...

    I just threw his name in there because doing so might summon him.

    I don't think that's how this software "works" (CS amirite?). The constant emails every time I post, however...



  • <font face="Times">

    Just because I'm an ignoramus, a "static method" is (supposed to be) a class method which can be called without requiring an object that instantiates the class, correct?

    I've actually got to ask a question, though, because I'm not sure I understand the philosophy behind it: if you have a function which does not require an instantiation of the class, why is that function part of the class and not part of the thing in which instances of that class are used?  Is this purely for organization purposes?

    The only time which I can think this might be useful is if you have parameters associated with the class itself, such as things which may configure how objects are created by a constructor.  But this gets a little strange in my mind, because then the class itself has some kind of variables, which means the class itself is an instantiated object? Doesn't this blur the line between a class and object which instantiates a class?  Is this the situation which caused the Factory pattern to emerge?  Do androids, in fact, dream of electric sheep?

    </font>


  • @too_many_usernames said:

    Just because I'm an ignoramus, a "static method" is (supposed to be) a class method which can be called without requiring an object that instantiates the class, correct?
    Well it's "always going to execute the same regardless of the state of the object" but your definition is more practical.@too_many_usernames said:
    I've actually got to ask a question, though, because I'm not sure I understand the philosophy behind it: if you have a function which does not require an instantiation of the class, why is that function part of the class and not part of the thing in which instances of that class are used?  Is this purely for organization purposes?
    Yeah, sure. 

    Usually when I use static methods, it's because I'm calling things from PSVM() which by definition is static, so it can't call any instance methods without instantiating itself, which is pretty useless.  Occasionally, there's something that's static because it doesn't actually use any instance variables, and I make such a thing static for the reason you mention.



  • Static methods are methods that do not require an object instance, either because they do not operate on any particular object or because they modify global state or whatever.

    In this case, the User.GetTravelling() method queries the database to find users which are travelling. The reason it is static on the User class is because:

    • It is a data access method, which means it belongs in the model somewhere, not on a page controller, and
    • It returns a list of Users (actually, integers? Hmm, I should investigate this further, but that's a separate issue) and operates on the User table, thus it belongs in the User class.

    So, code organization and code reuse.



  • @too_many_usernames said:

    <FONT face=Times>  part of the thing in which instances of that class are used

    </FONT>
    I would try to answer your question if I understood what this meant.



  • @Southerlands said:

    I would try to answer your question if I understood what this meant.

    Hopefully this will help.

    @pkmnfrk said:

    In this case, the User.GetTravelling() method queries the database to find users which are travelling. The reason it is static on the User class is because:

    • It is a data access method, which means it belongs in the model somewhere, not on a page controller, and
    • It returns a list of Users (actually, integers? Hmm, I should investigate this further, but that's a separate issue) and operates on the User table, thus it belongs in the User class.

    So, code organization and code reuse.

     

    I would question (in the sense of "bring up for discussion" rather than "suspicion") the rationale described by pkmnfrk for the following reasons:

    • The concept of "list of traveling users" is a concept outside a User, because it's possible to have a list of things other than users.
    • To expand on the above point, "Give me a list of traveling users" is a function you'd ask of an object which can contain lists, not something you'd ask of an object contained in that list.
    • What about systems in which you might have user objects, but don't need a list of which ones are traveling? This suggests to me that the concept of the list belongs outside the listable object.
    • I might be confusing what is represented by the User class; if that class is representing the table then the function is appropriate, but I'd envision you instantiating an object of that class to represent the table.  If the User class represents user objects then I don't think the list function is appropriate.  Said (hopefully) more concisely: I would build a UserTable class, which has a function getTraveling, that returns a list of all traveling users.


  • @too_many_usernames said:

    • To expand on the above point, "Give me a list of traveling users" is a function you'd ask of an object which can contain lists, not something you'd ask of an object contained in that list.
    • What about systems in which you might have user objects, but don't need a list of which ones are traveling? This suggests to me that the concept of the list belongs outside the listable object.
    • I might be confusing what is represented by the User class; if that class is representing the table then the function is appropriate, but I'd envision you instantiating an object of that class to represent the table.  If the User class represents user objects then I don't think the list function is appropriate.  Said (hopefully) more concisely: I would build a UserTable class, which has a function getTraveling, that returns a list of all traveling users.

    Static methods or data in OOP code are like side effects in functional code: Real world needs that don't fit with the pure concept. When you start talking like this, you're wasting your time, and might as well wonder who shaves the barber.



  • @too_many_usernames said:

    • The concept of "list of traveling users" is a concept outside a User, because it's possible to have a list of things other than users.
    • To expand on the above point, "Give me a list of traveling users" is a function you'd ask of an
      object which can contain lists, not something you'd ask of an object
      contained in that list.
    • What about systems in which you might have user objects, but don't need a list of which ones are traveling? This suggests to me that the concept of the list belongs outside the listable object.
    • I might be confusing what is represented by the User class; if that class is representing the table then the function is appropriate, but I'd envision you instantiating an object of that class to represent the table.  If the User class represents user objects then I don't think the list function is appropriate.  Said (hopefully) more concisely: I would build a UserTable class, which has a function getTraveling, that returns a list of all traveling users.

    I think you're overthinking it.

    That said, in a situation like this I usually make a User class, and a UserUtils static class, and put all the static shit in the latter. BUT, mixing static and non-static functions is a long-standing tradition in C# and the .net libraries, so the way they've done it doesn't bother me at all.


  • Discourse touched me in a no-no place

    @boomzilla said:

    and might as well wonder who shaves the barber.
    No-one shaves her - the husband likes hairy 'pits.



  •  In some languages (e.g. Python) a class is an object that can have its own properties independent of the properties of its instances.  For a particularly pointless example:

    class Foo(object):
      multiplier = 2
      
      def __init__(self, bar):
        self.bar = bar
    
      @classmethod # equivalent of static
      def get_multiplier(cls):
        return cls.multiplier
      
      # instance method
      def add_to_bar(self, value_to_add):
        self.bar = bar + (value_to_add * self.multiplier)
    
    
    class SuperFoo(object):
      multiplier = 6
    
      def __init__(self, bar, baz):
        super(BlahFoo, self.).__init__(bar)
        self.baz = baz
    

    Basically, handy for polymorphism.



  • Yes... that's a static member...



  • @blakeyrat said:

    I think you're overthinking it.
     

    "Overthinking things" is one of the skills I have highighted in my company's skills matrix. (Yes, we really have one of those.  It's frightening.)

    @blakeyrat said:

    would you really put every function that returns lists in to a big old StaticListGetter class?

    No, I would attempt to actually think about what the context of getting those lists is, and put them in a class appropriate to that.  More specifically, I would probably put the function in a class that defined the entity which actually stores the list data; e.g., Database.getTravelingUserList. or MemoryMap.getTravelingUserList or Secretary.getTravelingUserList.



  • Static methods can access Class properties ... right?



  •  While I generally end up with a UserList kind of class to instantiate collections of users as, I still tend to find one or two static methods lurking in the User class: typically these are methods that relate specifically to Users without relating specifically to a [i]particular[/i] User - and don't relate to collections of users. If the method describes some symmetrical relation between two Users, for example; it doesn't apply to either User more than the other, so there's no justification for favouring either with the instance method.



  • @too_many_usernames said:

    I've actually got to ask a question, though, because I'm not sure I understand the philosophy behind it: if you have a function which does not require an instantiation of the class, why is that function part of the class and not part of the thing in which instances of that class are used? Is this purely for organization purposes?

    Because classes in OOP serve two unrelated purposes. As data types and as modules. No, it does not really make sense, though it usually more or less works.

    In fact the unrelated purposes are actually three. Data types, interfaces and modules. You can see this when you try to match the concepts from say Java to language that has these concepts separate like Haskell (which is functional) or Go (which is mostly OO, but separates these concepts). @too_many_usernames said:

    The only time which I can think this might be useful is if you have parameters associated with the class itself, such as things which may configure how objects are created by a constructor. But this gets a little strange in my mind, because then the class itself has some kind of variables, which means the class itself is an instantiated object?

    Yes, in most OO languages the class is an object itself, usually called meta-object. In case of Java it has type java.lang.Class. C++ is an exception where the static members are instantiated separately with no runtime representation of the class itself.

    @too_many_usernames said:

    Doesn't this blur the line between a class and object which instantiates a class? Is this the situation which caused the Factory pattern to emerge?

    Well, somewhat. Meta-objects don't exist in some languages, e.g. C++ where while classes do double as types and modules, these roles are implemented differently. However there are some languages that removed the distinction and simply have a parent object. That called "prototype-based inheritance" and most famous language using it is ECMAScript, more commonly known as JavaScript.

    PS: Don't use <font face="Times">font face</font>, it looks <font face="Comic Sans MS">ugly</font>.



  • I've seen this before. I had a C# library where everything was exposed via interfaces. I needed some methods that would have been best as static methods, but because you can't have static methods in an interface they had to be instance methods.

    Here's the kind of scenario we had:

    
    T Foo<T>(int id) where T : IBaseInterface, new
    {
        T instance = new T();
        //here we have to call the interface method
        T result = instance.GetByID(id);
        //it'd be better if it was static and we could do this instead, alas C# doesn't support it
        T result = T.GetByID(id);    
    
        return result;
    }
    
    

    Now you see, in a generic method we don't know what T is at compile time. We do know that T implements our interface so we can use anything that belongs to the interface. We can't access any static methods from it because you can't have static methods in an interface. The only option left is to declare an instance and call an instance method instead.

    It's pretty crappy but it was the only option available without making drastic changes to the existing codebase.



  • < offtopic >

    @Bulb said:

    PS: Don't use <font face="Times">font face</font>, it looks <font face="Comic Sans MS">ugly</font>.
     

    I secretly hate sans-serif fonts.  I was actually surprised the forum accepted the tag to be honest.

    < /offtopic >



  • @too_many_usernames said:

    < offtopic >

    @Bulb said:

    PS: Don't use <font face="Times">font face</font>, it looks <font face="Comic Sans MS">ugly</font>.
     

    I secretly hate sans-serif fonts.  I was actually surprised the forum accepted the tag to be honest.

    < /offtopic >

    < still offtopic >


    It's not a secret anymore.


    I propose that you and I never try to agree on a font. Unless it's in a PDF I doubt we could reach a consensus.


    < /still offtopic>



  • @too_many_usernames said:

    I've actually got to ask a question, though, because I'm not sure I understand the philosophy behind it: if you have a function which does not require an instantiation of the class, why is that function part of the class and not part of the thing in which instances of that class are used?  Is this purely for organization purposes?

    The only time which I can think this might be useful is if you have parameters associated with the class itself, such as things which may configure how objects are created by a constructor.  But this gets a little strange in my mind, because then the class itself has some kind of variables, which means the class itself is an instantiated object?

     

     

    consider this:

     

    class ObjectWithId

    {

       private static int _nextid;

       private int _id;

     

      public ObjectWithId()

      {

         _id = _nextid;

         _nextid++;

      }

     

      public int GetId()

      {

         return _id;

      }

     

      public static int GetNextId()

      {

         return _nextid;

      }

    }

     

     

    now you have a class that has an id acting like a primary key and you don't have to care about how it's implemented at all. it's small, elegant, self-contained, and it just works

    there might be better examples, but this is the first one that comes to my mind.

     

     @too_many_usernames said:

    Doesn't this blur the line between a class and object which instantiates a class?

     not really, to me, it enforces the line, thanks to the "instantiation" thing. moreover, it enables proper implementation of singleton, either as a completely static class, or similar to the example above.

     @too_many_usernames said:

    Is this the situation which caused the Factory pattern to emerge?

    afaik, no. the factory pattern emerged from the need of getting custom-configured objects right away, instead of having to call the constructor and then configure them in-place, you move all this to the ObjectFactory.GetThisConfigurationOfTheObject() . Yes, i've also tried to use classes that had static functions serving as factories to instance themselves, but... it gets kind of confusing, in my opinion.

    @too_many_usernames said:

    Do androids, in fact, dream of electric sheep?

    do people dream about sheep? i haven't ever had a sheep in my dream.



  •  @SEMI-HYBRID code said:

    do people dream about sheep? i haven't ever had a sheep in my dream.

    Some do:

    There was an Argentinian Gaucho named Bruno,

    Who said "There is one thing I do know.

    A woman is fine.

    A sheep is divine.

    But a Llama is numero uno."



  • @DoctaJonez said:

    I've seen this before. I had a C# library where everything was exposed via interfaces. I needed some methods that would have been best as static methods, but because you can't have static methods in an interface they had to be instance methods.

    Here's the kind of scenario we had:

    
    T Foo<T>(int id) where T : IBaseInterface, new
    {
        T instance = new T();
        //here we have to call the interface method
        T result = instance.GetByID(id);
        //it'd be better if it was static and we could do this instead, alas C# doesn't support it
        T result = T.GetByID(id);    
    
    return result;
    

    }

    Now you see, in a generic method we don't know what T is at compile time. We do know that T implements our interface so we can use anything that belongs to the interface. We can't access any static methods from it because you can't have static methods in an interface. The only option left is to declare an instance and call an instance method instead.

    It's pretty crappy but it was the only option available without making drastic changes to the existing codebase.

    Wait, are you trying to imply that to use inheritence and virtual methods, you have to have instances of objects? PREPOSTEROUS!

    Honestly, if you think you need this, my first assumption is something is wrong with you/your model.



  • @Sutherlands said:

    @DoctaJonez said:

    I've seen this before. I had a C# library where everything was exposed via interfaces. I needed some methods that would have been best as static methods, but because you can't have static methods in an interface they had to be instance methods.

    Here's the kind of scenario we had:

    
    T Foo<T>(int id) where T : IBaseInterface, new
    {
        T instance = new T();
        //here we have to call the interface method
        T result = instance.GetByID(id);
        //it'd be better if it was static and we could do this instead, alas C# doesn't support it
        T result = T.GetByID(id);    
    
    return result;
    

    }

    Now you see, in a generic method we don't know what T is at compile time. We do know that T implements our interface so we can use anything that belongs to the interface. We can't access any static methods from it because you can't have static methods in an interface. The only option left is to declare an instance and call an instance method instead.

    It's pretty crappy but it was the only option available without making drastic changes to the existing codebase.

    Wait, are you trying to imply that to use inheritence and virtual methods, you have to have instances of objects? PREPOSTEROUS!

    Honestly, if you think you need this, my first assumption is something is wrong with you/your model.

    Read my post again, I never mentioned virtual methods or inheritance. It discusses implementing interfaces, I mentioned only instance methods and static methods.

    As an aside... In C# you can't have a static virtual method, so you do need an instance of an object to be able to use them. It's not preposterous at all. It's also not relevant!

    I bid you good day sir!



  • I was trying to get across sarcasm on that preposterous, implying that of course you needed objects to use inheritence.

    I stand by the last part of my post.



  • @too_many_usernames said:

    I've actually got to ask a question, though, because I'm not sure I understand the philosophy behind it: if you have a function which does not require an instantiation of the class, why is that function part of the class and not part of the thing in which instances of that class are used?  Is this purely for organization purposes?

    The only time which I can think this might be useful is if you have parameters associated with the class itself, such as things which may configure how objects are created by a constructor.  But this gets a little strange in my mind, because then the class itself has some kind of variables, which means the class itself is an instantiated object? Doesn't this blur the line between a class and object which instantiates a class?  Is this the situation which caused the Factory pattern to emerge?  Do androids, in fact, dream of electric sheep?

    Just think about alternate implementations of System.Drawing.Image.FromFile or java.lang.Class.forName. Static methods are sometimes the cleanest way to do something.



  • @SEMI-HYBRID code said:

    public ObjectWithId()

      {

         _id = _nextid;

         _nextid++;

      }

    That should totally be an interlocked increment.
    Who knows who is going to make a new thread to just loop and create new instance of your object then sleep a while before making another one ;).



  • @DanceMaster said:

    That should totally be an interlocked increment.
    Who knows who is going to make a new thread to just loop and create new instance of your object then sleep a while before making another one ;).
     

    1. I've never worked on multi-threaded app so far, so it's not my default way of thinking

    2. Even if it was, this was just a quick example of a first somewhat justifiable use of static props/methods (to whom i supposed is a non-programmer) to show it has its uses and i wouldn't care about making it thread-safe

    3. Thanks anyway, good to know, when i'm working on something multi-threaded i'm sure i'll either remember you/this, or it'll come to bite me in the ass.
    (As i know myself it's more likely to be the latter)



  • @SEMI-HYBRID code said:

    @DanceMaster said:

    That should totally be an interlocked increment.
    Who knows who is going to make a new thread to just loop and create new instance of your object then sleep a while before making another one ;).
     

    1. I've never worked on multi-threaded app so far, so it's not my default way of thinking

    2. Even if it was, this was just a quick example of a first somewhat justifiable use of static props/methods (to whom i supposed is a non-programmer) to show it has its uses and i wouldn't care about making it thread-safe

    3. Thanks anyway, good to know, when i'm working on something multi-threaded i'm sure i'll either remember you/this, or it'll come to bite me in the ass.
    (As i know myself it's more likely to be the latter)

    Given that multi-core processors have been in common use for a few years now [still waiting for Kiefer with 32 cores...but soon...] there is absolutly no excuse for wring any professional code (in a PC environment, regardless of OS) that is not designed from the ground up to take advantage of all cores.



  • @TheCPUWizard said:

    Given that multi-core processors have been in common use for a few years now [still waiting for Kiefer with 32 cores...but soon...] there is absolutly no excuse for wring any professional code (in a PC environment, regardless of OS) that is not designed from the ground up to take advantage of all cores.
     

    except when you never write apps that actually need to take advantage of any more than one core. btw, since when multi-threaded == multi-core?



  • @SEMI-HYBRID code said:

    @TheCPUWizard said:

    Given that multi-core processors have been in common use for a few years now [still waiting for Kiefer with 32 cores...but soon...] there is absolutly no excuse for wring any professional code (in a PC environment, regardless of OS) that is not designed from the ground up to take advantage of all cores.
     

    except when you never write apps that actually need to take advantage of any more than one core. btw, since when multi-threaded == multi-core?

     Second part first... With a single CPU and a Single Core, then Multi-Threaded is really just timesharing the one processing unit. With multi-core, single-threaded means wasting the horsepower of the other cores. For example, a program running on an i7 Extreme can potentially be 12x faster by multi-threading than by single-threading.

     Now for: "except when you never write apps that actually need to take advantage of any more than one core"... This basically means that the application is never compute bound (i.e. processor utilization does not go to 100% for even a few milliseconds) or that one does not care about the speed of execution.

     I have never seen the first (on a PC type platform), and there are few applications where there is not a single operation that users did not wish ran faster.



  • @TheCPUWizard said:

    Given that multi-core processors have been in common use for a few years now [still waiting for Kiefer with 32 cores...but soon...] there is absolutly no excuse for wring any professional code (in a PC environment, regardless of OS) that is not designed from the ground up to take advantage of all cores.

    Oh come on. While I agree with your general point ("write software that runs as fast as possible"). That just shows a lack of imagination.

    What if the program's just graphically displaying, say, a printer queue? You really think I need multiple cores on that task? Or hell even multiple threads?



  • @blakeyrat said:

    @TheCPUWizard said:
    Given that multi-core processors have been in common use for a few years now [still waiting for Kiefer with 32 cores...but soon...] there is absolutly no excuse for wring any professional code (in a PC environment, regardless of OS) that is not designed from the ground up to take advantage of all cores.

    Oh come on. While I agree with your general point ("write software that runs as fast as possible"). That just shows a lack of imagination.

    What if the program's just graphically displaying, say, a printer queue? You really think I need multiple cores on that task? Or hell even multiple threads?

     "Need"...NO.... but there can still be benefits. Remember on a system with multiple programs running (i.e. nearly every one) when a singe core gets 100% (or nearly) busy for even a short time, the scheduler will start re-allocating threads to other cores (based on affinity settings). So your printer queue display can have an impact on other more critical applications running on the system.  On the otherhand, if the same program was written to put a low load on multiple cores (if available) then it would typically have much less of a potential impact on other running programs.

     Also, how many developers *just* write that type of program?



  • @TheCPUWizard said:

    a singe core gets 100%
     

    Excellent typo



  • @TheCPUWizard said:

    "Need"...NO.... but there can still be benefits. Remember on a system with multiple programs running (i.e. nearly every one) when a singe core gets 100% (or nearly) busy for even a short time, the scheduler will start re-allocating threads to other cores (based on affinity settings). So your printer queue display can have an impact on other more critical applications running on the system.

    Oh come on, you're full of crap and you know it. Just admit it. You're not fooling anybody.

    @TheCPUWizard said:

    On the otherhand, if the same program was written to put a low load on multiple cores (if available) then it would typically have much less of a potential impact on other running programs.

    If that 1/3rd millisecond "impact" of a program drawing printer icons negatively affects your program, then just imagine what the USB mass storage interrupts are doing to it!

    These aren't fucking Commodore 64s, man. Christ.



  • @dhromed said:

    @TheCPUWizard said:

    a singe core gets 100%
     

    Excellent typo

    Agreed, a typo....but ironically potentially accurate....



  • @blakeyrat said:

    Oh come on, you're full of crap and you know it. Just admit it. You're not fooling anybody.

    Actually it is a very real problem on an industrial system I am currently working on. There are many timing requirements in the 50uS range [running an RTOS on PC hardware], and many of the "simple UI" applications that have no real performance specifications have had to be re-written.

    You also ignored my point of "writing JUST simple GUI applications. If that is all a person every does, I would find it suprising for them to remain in the field long. So consider a person who has written a more demanding program, and has learned excellent practices..I maintain that applying these practices to every development effort actually makes things easier (an lowest cost when viewed from a TCO point of view]



  • @TheCPUWizard said:

    There are many timing requirements in the 50uS range [running an RTOS on PC hardware],

    And... here we go again!

    Why does anybody anywhere ever try to even engage TheCPUWizard in conversation? Researchers are working around the clock to find that out.



  • @TheCPUWizard said:

    Given that multi-core processors have been in common use for a few years now [still waiting for Kiefer with 32 cores...but soon...] there is absolutly no excuse for wring any professional code (in a PC environment, regardless of OS) that is not designed from the ground up to take advantage of all cores.

    Not all problems fit neatly into a parallel mode of operation. But since that's not an excuse, but a constraint, I guess maybe you're right.



  • @TheCPUWizard said:

    @blakeyrat said:

    Oh come on, you're full of crap and you know it. Just admit it. You're not fooling anybody.

    Actually it is a very real problem on an industrial system I am currently working on. There are many timing requirements in the 50uS range [running an RTOS on PC hardware]

    And of course that's SO representative of most of the software being developed across the board.



  • @TheCPUWizard said:

    there is absolutly no excuse for wring any professional code (in a PC environment, regardless of OS) that is not designed from the ground up to take advantage of all cores.

    SNORT

    Stupid people are funny.



  • @too_many_usernames said:

    "Overthinking things" is one of the skills I have highighted in my company's skills matrix. (Yes, we really have one of those.  It's frightening.)
    So I take it you don't approve of skills matrices? In our ~20 person group at our ~40 person company, there has been a drive to create a "Responsibility Matrix" and a "Skills Matrix."  The responsibilty matrix has been the bane of my existence, but I always thought the skills matrix may have been useful if we would ever get one set up.  I don't think it would take the form of an actual matrix because it would be long in the "skills" axis and quite sparse for the most part, but having a list of what the heck everyone else knows would be useful from time to time. 

    So, is it your opinion that it is A Bad Thing generally, or has it just come to signify too much bureaucracy?

     



  • @TheCPUWizard said:

    @blakeyrat said:
    @TheCPUWizard said:
    Given that multi-core processors have been in common use for a few years now [still waiting for Kiefer with 32 cores...but soon...] there is absolutly no excuse for wring any professional code (in a PC environment, regardless of OS) that is not designed from the ground up to take advantage of all cores.

    Oh come on. While I agree with your general point ("write software that runs as fast as possible"). That just shows a lack of imagination.

    What if the program's just graphically displaying, say, a printer queue? You really think I need multiple cores on that task? Or hell even multiple threads?

     "Need"...NO.... but there can still be benefits. Remember on a system with multiple programs running (i.e. nearly every one) when a singe core gets 100% (or nearly) busy for even a short time, the scheduler will start re-allocating threads to other cores (based on affinity settings). So your printer queue display can have an impact on other more critical applications running on the system.  On the otherhand, if the same program was written to put a low load on multiple cores (if available) then it would typically have much less of a potential impact on other running programs.

    If your printer queue has an impact on more critical applications, it's because you've done something stupid with the priority settings.  And you appear not to understand that even a single-threaded app will get randomly scheduled across any available CPU when it's ready to run; even a busy-spin loop will only load each cpu in a N-core system by (100/N)%.

    @TheCPUWizard said:

    Also, how many developers *just* write that type of program?

    By "that type of program", you mean "I/O bound", so the answer is "many".




  • @DaveK said:

    @TheCPUWizard said:

    Also, how many developers just write that type of program?

    By "that type of program", you mean "I/O bound", so the answer is "many".

    +1


  • @Sutherlands said:

    @DaveK said:

    @TheCPUWizard said:

    Also, how many developers just write that type of program?

    By "that type of program", you mean "I/O bound", so the answer is "many".

    +1

    (Knowing full well the perils of attempting a real technical discussion on this forum...)

     So there are multiple people stating that *every* single program they have ever written have been 100% I/O bound.

     Either there is a significant area that I have missed over my 40 years as a programmer, or people are neglecting the word "just" in my original posting.  I am willing to wager the latter, as I would find it flabergasting if there are prople who have been writing code for an appreciable amount of time (even months) and have not had a single occurance where at least one (significant) point in one program was not CPU bound.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.