Thread: So, I'm trying out Google's C++ test library...

  1. #46
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by MutantJohn View Post
    This isn't what Yarin meant. He meant stack-based allocations. Unless you have a fancy stack allocator implementation, you shouldn't do VLAs in C++. If C supports them, awesome.
    I know, but variable-length stack arrays in C99 has been criticized, so the C++ committee still haven't figured out how to do it "right" yet. vector is best we're going to get, but if you've got a fast allocator, does it matter if it's stack or heap?
    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. #47
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    Yeah, it means a crap ton! A formal dynamic allocation is significantly slower than using the stack. Some of the best results I've gotten are because I took phantom's advice when he said that stack allocations are basically free. They really are! If you treat your stack well, it'll treat you well.

  3. #48
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    You can allocate a fixed block of heap memory at the start of your program and use that as a stack. Problem solved.
    (Hence "fast" allocator.)
    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.

  4. #49
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    But that also requires a kernel to handle that request. I know that's not always a guarantee in the case of the embedded world.

  5. #50
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    In the embedded world, you can just point a pointer to some usable memory to use as a stack in your allocator. And there are usually API calls that you can use to get dynamically allocated memory on all but the simplest of embedded systems.
    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. #51
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    2,158
    Quote Originally Posted by Elysia View Post
    ...So you're going to go into stuff that don't match 1:1 between the languages, the area I decided to skip. It's true that some stuff don't match 1:1, but that doesn't mean C++ can't do it.
    Move the goalposts much? Who was talking about nonemulatable features? You said C++ was a strict superset of C, and so I gave an incomplete list of some examples demonstrating the contrary.


    Quote Originally Posted by MutantJohn View Post
    This isn't what Yarin meant. He meant stack-based allocations. Unless you have a fancy stack allocator implementation, you shouldn't do VLAs in C++. If C supports them, awesome.
    I was actually just referring to the construct. Anyway, you can still dynamically allocate on the stack in pure C++ with alloca().




    Quote Originally Posted by MutantJohn View Post
    Also, isn't __restrict__ an actual thing in C but is optionally implemented by most compiler vendors in C++?
    It's just "restrict" in C, but yes. This is even functionality you can't match in C++.

  7. #52
    Make Fortran great again
    Join Date
    Sep 2009
    Posts
    1,413
    Quote Originally Posted by Yarin View Post
    Anyway, you can still dynamically allocate on the stack in pure C++ with alloca().
    (Not jumping back into the argument, just never heard of alloca()) Isn't this nonstandard? Googled it and didn't see that it was standard C or C++, and not even POSIX. One of the GNU one-offs.

  8. #53
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Angola
    Posts
    8,445
    Quote Originally Posted by Epy View Post
    (Not jumping back into the argument, just never heard of alloca()) Isn't this nonstandard? Googled it and didn't see that it was standard C or C++, and not even POSIX. One of the GNU one-offs.
    It's an extension, but pretty much ubiquitous across all systems. It wouldn't be part of POSIX though, since this standard doesn't deal with memory allocation of any sort.

    Quote Originally Posted by Elysia View Post
    You can allocate a fixed block of heap memory at the start of your program and use that as a stack. Problem solved.
    Quote Originally Posted by Elysia View Post
    In the embedded world, you can just point a pointer to some usable memory to use as a stack in your allocator. And there are usually API calls that you can use to get dynamically allocated memory on all but the simplest of embedded systems.
    Yes, and I can make a stack of pizza boxes. It's still not a memory stack.
    Anyways, more to the point: If your purpose all along was to name functional alternatives to non-existing language features, then you already lost. Because there is too nothing that C++ does that can't be done in C.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  9. #54
    Make Fortran great again
    Join Date
    Sep 2009
    Posts
    1,413
    Question 7.32

    no bueno

  10. #55
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    Yeah, alloca has more of a code smell than a dead fish hidden somewhere in your codebase. Or you're developing specifically just for one platform and have no plans to ever, ever migrate the code away from that.

  11. #56
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    2,158
    Quote Originally Posted by MutantJohn View Post
    Yeah, alloca has more of a code smell than a dead fish hidden somewhere in your codebase.
    Maybe, but no more than non-tailcall, untrampolined recursion, which is very commonplace.

    Quote Originally Posted by MutantJohn View Post
    Or you're developing specifically just for one platform and have no plans to ever, ever migrate the code away from that.
    Why? I've never seen a general non-embedded platform that doesn't support it.

  12. #57
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    Well, the advantage of non-trampolined recursion is that it's much more portable :P

    Regardless of platform support for alloca, it is a relatively moot point to argue because of VLA support which you should be using anyway. And then I read the wiki and apparently C11 made it no longer a requirement. So maybe alloca does have a place again? Maybe their reasoning is the same as yours, Yarin. That the implementation is already common enough that there's no point in making VLAs a hard requirement anymore.

  13. #58
    Make Fortran great again
    Join Date
    Sep 2009
    Posts
    1,413
    Quote Originally Posted by MutantJohn View Post
    Regardless of platform support for alloca, it is a relatively moot point to argue because of VLA support which you should be using anyway. And then I read the wiki and apparently C11 made it no longer a requirement. So maybe alloca does have a place again? Maybe their reasoning is the same as yours, Yarin. That the implementation is already common enough that there's no point in making VLAs a hard requirement anymore.
    Point should be that in the C vs. C++ argument, alloca means nothing because it's non-standard. If it's not part of the standard library or POSIX, then poo on it.

  14. #59
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Angola
    Posts
    8,445
    Quote Originally Posted by MutantJohn View Post
    And then I read the wiki and apparently C11 made it no longer a requirement. So maybe alloca does have a place again?
    It could on those platforms not supporting VLAs.
    It's important to keep in mind though that the C11 introduction of conditional (optional) language features is not a statement of undesired features. It merely indicates that implementations are free to not implement that language feature and set its defining macro accordingly. VLAs, along with other optional features, carry a certain burden that may not be desirable on embedded systems, but highly desirable on other systems. Hence the need to make them optional. VLAs are implemented in all major compilers for the major platforms though.

    The only really controversial feature of the C11 standard is Annex K, concerning bounds checking interfaces.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  15. #60
    Registered User
    Join Date
    May 2010
    Posts
    4,465
    The only really controversial feature of the C11 standard is Annex K, concerning bounds checking interfaces.
    Why do you consider it "controversial"?

    Jim

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Google Written Test question...!
    By manasij7479 in forum General Discussions
    Replies: 15
    Last Post: 10-25-2013, 06:00 PM
  2. Reading Google Sketchup (.skp) or Google Earth (.kmz)
    By Zeeshan in forum Game Programming
    Replies: 9
    Last Post: 03-07-2008, 05:25 PM
  3. Test at http://www.artlogic.com/careers/test.html
    By zMan in forum C++ Programming
    Replies: 6
    Last Post: 07-15-2003, 06:11 AM

Tags for this Thread