Everybody, look at my Delaunay triangulation written in C++!

[MutantJohn]

Hey All,

Look at this project I did and tell me if I did software releases right!

And I will attempt to fix my stack overflow error with large amounts of recursion. Last time, the solution was malloc/new so I'm guessing that's what it's going to have to be again.

Basically, you need Unix-like environment and gsl installed. Also, the code is like 10x faster if you pipe the output because it's just all print info.

[Elysia]

I cannot speak for the correctness of the code, but I can speak of some design decisions and advice:
- Embrace RAII. You keep too many raw pointers. Use smart pointers.
- Swallow less exceptions. If you can't handle them, you should let the propagate. Embed enough information into the exception so the catcher knows what went wrong and where.
- Don't use index operators. Use the .at() function for vectors and stuff. It helps you catch problems before they cause undefined behavior.
- Don't use C-style arrays. Use std::array and its .at() function.
- Declare variables near first use, especially in loops. And, you know, use "auto" instead of manually typing iterator types.
- Lots of repeat code. Create, catch, print error. Consider making a function that takes a lambda and additional information such as error message so you can condense the code.

[whiteflags]

- Don't use index operators. Use the .at() function for vectors and stuff. It helps you catch problems before they cause undefined behavior.

This is actually controversial advice. The at() function is not likely to be in released code. Consider that if at() can throw during normal execution, then the code needs to be fixed, and in working code, automatic bounds checking has a popular perception of being unnecessary. An out _of_range exception is a symptom of brittle code.

It really depends on whether using exceptions is part of your debugging strategy, and how often that code changes. In my experience, C++ programmers tend to use exceptions for error reporting rather than as a debugging tool.

[Elysia]

Consider that if at() can throw during normal execution, then the code needs to be fixed, and in working code, automatic bounds checking has a popular perception of being unnecessary. An out _of_range exception is a symptom of brittle code.

Then the code is brittle regardless of whether the exception is there or not and I agree that it should be fixed. But in properly written code, using .at() shouldn't matter, so what is the harm then?

In my experience, C++ programmers tend to use exceptions for error reporting rather than as a debugging tool.

It hurts to see how popular compilers like GCC happily allows for undefined behavior as the default action instead of breaking when the index operator is used, so as part of debugging strategy, I find it to be a good tool. Of course it matters what debugger and stuff you use, but I'll risk it. I'm going to say it's a good thing to do until someone proves me horribly wrong. I'd rather less newbies make out-of-bounds errors than giving bad advice a few times.

[whiteflags]

It hurts to see how popular compilers like GCC happily allows for undefined behavior as the default action instead of breaking when the index operator is used,

You might as well say it hurts to see things programmed the way the standard requires.

what's the harm?

Well, there isn't any.

But I think the difference is that some code requires you to write the check. Take for instance if you were going to use an index from the untrustworthy end-user:

size_t userindex = tools::getint("prompt >");
if (0 < userindex && userindex << somearray.size()) 
   foo(somearray[userindex]);

It's quite plain how at can help.

In code like this:

for (size_t i = 0; i < somearray.size(); i++) 
   foo(somearray.at(i));

As written, the only way this messes up is if the type of somearray actually has a broken interface. As I said, it has a perception of being unnecessary. It is even becoming more unnecessary with certain new features of C++, like the range based for loop.

[kmdv]

But in properly written code, using .at() shouldn't matter, so what is the harm then?

Using .at() by default or using operator[] by default is just a heuristic, so I won't be arguing "which is better" because it doesn't make sense. However, let me ask you how you do protect yourself against:
- Signed integer overflows
- Iterator singularity
- Accessing empty container's front/back
- Accessing any non-existent element in a container which doesn't have .at()
- Dereferencing invalid iterator
- Dereferencing null pointer (also applies to smart pointers)
- Creating std::shared_ptr cyclic references causing memory leaks

Do you throw exception on every occasion?

It hurts to see how popular compilers like GCC happily allows for undefined behavior as the default action instead of breaking when the index operator is used, so as part of debugging
strategy, I find it to be a good tool.

o_O

I suggest you googling for _GLIBCXX_DEBUG.

[Epy]

Ditch GSL, use LAPACK. LAPACK is the gold standard for linear algebra; MATLAB and just about all CFD/FEA codes I know of use it and/or associated packages, see Netlib at The Univ. of Tennessee and ORNL. You said you wanted to use this to impress employers--no one uses GSL, especially because of the GPL license.

[MutantJohn]

Oh God, LAPACK seems like 3x as confusing as learning gsl was. But I guess you're right, Epy.

Also, thank you, everybody, for the advice/criticism! I actually do appreciate it.

[MutantJohn]

Btw, this topic wasn't made to give me attention.

I mean, it was, yes, but only to a degree. I really just wanted useful input as to how to stylistically change my code or things that would be an obvious fix to a real programmer.

I don't know if that was already implied or not but I just wanted to be clear.

[whiteflags]

I don't think you have anything to worry about. Lots of people share their games or other projects in a thread.

[Vespasian]

Hey All,

Look at this project I did and tell me if I did software releases right!

And I will attempt to fix my stack overflow error with large amounts of recursion. Last time, the solution was malloc/new so I'm guessing that's what it's going to have to be again.

Basically, you need Unix-like environment and gsl installed. Also, the code is like 10x faster if you pipe the output because it's just all print info.

I dig your one comment:

"This function is truly deserving of its name"