5 ms·

I never liked those microsoft functions, and disable all the warnings in each new project. What are you supposed to use instead of memcpy? It's a bit of a rant

I never liked those microsoft functions, and disable all the warnings in each new project. What are you supposed to use instead of memcpy? It's a bit of a rant but I find myself in agreement with this: http://unspecified.wordpress.com/2009/05/16/microsoft-bans-memcpy/ http://unspecified.wordpress.com/2009/05/16/microsoft-bans-m...

aaronbrethorst 13y ago
memcpy_s: http://msdn.microsoft.com/en-us/library/dswaw1wk(v=vs.80).aspx http://msdn.microsoft.com/en-us/library/dswaw1wk(v=vs.80).as... edit: I read the link you included and I have to take exception with this line: it’s a perfectly safe function if you use it properly Sure, same thing as automobiles, alcohol, condoms… Problems arise because people do not use them correctly.
- penguindev 13y ago
  LOL, That's a fucking joke! "If the source and destination overlap, the behavior of memcpy_s is undefined." Wow, way to improve things microsuck! It's not like anyone has ever mistakenly used memcpy on overlapping buffers....
  - deleted 13y ago
    [deleted]
  - quotemstr 13y ago
    You can use memmove_s, you know.
  - EpicEng 13y ago
    The same is true for memcpy ya know... that's what memmove is for. Perhaps you should make sure you know what you're talking about before bashing others ("others" who are probably far more experienced than yourself).
    - tedunangst 13y ago
      Eh, I believe that was his point. If you're going to go to the trouble of building a safe memcpy with no sharp corners, don't leave the overlapping buffer razor blade sticking out. Perhaps you should settle down.
      - EpicEng 13y ago
        Hmmm... well perhaps I did miss that, but your (his?) suggestion is a terrible idea. memcpy should be fast. Checking for overlap slows it down. Want to allow for overlap? Use memmove, that's what it's there for. I don't want to have to roll my own optimized version of memcpy when I know that I don't need any special handling or error checking.
        jheriko 13y ago
        "memcpy should be fast" you know memcpy is my 'classical' example of why you should never trust library code to be well optimised. its almost always a dumbass byte-by-byte copy - its pretty much the worst case performance unless you go out of your way to slow down your implementation. the speed improvement from good register usage and appropriate cache hints was >35% the last time i had to do this (iirc against the VS 2008 implementation) MS provided a special memcpy variant for 360 that did this for you using the PPC dcb* instructions and good use of the wider registers.
        eliasmacpherson 13y ago
        Am gobsmacked by the differences in benchmarks: http://nadeausoftware.com/articles/2012/05/c_c_tip_how_copy_memory_quickly#Benchmarkresultsndashcompiledwithoptimizations http://nadeausoftware.com/articles/2012/05/c_c_tip_how_copy_... http://software.intel.com/en-us/articles/memcpy-performance http://software.intel.com/en-us/articles/memcpy-performance
        jheriko 13y ago
        this looks pretty recent, good to know that memcpy is improving (maybe). i suspect the reason icc is winning so hard is exactly what i mention - cache hints and good register usage. the things is that stuff isn't new... its much more than 10 years old now. no memcpy implementation has an excuse to be that slow under any compiler imo. i'd imagine the intel guys will make use of this stuff because its why they put it in the hardware to start with... :) incidentally, as a complete tangent, really great bunch of guys to work with if you get the chance - at least in my experience. a definite passion for and focus on performance in a serious way. :)
BudVVeezer 13y ago
Those aren't "Microsoft functions"; they're C's optional Annex K functions which Microsoft happens to mostly implement (though in true MS fashion, they did manage to get a few wrong before the standard was finalized).
- comex 13y ago
  They were Microsoft functions long (6 years?) before they were standardized.
  - BudVVeezer 13y ago
    Microsoft led the standardization process for the Annex K functions.
  - derleth 13y ago
    > They were Microsoft functions long (6 years?) before they were standardized. And most of what's in ANSI C (the first C standard, before ISO stepped in, from 1989) was in C compilers before ANSI C existed. I think void and void* were the only things ANSI C really added to the language. My point is, the C standards body likes to standardize common usage, and 'what a Microsoft compiler does' is pretty close to being common in some parts of the world.
    - eliasmacpherson 13y ago
      They also 'standardised' threads which were hardly common usage.
      - derleth 13y ago
        > They also 'standardised' threads which were hardly common usage. Didn't the POSIX standard do that, as opposed to the ANSI C standard?
        ygra 13y ago
        Well, yes, for operating systems that implement POSIX. Which doesn't account for all of them, last I checked.

