Initializing arrays to zero all in one go?

This is a discussion on Initializing arrays to zero all in one go? within the C++ Programming forums, part of the General Programming Boards category; Well, they're inherently dangerous with non-POD types, that's true. That's where the main danger lies. But I suppose there are ...

  1. #16
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,001
    Well, they're inherently dangerous with non-POD types, that's true. That's where the main danger lies.
    But I suppose there are other pitfalls even for POD-types, so I would say that you should still be careful.
    But you also see that it is easy to assign on an element basis instead of a byte-basis, too, so there is an additional advantage.
    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. #17
    Registered User
    Join Date
    Aug 2010
    Location
    Poland
    Posts
    682
    Aah! So I was right after all! Except that I thought that {1} would set all to 1, which is false.
    I was thinking in a similar way, expecting { 0 } to initialize the first element only good to know. My fault, sorry.

    I totally disagree. It stops a host of errors.

    It has not slown down program execution to any measurable degree in any application I have written.
    Imagine every local variable being initialized twice. I mean here also bigger buffers. Who needs to fill it with zeros, if it will be overwritten with stream's data for a moment. It also obsfucates the code (to me):
    Code:
        int a = 0;
        if (getline())
        {
             a = 1;
        }
        else
        {
             a = 0;
        }

  3. #18
    Registered User
    Join Date
    Mar 2008
    Location
    Coimbra, Portugal
    Posts
    85
    Quote Originally Posted by Elysia View Post
    Well, they're inherently dangerous with non-POD types, that's true. That's where the main danger lies.
    But I suppose there are other pitfalls even for POD-types, so I would say that you should still be careful.
    But you also see that it is easy to assign on an element basis instead of a byte-basis, too, so there is an additional advantage.
    Sorry to be pesky, but what other pitfalls do you see with POD-types and memset? Is it, for instance, buffer overruns due to invalid size arguments passed?

  4. #19
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,001
    Not portable. All machines do not use the same bit representation.
    While buffer overruns are always a problem, the "C++ way" isn't necessarily better. Iterators can be just as unsafe as pointers plus size. So std::fill doesn't really have an "advantage" that way.

    ...But this is all that comes to mind right now. Using memset on PODs should be fine, but it's a special case, and usually there isn't much advantage of using memset anyway. Good library implementations can detect POD types and call memset internally, leaving the user free to use std::fill without worries.
    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.

  5. #20
    Registered User
    Join Date
    Mar 2008
    Location
    Coimbra, Portugal
    Posts
    85
    Quote Originally Posted by Elysia View Post
    Not portable. All machines do not use the same bit representation.
    Well, as far as initialization goes, memset should be ok, IMO.

    While buffer overruns are always a problem, the "C++ way" isn't necessarily better. Iterators can be just as unsafe as pointers plus size. So std::fill doesn't really have an "advantage" that way.
    Yes, I was going to see if you would say that to state that C++ isn't safe either
    ...But this is all that comes to mind right now. Using memset on PODs should be fine, but it's a special case, and usually there isn't much advantage of using memset anyway. Good library implementations can detect POD types and call memset internally, leaving the user free to use std::fill without worries.
    Yes, I remember reading a thread here about that exact issue. It debated ::fill vs memset speed and the likes.

    Thanks for the info.

  6. #21
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,001
    Quote Originally Posted by Jorl17 View Post
    Well, as far as initialization goes, memset should be ok, IMO.
    Probably, but we can't be sure, so that kind of hurts the portability argument, even though it probably is safe 99.99% of the time.
    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.

  7. #22
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,759
    memset is portable for POD types. The arguments against this fact do not make sense.

    In the first place, machine A with a different bit representation than machine B, would use the memset for machine A anyway in its executable. It would be true that machine A's executable cannot run on machine B, so the executable is not portable, but the source code is, which is what matters.

    This is exactly why good implementations of say, std::fill can call memset on POD types safely.

  8. #23
    Registered User
    Join Date
    Aug 2010
    Location
    Poland
    Posts
    682
    If the standard does not guarantee bit representation, what if the bit representation of floating-point's 0 is represented as 0x80000000 (or something else)? Some machine might use 0 for minus sign and 1 for plus, or use 0x00000000 as NAN.
    Last edited by kmdv; 09-19-2010 at 01:17 PM.

  9. #24
    Registered User
    Join Date
    Mar 2008
    Location
    Coimbra, Portugal
    Posts
    85
    Quote Originally Posted by kmdv View Post
    If the standard does not guarantee bit representation, what if the bit representation of a floating-point's 0 is represented as 0x80000000 (or something else)? Some machine might use 0 for minus sign and 1 for plus, or use 0x00000000 as NAN.
    Does it really matter all that much? If we use the {0} scheme, it gets initialized properly. If we want to see if it "hasn't been changed" we'd just compare it with (float)0, which would give you your correct bit representation.

    Of course that, with memset, that would fail, unless you wrote a specialized memsetf for that architecture's float (which would copy data as floats and not bytes). Or am I missing something else?
    Last edited by Jorl17; 09-19-2010 at 01:22 PM.

  10. #25
    Registered User
    Join Date
    Aug 2010
    Location
    Poland
    Posts
    682
    Quote Originally Posted by Jorl17 View Post
    Does it really matter all that much? If we use the {0} scheme, it gets initialized properly. If we want to see if it "hasn't been changed" we'd just compare it with (float)0, which would give you your correct bit representation.

    Of course that, with memset, that would fail, unless you wrote a specialized memsetf for that architecture's float (which would copy data as floats and not bytes). Or am I missing something else?
    You might want to clear something at runtime (
    Code:
    {}
    is for initializing only (?) ).

    Btw. I tried to post this without the CODE tags and it failed. The checker seems to be a bit too strict.

    Quote Originally Posted by Jorl17 View Post
    Or am I missing something else?
    Yes, we are talking about all POD types, not arrays only.
    Last edited by kmdv; 09-19-2010 at 01:32 PM.

  11. #26
    Registered User
    Join Date
    Mar 2008
    Location
    Coimbra, Portugal
    Posts
    85
    Quote Originally Posted by kmdv View Post
    You might want to clear something at runtime (
    Code:
    {}
    is for initializing only (?) ).

    Btw. I tried to post this without the CODE tags and it failed. The checker seems to be a bit too strict.


    Yes, we are talking about all POD types, not arrays only.
    Ah, so we're discussing if memset is in fact portable with all POD types, right?

    But if we're not into arrays anymore, then what's the purpose of using memset? Using the assignment operator is probably just faster then. It's obvious that, since memset() works byte-by-byte, it can't be *entirely* safe, period.

  12. #27
    Registered User
    Join Date
    Aug 2010
    Location
    Poland
    Posts
    682
    Quote Originally Posted by Jorl17 View Post
    Ah, so we're discussing if memset is in fact portable with all POD types, right?

    But if we're not into arrays anymore, then what's the purpose of using memset? Using the assignment operator is probably just faster then. It's obvious that, since memset() works byte-by-byte, it can't be *entirely* safe, period.
    Memset works byte-by-byte (rather, dword-by-dword or qword-by-qword respectively) and this is why it is _faster_. Of course, the assignment operator can work as memset either, but this is a different story.
    The purpose of using memset is that you can use it for any type, without the need of generating empty instance for every POD structure.

    Personally, I don't feel any need for memset (except raw buffer 0-ing).
    Last edited by kmdv; 09-19-2010 at 01:48 PM.

  13. #28
    Registered User
    Join Date
    Mar 2008
    Location
    Coimbra, Portugal
    Posts
    85
    Quote Originally Posted by kmdv View Post
    Memset works byte-by-byte (rather, dword-by-dword or qword-by-qword respectively) and this is why it is _faster_. Of course, the assignment operator can work as memset either, but this is a different story.
    Ah, you're right, dword-by-dword or qword-by-qword indeed, it's faster. However, I think that we should rely on the fact that our compiler produces fast code for those operators (and it probably does).

    edit:

    Personally, I don't feel any need for memset (except raw buffer 0-ing).
    Exactly, that's what I use it for.
    Last edited by Jorl17; 09-19-2010 at 01:55 PM.

  14. #29
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,001
    memset is faster because it treats whatever it copies as just raw bytes. Copying one byte at a time is very inefficient. memset doesn't do that. It just guarantees that the result is the same as if the bytes were copied one byte at a time.
    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.

  15. #30
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,759
    I find that since memset does not work for floats it is not applicable when discussing how portable memset is. It is just as easy to say that memset is not built to work with floating point. Before discussing if memset is portable in the case of floating point stuff, figure out if it even works for floating point stuff.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 23
    Last Post: 12-06-2008, 01:39 PM
  2. initializing multi-dimensional arrays
    By cyberfish in forum C++ Programming
    Replies: 4
    Last Post: 10-31-2007, 09:15 PM
  3. newbee: initializing arrays
    By breaka in forum C Programming
    Replies: 11
    Last Post: 06-12-2006, 01:20 PM
  4. Initializing dynamic arrays
    By cunnus88 in forum C++ Programming
    Replies: 9
    Last Post: 11-21-2005, 09:50 AM
  5. Replies: 14
    Last Post: 03-17-2003, 10:07 AM

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