Jump to content

  • Log In with Google      Sign In   
  • Create Account

l0calh05t

Member Since 16 Dec 2000
Offline Last Active Today, 06:04 AM

#5284016 Naming conventions, software documentation and version control

Posted by l0calh05t on 29 March 2016 - 03:25 AM


Simple. They find className.doSomeThing() more readable than class_name.do_some_thing().
That's it, and it's a perfectly valid reason.

 

IMO it is the opposite. But to each their own. Personally I think in many cases it was just "inherited" from the Java coding standard, because that was one of the most popular/well known of the codified standards.




#5282636 GIT vs Mercurial

Posted by l0calh05t on 22 March 2016 - 09:03 AM


Subversion is out.

 

Why? It works well for binary assets. Or at the very least a lot better than GIT (or any DVCS for that matter).




#5282583 Naming conventions, software documentation and version control

Posted by l0calh05t on 22 March 2016 - 03:26 AM

It might be informative to look at the naming conventions used in the standard library (defined through an ISO standards document)

 

This. A thousand times this.

 

Why is it that so many C++ programmers choose a Java style and (often) also throw out any and all uses of the standard library... 




#5282557 GIT vs Mercurial

Posted by l0calh05t on 22 March 2016 - 02:50 AM

Have any of those complaining about subversion's branch/merge handling actually tried it with a version less than about 5 years old? Since SVN started noting branch and merge information in properties it has become much, much better at handling them. Haven't had any serious problems in a long time.

 


Pros:
- It doesn't create .svn folders everywhere.

 

Subversion hasn't done that for quite some time either.




#5279634 When you realize how dumb a bug is...

Posted by l0calh05t on 05 March 2016 - 04:39 AM

