Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] C++ stack objects [OT?] (was: Continous integration without version control)

Expand Messages
  • Robert Sartin
    ... I think the OP is referring to the fact that the type of a stack object is fixed at the declaration of the object. You can t use a factory to produce a
    Message 1 of 48 , Sep 1, 2001
    • 0 Attachment
      --- kevinxp@... wrote:
      > polymorphism for stack-based objects". An object is an object,
      > whether it was created on the stack (local), in data space (global),

      > or on the heap (using new).

      I think the OP is referring to the fact that the type of a stack object
      is fixed at the declaration of the object. You can't use a factory to
      produce a stack object.

      If I have a method:

      void doStuff() {
      SomeClass anObject;
      // ...
      }

      I can't change the class of anObject unless I change that code. If I
      have a method:

      void doStuffDynamically() {
      SomeClass* anObject = ClassFactory.getSomeClass();
      // ...
      }

      Then I can decide the type at runtime in the factory.

      Also, the compiler is actually free, in the stack case, to not use
      dynamic dispatch since the compiler knows that actual type of anObject.
      It can directly dispatch to the methods defined in SomeClass without
      using something like a vtbl. In that sense, polymorphism could be said
      to be gone for stack objects.

      Regards,

      Rob


      __________________________________________________
      Do You Yahoo!?
      Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
      http://im.yahoo.com
    • kevinxp@qualitycode.com
      ... Valuable to end users? No. Valuable to the XP customer so he can see progress, validate the rules so far, and think of new ones that may break the system?
      Message 48 of 48 , Sep 7, 2001
      • 0 Attachment
        --- In extremeprogramming@y..., "Matthew Davis" <azami@s...> wrote:
        > --- In extremeprogramming@y..., kentbeck@c... wrote:
        > > At LifeWare, we would have a new insurance product to implement. We
        > > would get a simple version of it working with an acceptance test.
        > > Then the actuary would give us a variation, we would make that work.
        > > When the actuary couldn't think of any more variations, we were
        > ready
        > > to go live, and we put the product into the list of possible
        > products
        > > in the GUI.
        > >
        > > The actuary seemed to think each new variation working was valuable.
        > > Was he wrong?
        >
        > I suppose it depends on how you define valuable. In the strictest
        > sense, _I_ would say he was wrong.

        Valuable to end users? No.
        Valuable to the XP customer so he can see progress, validate the rules so far,
        and think of new ones that may break the system? Absolutely.

        I do agree that changing the UI may make a new release unusable by legacy
        customers, thus requiring a branch. It depends on the customers, the product,
        the business model, the nature of the changes, and whether Ron sneezed the
        day before or not.

        Kevin
      Your message has been successfully submitted and would be delivered to recipients shortly.