Anyone interested in giving feedback on program/app I created?

[deleted account xyzzy]

Custom namespaces for the most part are easy.

https://www.learncpp.com/cpp-tutorial/4-3b-namespaces/

[deleted account xyzzy]

I chose a header only version so I didn't have to go the route of creating a lib file.

Admittedly not the best practice for doing custom libraries, but since my version of the random toolkit is for hiding all the working guts in a simply interface it is a fair trade-off.

[H00G0]

@jonnin
Oh right my bad, I was just wondering about that, since I'm used to working with VS and also SDL_2.

I guess the way to go for now is to use a simple header until I have enough of these small tools to make it worth building a library from it. At which point I'll look into that too.

@Furry Guy
Oh thanks, I didn't think that would be so trivial. How do you know when to use custom namespaces though, only when you have two function names colliding or do you make namespaces for sort of 'themes' in your programs, for instance mathematics, logic handling, etc?

[deleted account xyzzy]

How do you know when to use custom namespaces

From the page I linked:

When you should use namespaces

When you write a library or code that you want to share otherwise, place the code inside a namespace. You can’t know what the environment your code will be used in looks like, which can quickly lead to conflicting names. Placing library code inside a namespace also allows the user to see the contents of your library by using their editor’s auto-complete and suggestion feature.

Visual Studio auto-complete works wonders with my toolkit. Type the namespace ( rtk:: ) and I get suggestions on which function from the toolkit to use.

If the function has parameters, I get a friendly reminder what the parameters can be. In the case of rtk::rand whether it needs two ints or two doubles.

[deleted account xyzzy]

Why did I chose to use a custom namespace for the toolkit? So I could reuse the function names rand/srand without having name clashes. I'm a cheeky bastard like that.

+ more learning about namespace use.

One of the best ways to learn to code C++ is to code C++.

The next revision of the toolkit might use templates, so I can stretch my understanding of how they work.

[H00G0]

I see what you both mean yes. And it's true that the auto-complete feature in VS has saved me countless hours, if I had to type everything every time. It made a huge difference when I transitioned from DevC++ to VS, it's hard to go back now..

I had another question about include: If several of your headers include the same things, is it beneficial in any way to make another header that include all those and then include that header in the other ones?

Let's say you have a header A.h, B.h and C.h. B and C are included in A and they both include <string> and <vector> for instance. Is it better to keep it that way or make an other D.h header that include <string> and <vector> and simply include D in B and C?

[jonnin]

for c++ standard includes just use them in each file that needs them. That way the file is more stand-alone and can be moved to another project without having to also add in your special file that isn't doing anything useful.

for your own library, both approaches have merits. I prefer to keep things as split up and stand alone as possible but that means lots of includes in some programs. Ive lumped them before too, and that gets you everything (need it or not) with less trouble. The compiler gets rid of things you don't need so that isn't a problem, except, it compiles the crap you don't need before it figures that out, so very very large programs (anything that takes more than 15 min to compile in my book) should not use an approach that adds to compile time with this kind of bloat.

I don't think any program I have ever done flying solo has taken more than 1-2 min to compile on a bad day. So that issue crops up in something built by a team or a very, very ambitious solo project. Or a very slow computer, I guess :)

[H00G0]

for c++ standard includes just use them in each file that needs them. That way the file is more stand-alone and can be moved to another project without having to also add in your special file that isn't doing anything useful.

I see what you mean, indeed it makes more sense to have them portable.

I prefer to keep things as split up and stand alone as possible but that means lots of includes in some programs.

So you mean like one function/class per header? or one feature per header?

I haven't done anything too big myself and the most I've waited for compiling must have been like 1 min on my old potato laptop, now it's done in no time with my current PC.

[dhayden]

Jonnin, the rand2 class you gave on the previous page has a serious flaw: Only the first instance of the class matters:

int main()
{
    rand2 dummy(100,200);   // create and ignore
    rand2 r(0,10);     // I want numbers from 0 to 10
    r.seed(time(0));
    for(int i = 0; i < 25; i++)
        std::cout << r() << std::endl;
}

$ ./foo
136
139
113
200
194
116
156
134
156
145
115
184
183
157
112
176
189
139
132
141
160
142
148
170
185

I think dist should not be static:

class rand2 {
    std::default_random_engine generator;
    std::uniform_int_distribution<unsigned int> dist;
public:
    rand2(unsigned int strt=0, unsigned int fnsh=-1) :
        dist(strt, fnsh)
    {}

    void seed(unsigned int s) {generator.seed(s); dist(generator); }
    unsigned int operator()(){return dist(generator);}
};

[jonnin]

so much for doing it off the cuff. Good point