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

  1. #76
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    I think it's time you stop living in 1989 and accept that you can no longer have a language like C with just hosted and standalone conforming environments to distinguish its features. It may have made sense then, but 22 years later the hardware diversified itself too much. C99 had its share of mistakes that C11 tried to correct. Why would you, for instance, force a compiler to support VLAs if the compiler is meant for an embed system with bounded stack growth? Or why would you force a compiler to support VLAs in an embedded system with very limited resources, when VLAs don't let you recover from OOM errors?

    You can argue in that case we should remove VLAs. But I ask you, what for?
    Will you just start refusing additions unless all compilers can implement them? Languages like C++ and others don't suffer from these technicalities because they tend to aim at a smaller subset of the hardware ecosystem. But C is more expansive in WHERE it can be used. If there is anyone you should be arguing with, is the implementation developers; if they can support an optional feature and choose not to, then it's them that are at fault and they cannot shield themselves on the fact the feature carries an "optional" tag. It would reveal a gross misunderstanding of its purpose.

    6 years later and we still don't have a C11 rationale document to stand by. But from all I see (and I am still learning the language, so I haven't seen enough), most implementations developers aren't so confused as you and they have supported VLAs where it makes sense to support them.
    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.

  2. #77
    Registered User
    Join Date
    Jun 2011
    Posts
    4,513
    Quote Originally Posted by Mario F. View Post
    I think it's time you stop living in 1989 and accept that you can no longer have a language like C with just hosted and standalone conforming environments to distinguish its features. It may have made sense then, but 22 years later the hardware diversified itself too much. C99 had its share of mistakes that C11 tried to correct. Why would you, for instance, force a compiler to support VLAs if the compiler is meant for an embed system with bounded stack growth? Or why would you force a compiler to support VLAs in an embedded system with very limited resources, when VLAs don't let you recover from OOM errors?
    Just as a point of interest - quite a few of the compilers for low-level (e.g. 8-bit) embedded devices I've worked with avoided this mess by simply declaring that they conform only to C89 (apart from the custom parts such as "bit" data type, etc).

  3. #78
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    Is this a bad time to mention that I've now since ditched GTest in favor of Catch? Catch is a lot nicer simply because it's a header-only library so setting it up is trivial.

  4. #79
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    That's fine. But you may want to open a facebook and a twitter account, if you are going to document your entire programming career.
    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.

  5. #80
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    Ah, I knew I'd get ya with that one, you old grouch XD

    Maybe I'm sharing because it's my hope that other people will in turn share their experiences and we can communicate and compare tools and experiences and both learn something.

  6. #81
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Well, a cursory look revealed it doesn't support mocking, which may or may not be a big deal depending on how deep you go with your objects.
    Mocking is sort of essential for us, who end up building complex objects or complex object hierarchies that tend to be expensive to generate for the sole purpose of unit testing. But regardless, I'd say you would probably be better off using a traditional tried-and-tested xunit framework, instead of relying on less known solutions that promise the world on a shoestring. Simplicity, the likes of offering a UT framework on a header file, tends to come with a cost and I suspect sooner or later you'll find it.

    EDIT: OTOH, doesn't VStudio come already with a very good unit testing solution? I seem to remember, yes.
    Last edited by Mario F.; 12-01-2016 at 08:48 PM.
    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.

  7. #82
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    That's actually a really good point, I hadn't thought of mocking. I don't actually know enough to comment with any sort of real insight but my first instinct is to ask, can't we just create our own mocks? There are techniques that we can do that don't necessarily necessitate a testing framework. If we need to mock something specific, can we not rely on tools like PIMPL and duck typing? The STL containers are a good example. They're all Allocator aware (and this is where I start talking out my ass) and I assume this means they use duck typing as well. It'd be simple (I tell myself) to implement an allocator mock and substitute it in. Maybe it'd force you to have an awkward design pattern but compared to the awful duck typing in JS, C++'s duck typing seems a lot more palatable.

  8. #83
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    2,158
    Quote Originally Posted by MutantJohn View Post
    C++'s duck typing seems a lot more palatable.
    C++ doesn't have duck typing. What you're thinking of is either inheritance or specialization overloading.
    Last edited by Yarin; 12-01-2016 at 10:35 PM.

  9. #84
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    Quote Originally Posted by Yarin View Post
    C++ doesn't have duck typing. What you're thinking of is either inheritance or specialization overloading.
    Conceptually, they're similar enough, imo.

    Basically, I just mean this:
    Code:
    // Example program
    #include <iostream>
    #include <string>
    
    struct duck_t
    {
    public:
        auto quack(void) const -> void
        {
            std::cout << "quack\n";
        }
    };
    
    template <typename Duck>
    auto quack_checker(Duck const& duck) -> void
    {
        duck.quack();
    }
    
    int main(void)
    {
        duck_t duck;
        quack_checker(duck);
        return 0;
    }
    This is basically JS duck typing with a static compilation check. And it's waaaaaaaaay better for that reason.
    Last edited by MutantJohn; 12-01-2016 at 10:50 PM.

  10. #85
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    That won't solve the problems that mocking addresses. You would just be redirecting object construction and usage around and it is closer (although not the same) to another technique called stubbing. What you are doing there is like adding a new coat of paint to a complex object hierarchy and pretending that you have simplified it.

    Mocking will instead create "fake objects" that simulate the real objects. You won't, of course be mocking the object you want to test, but those dependencies and relationships around that object. Mocking is sort of cool. But, like I said, only really useful if your object hierarchies are complex and run deep, or if the test has effects on the system that you do not wish to preserve after unit testing.
    Last edited by Mario F.; 12-02-2016 at 03:51 AM.
    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.

  11. #86
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    Oh man, you might be right about mocking O_o

    I finally took a look at GMock. It's pretty cool. But it's definitely not necessary for my project. I'll have to keep that in mind though for future projects and what tools to use. "Do I need to care about mocking?" was a question I would've never thought about without your input so thank you, Mario.

  12. #87
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by MutantJohn View Post
    Conceptually, they're similar enough, imo.

    Basically, I just mean this:
    I believe this technique is labeled "static polymorphism" in C++.
    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.

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