Inputting a dynamic, mutable character array with spaces

This is a discussion on Inputting a dynamic, mutable character array with spaces within the C++ Programming forums, part of the General Programming Boards category; Because RTTI means runtime overhead and that goes against C++'s principles. Sometimes it is needed to make decisions on runtime ...

  1. #31
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,411
    Because RTTI means runtime overhead and that goes against C++'s principles.
    Sometimes it is needed to make decisions on runtime instead of compile time, of course. Polymorphism is a fine example. But that is an explicit choice.
    Making an implicit runtime check everytime you convert a pointer would hurt performance. This isn't some dumb Java.

    Quote Originally Posted by whiteflags View Post
    Not arguing. You make the same assumptions about *T and *S when you convert explicitly though, so I am not sure I understand.
    This part I don't understand what you're trying to imply, though.

    RTTI isn't the devil, and C++ supports it.
    RTTI is Evil(tm) [just as goto].
    Last edited by Elysia; 08-08-2010 at 05:40 PM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #32
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,622
    Me: Not arguing. You make the same assumptions about *T and *S when you convert explicitly though, so I am not sure I understand.

    You: This part I don't understand what you're trying to imply, though.
    void* happens to be one of the only types that implicitly casts to other pointers in C. You can also assign T* to const T* or T const* or const T const* without complaint. That exception makes sense to you hopefully because on one end, you don't care if it's constant, buut the other end wants to treat values constant. With T* to S* an assumption is made about what the pointed to object is. So for me it's really not an argument, because even in C you have to explicitly cast T* to S*. The only thing C++ tells me in void*'s case is that I can't treat some address as another pointer type, and that doesn't make sense. At least C compilers are smart enough to handle special cases.

    Assuming that it's still a problem... and this is really a generous assumption ... then RTTI is needed for pointer conversions. At least that would have been ideal to me. Nevertheless, evil is rather strong considering you can't really defend the idea.

    Please compile a list of evil things and link to it in your sig.
    Last edited by whiteflags; 08-08-2010 at 07:02 PM. Reason: effectively rewrote this

  3. #33
    The larch
    Join Date
    May 2006
    Posts
    3,573
    I think the point about evilness of void* -> T* (in C++) is illustrated by this example:

    Code:
    #include <stdlib.h>
    typedef struct X {int i; } X;
    
    typedef struct Y { double d; } Y;
    
    void foo(Y* p) {}
    
    int main()
    {
    
        X* p = malloc(sizeof(*p));
        foo(p);
        return 0;
    }
    A C compiler accepts this (perhaps emitting a warning), because there exists an implicit conversion X* -> void* -> Y*.

    In C++, types are / can be more than just a sequence of bytes, and pointers silently turning into pointers to any completely unrelated type makes far less sense. If that is really your intention, explicitly cast it with reinterpret_cast or an evil C-style cast.

    --------

    The passion with which Elysia argues that a standard feature which even doesn't have any standard replacement* yet is evil is somewhat bizarre though.

    *Well, nullptr can be implemented as a library feature, as was shown in the proposal for it.
    Last edited by anon; 08-09-2010 at 12:50 AM.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  4. #34
    Registered User
    Join Date
    Oct 2009
    Posts
    2
    NULL was introduced into C in 1978 or so. It *had* to be 0 or 0L.
    NULL was adopted unchanged into C++ for compatibility reasons.
    I never liked it and have consistently warned against its use.
    In the late 1980s void* was introduced into C++ and a bit later in an incompatible and type unsafe form into C.
    In C89, the definition of the NULL macro was changed in C to (void*)0. That definition cannot be used in C++ because it would prevent assignment of NULL to a pointer.
    In C++98 it is actually allowed to implement NULL as a value that cannot be converted to an int, but not all implementations take advantage of that
    In C++0x, you will be able to use nullptr to minimize confusion and resolver integer/pointer ambiguities. This is not a perfect solution because you can still (for compatibility reasons) use 0 and an old-style NULL.

    For an example of why void* to T* conversions are unsafe, see Stroustrup: C++ Style and Technique FAQ

  5. #35
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,411
    Quote Originally Posted by whiteflags View Post
    Please compile a list of evil things and link to it in your sig.
    Not bad idea, I suppose. I might just utilize a private wiki page for that.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #36
    Registered User
    Join Date
    Jul 2010
    Location
    Oklahoma
    Posts
    107
    According the Microsoft developer's network documentation, the availability of nullptr is contingent upon the /clr (common language runtime) switch during compilation. I got this from: nullptr. This is the first I've ever heard about it, and I am diligently reading to catch up. They also made a distinction with another variable __nullptr.... Seems like more bells and whistles to me, but I guess it's more exciting to use an R.P.G. than a flyswatter when hunting flies.

    I recall there was always some discrepancy between Microsoft standards and the ISO standards. I don't get to work with Microsoft's material very often, as it is often out of my price range, so I kind of keep an eye on them at a distance. Especially after some rather disparaging events -- for example the monopoly hearings a few years ago, and even more so after a recent article in Linux Journal regarding the use of highly proprietary material within the government: OSS: Europe vs. The United States | Linux Journal.

    When I was getting honed on the formal language material a few years ago, we were always encouraged to manage our data type conversions carefully. The concept of NULL was firmly concrete by the time it was introduced in Abstract Algebra and Real Analysis, and it has never caused any problems for me, ever. The idea of using a numeric value to express a location in memory is rather reasonable, I think. In fact, I've seen some very elegant code that takes advantage of the fact that memory addresses are integers.

    Where might I read more about this debate you are having? Elysia you seem to be very certain of your perspective, is there a specific reference source you are using?

    Best Regards,

    New Ink -- Henry

  7. #37
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,411
    Microsoft and their dumb solutions. Don't use /clr. Ever. It breaks stuff.
    Using nullptr in native code is perfectly fine. What is problematic is Managed C++ and use of nullptr. Frankly, don't use it. It causes headaches and problems.

    If you're interested in nullptr, then this should dig deep:
    Stephan T. Lavavej: Everything you ever wanted to know about nullptr | Going Deep | Channel 9
    You may want to skip ahead a little, since he talks about a lot of nonsense (read: nothing about nullptr) in the beginning.

    The problem isn't the value; rather it is the type. In C++, it is possible to create different types that hold integral data, for example. You can make it so you can't assign x-coordinates to y-coordinates and vice versa. A safe type system.
    The same should apply to a null pointer, since it isn't an integer. NULL is confusing, however, because it is exactly that - an integer and behaves like one.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #38
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    Quote Originally Posted by bjarne View Post
    NULL was introduced into C in 1978 or so. It *had* to be 0 or 0L.
    NULL was adopted unchanged into C++ for compatibility reasons.
    I never liked it and have consistently warned against its use.
    In the late 1980s void* was introduced into C++ and a bit later in an incompatible and type unsafe form into C.
    In C89, the definition of the NULL macro was changed in C to (void*)0. That definition cannot be used in C++ because it would prevent assignment of NULL to a pointer.
    In C++98 it is actually allowed to implement NULL as a value that cannot be converted to an int, but not all implementations take advantage of that
    In C++0x, you will be able to use nullptr to minimize confusion and resolver integer/pointer ambiguities. This is not a perfect solution because you can still (for compatibility reasons) use 0 and an old-style NULL.

    For an example of why void* to T* conversions are unsafe, see Stroustrup: C++ Style and Technique FAQ
    Thanks, this explains the issue.

    There is never a perfect solution, but since nullptr offers more without any consequences (as I understood so far) it is a better solution. I guess you should add some checks if it is supported and if not revert to NULL to solve compatibility issues

  9. #39
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,643
    Users of older compilers could simply define something like this:

    Code:
    #if __cplusplus <= 199711L
    
    #include <cstdlib> // for NULL
    
    namespace std {
    
    struct nullptr
    {
    	template < typename Type >
    	inline operator Type* ( void ) const
    	{
    		return static_cast< Type* >( NULL );
    	}	
    	
    	template < typename Type >
    	inline friend bool operator == ( nullptr const& lhs, Type* rhs )
    	{
    		return rhs == static_cast< Type* >( NULL );
    	}
    	
    	template < typename Type >
    	inline friend bool operator != ( nullptr const& lhs, Type* rhs )
    	{
    		return !( lhs == rhs );
    	}	
    	
    	template < typename Type >
    	inline friend bool operator == ( Type* lhs, nullptr const& rhs )
    	{
    		return rhs == lhs;
    	}	
    	
    	template < typename Type >
    	inline friend bool operator != ( Type* lhs, nullptr const& rhs )
    	{
    		return rhs != lhs;
    	}
    } 
    	nullptr;
    	
    } // namespace std
    
    using std::nullptr;
    	
    #endif // __cplusplus <= 199711L
    
    // Test:	
    
    #include <iostream>
    #include <cassert>
    
    using namespace std;
    	
    void foo( int )
    {
    	cout << "foo(int)" << endl;
    }
    
    void foo( int* )
    {
    	cout << "foo(int*)" << endl;
    }
    
    int main( void )
    {
    	int i;
    	int* ip = &i;
    	int const* ipc = nullptr;
    	int const volatile* ipcv = nullptr;
    	int const volatile* const ipcvc = nullptr;
    	assert( ip != nullptr );
    	assert( ipcvc == nullptr );
    	foo( 0 );
    	foo( nullptr );
    }
    More or less, anyway.
    Code:
    if( numeric_limits< byte >::digits != bits_per_byte )
        error( "program requires bits_per_byte-bit bytes" );
    24bbs.cpp

  10. #40
    The larch
    Join Date
    May 2006
    Posts
    3,573
    An alternative library-based implementation (from the proposal of nullptr) is on page 3.

    Code:
    #if __cplusplus <= 199711L
    At this time, I wouldn't bet that this correctly detects if nullptr is around. There are compilers whose implemented C++0x features don't include nullptr.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  11. #41
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,643
    Quote Originally Posted by anon View Post
    An alternative library-based implementation (from the proposal of nullptr) is on page 3.
    Figures, yeah. I was just pointing out the obvious, really.

    Quote Originally Posted by anon View Post
    At this time, I wouldn't bet that this correctly detects if nullptr is around. There are compilers whose implemented C++0x features don't include nullptr.
    Hmm, good point. I guess there isn't really a portable way to do that then?
    Code:
    if( numeric_limits< byte >::digits != bits_per_byte )
        error( "program requires bits_per_byte-bit bytes" );
    24bbs.cpp

  12. #42
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,590
    Microsoft and their dumb solutions. Don't use /clr. Ever. It breaks stuff.
    Once again an incorrect statement. Use /clr when it is necessary or when you want to use the .NET framework in C++. There is no other way. C++/CLI looks daunting at first but then you realize why they did the things they did. I do not agree with the addition of keywords, symbols, etc. but after you get used to it...it isn't all that bad. I've programmed in C++ and C++/CLI and as long as you keep your mind focused on the language at hand everything works just as it should.

    Back to the discussion at hand:
    Quite honestly I have bigger fish to fry in code than worrying about whether or not I use 0, NULL, or some other construct to represent a null pointer. Sorry, just not an issue with me.

    RTTI is Evil(tm) [just as goto].
    Again an incorrect statement. All the pieces of the language have their uses and possible abuses but that in and of itself does not make said piece evil. You seem to be quite the close-minded programmer in that everything must use A or B but not C. Sorry but that isn't how I feel about any of the tools that I daily use to perform various tasks.

    All of this also makes me wonder if you are working day to day in a large complex code line because none of what you have said, suggested, or implied even comes close to what I am used to seeing or fretting about. You think I really care if someone is using 0 or NULL when I have a million lines of code to look at to find a bug or two? I really don't see the sense in any of that.
    Last edited by VirtualAce; 08-09-2010 at 10:27 PM.

  13. #43
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,411
    I would prefer C# over C++/CLI seeing how Microsoft breaks stuff with that switch. Native standards are more important to me than Microsoft managed languages.

    There are many things that are evil. Yet, that does not mean they don't have their uses. Otherwise they wouldn't have existed in the first place. RTTI is one of those things. It goes completely against what C++ strives for - static type checking and templates. Yet, it exists. If you need to use it, think twice, and if you still need it, then use it. But I can still label it evil.

    This isn't about transforming existing code. This is about doing the right thing in the future. NULL is deprecated and is an evil construct that we've been stuck with. Now there's a solution, and therefore, I encourage everyone who can to upgrade to C++0x and use it. There is no must. Just like there is no must to use the latest and greatest. That is all.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #44
    Anti-Poster
    Join Date
    Feb 2002
    Posts
    1,399
    Quote Originally Posted by Elysia View Post
    I would prefer C# over C++/CLI seeing how Microsoft breaks stuff with that switch.
    Can you provide a link? I've been looking for a list of stuff that breaks when using /clr, but I haven't been able to find one.
    If I did your homework for you, then you might pass your class without learning how to write a program like this. Then you might graduate and get your degree without learning how to write a program like this. You might become a professional programmer without knowing how to write a program like this. Someday you might work on a project with me without knowing how to write a program like this. Then I would have to do you serious bodily harm. - Jack Klein

  15. #45
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,411
    'Fraid not. Only have what new_ink2001 posted.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Page 3 of 4 FirstFirst 1234 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Multi-dimensional dynamic array - performance
    By melkor445 in forum C++ Programming
    Replies: 15
    Last Post: 10-07-2007, 04:17 AM
  2. Dynamic structure with array and array count
    By Nazgulled in forum C Programming
    Replies: 14
    Last Post: 06-08-2007, 10:10 PM
  3. Replies: 4
    Last Post: 11-02-2006, 10:41 AM
  4. Help with 2-D character array
    By choykawairicky in forum C++ Programming
    Replies: 2
    Last Post: 05-15-2004, 12:12 AM
  5. Reading in text file into an array, white spaces...
    By error in forum C++ Programming
    Replies: 12
    Last Post: 01-14-2003, 08:39 AM

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