new and delete for references

This is a discussion on new and delete for references within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by Sebastiani I'm with Elkvis here. Pointers are fugly. Period. End of debate. Seriously, though, I don't see ...

  1. #31
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    Quote Originally Posted by Sebastiani View Post
    I'm with Elkvis here. Pointers are fugly. Period. End of debate.

    Seriously, though, I don't see what all the fuss is about, giving references the same privilages as pointers. The argument that it would be too confusing or dangerous is purely a subjective one. Considering all of the bizarre, error-prone conventions used by programmers that are perfectly *legal*, I hardly think allowing someone a bit of syntactic sugar poses any real threat to safe programming practices.
    Implementation specific.... As long as one checks for bad_alloc's being thrown I don't see there being too much danger, per se. But whatever, you write your code and I will write mine and one day we can write ours together hand in hand for the sake of world peace.

  2. #32
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,308
    I completely get what the OP is getting at.
    When references were introduced it was decided to prevent a reference from existing without actually referring to anything. This itself makes perfect sense and is one of the useful things that sets it apart from pointers.
    However, the language could have also been designed such that if a reference is ever declared and NOT made to refer to anything, that it actually refers to a temporary default-constructed object. This also of course cannot subsequently be reassigned, no change there.

    Assuming you follow so far, it almost seems like a plausible idea. Okay, now think about this: How does declaring one of these references to a default-constructed object differ from declaring an ordinary object? I'd say that the only difference is whether the underlying object is stored on the heap, or as part of it's parent classes memory layout. Feels a bit C# class vs struct-ish to me.

    So would this actually be useful? Not really. In the majority of cases storing the object as part of it's parent is going to be more efficient. The only case where you wouldn't want to do that is when the object is large and it's parent is on the stack. In that once case I think it is acceptable to force the programmer to have to go that extra mile (or millimeter) to use a smart pointer, instead. Hence my conclusion of why nobody wants the discussed feature.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  3. #33
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    However, the language could have also been designed such that if a reference is ever declared and NOT made to refer to anything, that it actually refers to a temporary default-constructed object.
    Then you'd have one rule for objects with a default constructor and another for those without. Not much of an improvement there.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  4. #34
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    Or a VB-esque IsNothing() function.....

  5. #35
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,308
    Quote Originally Posted by CornedBee View Post
    Then you'd have one rule for objects with a default constructor and another for those without. Not much of an improvement there.
    Oh I certainly agree!

    I was hoping to convince the OP that I did understand them and try and show that others that have been posting actually also make just as much sense, as they draw the same conclusions (if not rather abruptly)
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  6. #36
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    Practical and possible do not always see eye to eye in this cruel world of ours.

  7. #37
    Registered User
    Join Date
    Aug 2008
    Posts
    188
    i'm completely lost here....what's the big deal?

    Foo* foo = new Foo;
    Foo& bar = *foo;
    bar.WeeICanUsePeriodNow();

  8. #38
    Sweet
    Join Date
    Aug 2002
    Location
    Tucson, Arizona
    Posts
    1,812
    Cause this is cooler
    Code:
    #include <iostream>
    
    class CAwesome{
    public:
    	void DoAmesomePrint()
    	{
    		std::cout<<"Awesome!!!!!!!!!!"<<std::endl;
    	}
    };
    
    int main()
    {
    	
    	CAwesome &awesome = *(new CAwesome);
    
    	awesome.DoAmesomePrint();
    
    	std::cin.get();
    
    	delete &awesome;
    
    	return 0;
    }
    Woop?

  9. #39
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    Since this doesn't break as much. This is even cooler.
    Code:
    #include <iostream>
    #include <new>
    
    class CAwesome{
    public:
    	void DoAmesomePrint()
    	{
    		std::cout<<"Awesome!!!!!!!!!!"<<std::endl;
    	}
    };
    
    int main()
    {
      try
      {
        CAwesome &awesome = *(new CAwesome);
    
        awesome.DoAmesomePrint();
    
        std::cin.get();
    
        delete &awesome;
    
        return 0;
      } catch(std::bad_alloc e)
      {
        std::cerr << e.what() << std::endl;
        return -1;   
      }
    }

Page 3 of 3 FirstFirst 123
Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21