aaronbrethorst 13y ago

memcpy_s: http://msdn.microsoft.com/en-us/library/dswaw1wk(v=vs.80).aspx http://msdn.microsoft.com/en-us/library/dswaw1wk(v=vs.80).as... edit: I read the link you included and I have to take exception with this line: it’s a perfectly safe function if you use it properly Sure, same thing as automobiles, alcohol, condoms… Problems arise because people do not use them correctly.

penguindev 13y ago
LOL, That's a fucking joke! "If the source and destination overlap, the behavior of memcpy_s is undefined." Wow, way to improve things microsuck! It's not like anyone has ever mistakenly used memcpy on overlapping buffers....
- deleted 13y ago
  [deleted]
- quotemstr 13y ago
  You can use memmove_s, you know.
- EpicEng 13y ago
  The same is true for memcpy ya know... that's what memmove is for. Perhaps you should make sure you know what you're talking about before bashing others ("others" who are probably far more experienced than yourself).
  - tedunangst 13y ago
    Eh, I believe that was his point. If you're going to go to the trouble of building a safe memcpy with no sharp corners, don't leave the overlapping buffer razor blade sticking out. Perhaps you should settle down.
    - EpicEng 13y ago
      Hmmm... well perhaps I did miss that, but your (his?) suggestion is a terrible idea. memcpy should be fast. Checking for overlap slows it down. Want to allow for overlap? Use memmove, that's what it's there for. I don't want to have to roll my own optimized version of memcpy when I know that I don't need any special handling or error checking.
      - jheriko 13y ago
        "memcpy should be fast" you know memcpy is my 'classical' example of why you should never trust library code to be well optimised. its almost always a dumbass byte-by-byte copy - its pretty much the worst case performance unless you go out of your way to slow down your implementation. the speed improvement from good register usage and appropriate cache hints was >35% the last time i had to do this (iirc against the VS 2008 implementation) MS provided a special memcpy variant for 360 that did this for you using the PPC dcb* instructions and good use of the wider registers.
        eliasmacpherson 13y ago
        Am gobsmacked by the differences in benchmarks: http://nadeausoftware.com/articles/2012/05/c_c_tip_how_copy_memory_quickly#Benchmarkresultsndashcompiledwithoptimizations http://nadeausoftware.com/articles/2012/05/c_c_tip_how_copy_... http://software.intel.com/en-us/articles/memcpy-performance http://software.intel.com/en-us/articles/memcpy-performance
        jheriko 13y ago
        this looks pretty recent, good to know that memcpy is improving (maybe). i suspect the reason icc is winning so hard is exactly what i mention - cache hints and good register usage. the things is that stuff isn't new... its much more than 10 years old now. no memcpy implementation has an excuse to be that slow under any compiler imo. i'd imagine the intel guys will make use of this stuff because its why they put it in the hardware to start with... :) incidentally, as a complete tangent, really great bunch of guys to work with if you get the chance - at least in my experience. a definite passion for and focus on performance in a serious way. :)

BudVVeezer 13y ago

Those aren't "Microsoft functions"; they're C's optional Annex K functions which Microsoft happens to mostly implement (though in true MS fashion, they did manage to get a few wrong before the standard was finalized).

comex 13y ago
They were Microsoft functions long (6 years?) before they were standardized.
- BudVVeezer 13y ago
  Microsoft led the standardization process for the Annex K functions.
- derleth 13y ago
  > They were Microsoft functions long (6 years?) before they were standardized. And most of what's in ANSI C (the first C standard, before ISO stepped in, from 1989) was in C compilers before ANSI C existed. I think void and void* were the only things ANSI C really added to the language. My point is, the C standards body likes to standardize common usage, and 'what a Microsoft compiler does' is pretty close to being common in some parts of the world.
  - eliasmacpherson 13y ago
    They also 'standardised' threads which were hardly common usage.
    - derleth 13y ago
      > They also 'standardised' threads which were hardly common usage. Didn't the POSIX standard do that, as opposed to the ANSI C standard?
      - ygra 13y ago
        Well, yes, for operating systems that implement POSIX. Which doesn't account for all of them, last I checked.