Oh right, for some reason I thought that was GLint =S (that said, I think OpenGL returns 0 on error when it'd return an identifier, if anybody wonders)

Not in this case, glGetUniformLocation returns -1 if the uniform is not available.

 

But you probably shouldn't assert on that, as it might just have been optimized away...




#5274936 Have You Ever....?

Posted by l0calh05t on 09 February 2016 - 01:50 AM

 


was copy-pasted in 5 different locations in the code

I spent a week creating such situation. Now I get to fix it.

 

If only everyone were so diligent as to clean up their own mess.




#5274854 Have You Ever....?

Posted by l0calh05t on 08 February 2016 - 09:15 AM

Have you ever joked about developing a keyboard that delivers an electric shock if ctrl-c or ctrl-v are pressed and later thought there really is a need for these after having to fix some idiotic bug that was copy-pasted in 5 different locations in the code?




#5274612 Have You Ever....?

Posted by l0calh05t on 06 February 2016 - 03:02 AM

Have you ever tried to refactor a big-picture part of your code's architecture, and bit off a larger chunk than you could chew at once, taking more than two weeks to get your code even compiling again, let alone running?

all the time... people just love their singletons and shared state... leading to any change being a big-picture change...




#5271725 When you realize how dumb a bug is...

Posted by l0calh05t on 18 January 2016 - 11:54 AM

 

(I'm not sure how obvious it is what exactly happens here. I've only programmed using OpenGL and c++ on my own. Feel free to ask). 

 

m_VboID isn't initialized, so glGenBuffers(1, &m_VboID); might not get called, but since you were compiling in Debug mode, the compiler initialized it for you, hiding that the bug existed?

 

additionally, glGenBuffers is only called if(m_VboID != 0), so only if m_VboID is already set to a non-zero value.




#5269202 Criticism of C++

Posted by l0calh05t on 04 January 2016 - 09:37 AM

 


C++ is a terrible language, and all the others are even worse.

QFT.

 

Almost every modern programming language has been designed to correct for perceived flaws in C++. Unfortunately, almost all* of them have focused on the wrong flaws.

 

* Rust might actually be on the right track, if they become a little more pragmatic.

 

I agree. Both with the original statement and that Rust might be on the right track, if not always entirely practical.




#5265402 Replay & recorded games

Posted by l0calh05t on 08 December 2015 - 02:07 AM

 


frob: Now I realise I had made an assumption which I may not have made clear enough - I was referring to 'floating point' as just the bits covered by the IEEE 754 standard. I accept that everything outside it (like sin, inv sqrt etc) may not always give the same result across all processors.

Good luck performing 3D world operations and physics manipulations without them.

 

You don't have to. You only need to provide your own versions (which could also be "fast approxiate" versions, depending on your needs) that don't use processor intrinsics like fsin/fcos.




#5264860 Replay & recorded games

Posted by l0calh05t on 04 December 2015 - 06:21 AM

 

Hopefully those links will change your mind. Otherwise, scroll back up to the Gaffer On Games articles about Deterministic Lockstep, and the other on Floating Point Determinism.


Unless you jump through a lot of very careful hoops, turn off a lot of optimizations, and introduce some slower operations, you can get different results even on the same computer with the same executable and the same exact input.


No, all the cases you mention are caught by:

I use 32-bit float operations (SSE doesn't internally use 80-bit extended precision) with no denormals (FTZ bit set), code floating point atomically (e.g. no x = a + b + c) and use compiler flags to restrict float optimisations. And you can only use + - * / sqrt() operations - not things like sin().


Yes, this prevents the compiler using fancy instructions like fused-multiply-add and reciprocal sqrt. But I don't consider the performance penalty significant, given the benefits it gives for networking model it enables.

As evidence of my claim of IEEE 754 specifying the exact binary result of calculations, I cite 'What Every Computer Scientist Should Know About Floating-Point Arithmetic' by David Goldberg:

http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

Which says:

"The IEEE standard requires that the result of addition, subtraction, multiplication and division be exactly rounded. That is, the result must be computed exactly and then rounded to the nearest floating-point number (using round to even)."

"One reason for completely specifying the results of arithmetic operations is to improve the portability of software. When a program is moved between two machines and both support IEEE arithmetic, then if any intermediate result differs, it must be because of software bugs, not from differences in arithmetic."

"There is not complete agreement on what operations a floating-point standard should cover. In addition to the basic operations +, -, × and /, the IEEE standard also specifies that square root, remainder, and conversion between integer and floating-point be correctly rounded. It also requires that conversion between internal formats and decimal be correctly rounded (except for very large numbers)."

 

Although I mostly agree (and am very annoyed by the apparent majority of programmers who seem to think floating point is some kind of unspecified magic), there is one case that is not covered by your original quote: parallelization. If you parallelize any kind of reduction (e.g. a sum) this can introduce non-determinism, unless you ensure that the order of operations is always the same. Integers with wraparound do not have this problem, however saturating integer operations have the same problem.




#5259246 The wrong way to count lines of code

Posted by l0calh05t on 27 October 2015 - 05:24 AM

 

LOC is clearly an outdated metric. Its weird that people go to the effort of counting lines while each counting differently.
I'd suspect making a .tar.gz of all source files and comparing size in bytes might be more useful for comparing project complexity, but still flawed. At least it would condense obvious bloat like copy-paste and extraneaous whitespace, which you could then find out about if the .tar significantly increases in size but the .tar.gz not.

Hah, that's a good metric: compression ratio.

If one project has a "better" compression ratio than another, then it's probably full of C&P, or other forms of repetition laugh.png

 

love the idea!




#5256707 The wrong way to count lines of code

Posted by l0calh05t on 11 October 2015 - 12:07 PM

The only place where lines of code are a useful is when refactoring. Lines of code removed (while all tests continue passing of course) is a great metric.




#5254236 Simple GUI library to use with openGL

Posted by l0calh05t on 27 September 2015 - 05:14 AM

TurboBadger looks nice https://github.com/fruxo/turbobadger






PARTNERS