Deraynger Deraynger

Niner since 2010


  • C9 Lectures: Stephan T Lavavej - Advanced STL, 6 of 6

    *I give up*

  • C9 Lectures: Stephan T Lavavej - Advanced STL, 6 of 6


  • C9 Lectures: Stephan T Lavavej - Advanced STL, 6 of 6

    @Charles: When? My favorite series has come to a halt for a while now Tongue Out

  • GoingNative 3: The C++/CX Episode with Marian Luparu

    Followed this thread since the beginning. Now that Tomas posted some sample code, I wonder what Herb and Jim (and everyone else that has been posting here) have to say about it.

  • C9 Lectures: Stephan T Lavavej - Advanced STL, 6 of 6

    @STL: I understand what you mean, but I think it's a good way to communicate intent. I still think you should do some STL videos regarding generally used "Patterns", I took ages to google, and find the right wording, to find CRTP. I think those are basics that anyone writing C++ should know. I would have written my code completely differently if I had known that. Especially I use the patterns quite often (the quality of it is another thing), so I knew, I need something that does X, and remembered something regarding that, by having read the Design Patterns book. Looked it up and implemented it. Now when I see the code I know, oh yeah, that's this or that pattern and works like this or that. Just my 2 cents.

    I assume you used the patterns all before, just never thought of it as a pattern. If someone not so smart like you would look at it, I believe if they see certain constituents, they'd know what pattern you used, and if naming the methods/classes etc. in a similar way, it's even easier, like MakeXyz() or class AbcStrategy etc.

    Matt> b) design patterns - intro into modern design patterns and which to use

    I am actually not a fan of Design Patterns. I've read the book, and I didn't think it was that useful. I think in terms of C++ idioms instead (e.g. iterators, functors, non-virtual interfaces).

  • GoingNative 1: VC++ vNext, CRT, C++ and Beyond

    To anyone who's interested to have the coloring now. There's an add-in called Highliterr that does the coloring for C++ on VS2010.

  • C9 Lectures: Stephan T Lavavej - Advanced STL, 6 of 6

    STL> There is a time and place for inheritance (e.g. type erasure is powered by it), but it shouldn't be used when templates are more appropriate.

    Ok, so I'll see about rewriting everything Tongue Out. I have an idea for you or the authors, provided you/they have enough time: Rewrite the Design Patterns: Elements of Reusable Object-Oriented Software book using templates instead of inheritance Big Smile

    STL> Remember that I am not a user, I am a Microsoft employee. The company owns everything I write on company time.

    Yes, I asked with enough details in the e-mail. But Your ASCII tree etc. was probably written in your own time. Anyhow, then I'll just have to rewrite the code from scratch provided that I ever sell a product containing your code.

    Deraynger> I use inline usually for tiny things (not even for calculations), but mainly just for setters/getters.

    STL> The correct way to design a class is to think about the abstraction you want, devise an interface to provide that abstraction, and finally implement it. Sometimes you do end up with member functions that directly return data members without doing anything else (or more rarely, directly modify without doing anything else), but it should not be an explicit goal of your design. If it happens too often, that may be a sign that your abstractions are too low-level.

    As I mainly do OpenGL stuff, I do need a getter/setter for X, Y, Z etc., of course providing other functions too, based on those members. So it is a bit low level, but necessary IMO. Otherwise I agree that the functions should provide other things than just get/set. Other areas are when using inline is when checking e.g.

    inline bool AreVertsEmpty(void) { return myTriangleStripVerts.empty() && myTriangleVerts.empty(); }

    I don't like calling them float GetX( void ) const and void SetX( float ), so I write them like float X( void ) const and void X( float ).

    STL> [mem_fn] & [op<<]

    Ok, thanks for the details.

  • C9 Lectures: Stephan T Lavavej - Advanced STL, 6 of 6

    @STL: Thanks so much for elaborating.

    STL> Do you want to handle arbitrary types? Then you want templates.

    To what extent is it arbitrary? If I have an interface/abstract base class, then it's not arbitrary anymore, although with templates I could probably skip the base class and use a template that checks that the class contains the functions I need.

    Deraynger> I like this diagram for choosing containers

    STL> I strongly disagree with that diagram for several reasons

    As I mentioned, I never really used the diagram, but "I usually do look at a C++ reference site to see what's better for what case, i.e. inserting in middle, reading from middle, etc."

    Regarding vectors, that's what I mainly use (especially for vertices etc.), map/multimap and in one case a stack<x, vector<x>()>.

    STL> I can point to the notice at the bottom of every C9 page, which may or may not apply to my C9 code, and wouldn't be useful if it did!

    [Edit] I sent an e-mail to C9 regarding the different questions. Theoretically I consider it quite open for interpretation, so IMO your code falls under user-posted content (see:">, where you can provide a CC-license (which doesn't state it has to be the same as C9s CC-license), so you could theoretically say that we can use all of your posted code freely and commercially and the license is the following:, with the extra permissions that we can use it with or without a copyright notice with your name (provided you want that) Big Smile, and as the license states, it has to be visible that this license is used.

    I'll write when I get an answer from C9.

    STL> [Inlines]

    I use inline usually for tiny things (not even for calculations), but mainly just for setters/getters. But if I know that it shouldn't be for virtual functions, then I also won't use them there Smiley


    Small question. If I use a for_each, can't I create a member function (preferably non-static) defined in the same class, or is it like a functor, where a seperate class/struct is necessary?

    Thanks again for all your detailed answer (especially on the containers and the diagram).


    STL> The problem with op<<() is that it mixes code and data.

    Can you explain it, I don't get it Perplexed


    Charles> Would you like to see a monthly show focusing on native dev with a rotating cast of characters and topics? Would you like a native-focused show that thrills and delights, educates and challenges? Well, hold on pardners... It's a comin'!]

    I'd love it!

  • C9 Lectures: Stephan T Lavavej - Advanced STL, 6 of 6


    Great video, thanks so much!

    Regarding the FizzBuzz task you recommended to Ivan, I guess I'll have to do the same thing.

    In C# I have no problems with generics (which is IMO far from templates), but I can imagine when using it. In C++ I have the problem (and it is a problem IMO), that I can't detect when templates would be valuable. In C# we have e.g. a generic Presenter (MVP), where we can pass some other class that the derived class depends on (IOC) or some other examples, where I know when to use generics when I see it. I'm sure I have a lot of code that could be optimized using templates. Of course I should be creating a few, so I see/learn the benefits of when to use them.

    C++/OpenGL I do for fun on some evenings, after doing C# all day at work (learnt a lot about C++ in the last 1.5 years -- if I compare myself to questions from KerrekSB etc. I've got tons to learn).

    I like this diagram for choosing containers: (at the bottom. unordered_... not included), though I usually do look at a C++ reference site to see what's better for what case, i.e. inserting in middle, reading from middle, etc.

    Previous video you mentioned in the comments, you can't comment on legal things, but you can say if we can use your code commercially/non-commercially etc. like the code above for printing an ASCII tree.

    You actually used an ifstream this time Smiley I often use "pure" C++ classes (including ifstream). What I don't get, I recently saw this on ifstream provides an interface to read data from files as input streams. IMO that means, it's an interface, so I'm suppose to use an fstream if it's not meant to be an interface or to pass it an fstream to a function I could use Do(const ifstream& aStream);??? Or what am I misunderstanding. Does interface in this case mean a facade/wrapper, and not an interface (i.e. C#'s meaning of interface). Must be, since its functions are obviously not pure virtual.

    Another question that someone may know. If I inherit from a base class, is it a bad idea to do an inline on an overriden (for virtual)/implemented (pure virtual) function in the derived class (obviously)?


  • C9 Lectures: Stephan T Lavavej - Advanced STL, 5 of n


    Thanks a lot for taking your time to answer my questions.

    Regarding #1, so it's fine then that I do namespace kittens { <functions> } in the source file?

    Regarding #2, not declare using directives/declarations in headers, I know that from your first STL series Smiley

    Regarding #3, you basically answered it with boost. What I meant was, I have boost/kittens/detail/feedme.hpp and need to reference something, say boost/kittens/cat.h, e.g. a friend. In feedme.hpp would you do: friend class boost::kittens::cat;? Second part of it was, if it's refering to something in boost/helpers/stl_utils.hpp, would you use the fully qualified name (which you would, based on your answer to #4).


    New questions (while still waiting Tongue Out). This always bothers me, since I don't know these licensing details (maybe you might).

    Are we allowed to use your code legally for ourselves, by just downloading it, and should or may we add the following 2 lines?

    // Copyright (c) Stephan T. Lavavej 2011. All rights reserved.

    // Copyright (c) Dopefish 2011. All rights reserved.

    Can we also just add our copyright (although I would probably add both, so I know where I got it from)?

    I got some files from someone online, he said I could use it how I want, commercially/modified etc., does that mean I can also change the copyright notice (would still keep his name in the file, where it still somehow represents the same class/file)?

    What happens if I retype a code from someone, by looking at it, and modifying it. Do I still need to include his copyright notice? What's if the code is (maybe partially) on a blog. Can I then just use it without hist copyright notice?

  • C9 Lectures: Stephan T Lavavej - Advanced STL, 5 of n

    A few newbie questions (while waiting for part 6) regarding namespaces etc.:

    1. In the .cpp file, what do you consider best (or what's correct)?

    • Use a using namespace MyNamespace;
    • Surround it with the same namespace i.e. namespace MyNamespace { <All functions> }
    • Use the namespace like void MyNamespace::MyClass::Do() { <code> }

    2. If I have a Class in src/Utils/MyClass.h, and it relies on src/Utils/Detail/OtherClass.h, should I

    •  add the whole namespace i.e. Utils::MyClass::DoSth() { Utils::Detail::OtherClass }
    • or just the deeper data, i.e. Utils::MyClass::DoSth() { Detail::OtherClass
    • and should I (again) use a using like using Utils::Detail::OtherClass  (or using Detail::OtherClass based on the above point)?
    • or rather of the namespace: using namespace Utils::Detail;

    3. Do you add the whole namespace when calling something from another structure?

    • Like src/Helpers?
    • and in the same structure?

    4. Should I include from the base path (like boost does it)?

    • #include "Utils/Detail/OtherClass.h"
    • or only lower structure, if I'm calling it within Utils then just #include "Detail/OtherClass.h"

    5. What's if it's lower, i.e. from Details back to some other class, e.g. Helpers, what do you recommend?

    • #include "Helpers/SomeHelper.h"
    • #include "../../Helpers/SomeHelper.h"

    I know about using a shorter name for long namespaces (not sure of the syntax): using Det = Utils::Details; or something like that, but am not such a fan of it.

    If I could decide, I'd choose, deeper Namespaces don't need to be used with the whole namespace, just the deeper part, e.g. Detail::OtherClass if calling from Utils to Utils/Detail. Higher ones would need the whole one (but that makes it less readable IMO).

    In boost, the only thing I found in a source file was a huge list of using Full::Namespace::SomeClass;

  • C9 Lectures: Stephan T Lavavej - Advanced STL, 5 of n

    @STL: Cool, thanks for the info!

View All