Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 05 May 2007
Offline Last Active Today, 07:23 PM

Posts I've Made

In Topic: Should getters and setters be avoided?

12 April 2016 - 10:14 AM

You need to take what you read with a grain of salt and evaluate whether it makes sense or applies to your project. ESPECIALLY when someone starts calling something always evil like in one of the linked URLs in the original post. At this point, I don't think there is anything that is always evil. I think I actually even have a good case for a goto in my rendering engine's code, which is the pinnacle of the NO-NOes in programming. (And I'm still looking to get rid of it.) So if you tell me that something as ubiquitous and proven as getters/setters are always evil, no, just no. Misused? Yeah, I think people often write a lot more getters and setters than they actually need to. But always evil? No. (And only a Sith deals in absolutes. :P)


The truth is that there are a lot of people in the programming circles that would like to make themselves a name by calling well accepted practices "evil" just because it's bad by some completely unpragmatic point of view, or because once upon a time someone misused the pattern or principle. Now it's get/set, last week singletons were evil. Next week if someone calls having a main() function an antipattern... well, remember I called it first here. :P


Don't ignore what you read, just have critical thinking. If you're a seasoned programmer, you know more about how to go with your project than some blogger with a book so listening advices and new method can never hurt, but in the end you're the one who can judge how to go with your project. A lot of those people writing about programming practices are academic Java programmers looking to sell their books or conferences. Probably the same type of people that state completely obvious things, wrap them in silly catchy acronyms like KISS, GRASP and SOLID and write PhD thesis around those, but I disgress...


I do think though that if you're going to write a data object with full read and write access and know it's going to remain that way, just write an old-fashioned plain-old-data struct. It's not "prettier" to have to write my_object.GetXXX() instead of my_object.XXX and for setters it's actually annoying if you like to do chain assignments or swaps. Qt is guilty of that a lot: you need to pass through methods to set the values of a vector or a matrix. It's just annoying. Don't do that.


This is kind of why I would like to see properties in C++: you can expose naked properties if you don't need to control reading and writing, and if you change your mind later and need a getter or setter, you can write them without breaking any code. But again, I disgress.

In Topic: My app cannot write files anywhere on Windows 10

07 April 2016 - 09:38 PM

The locations you listed have in common that they're either read-only or in a folder created in NSIS.


Look at the access rights of the folders created by NSIS in your User folder. Is it restricted in reading or writing? There may be an error in your NSIS script that makes it create folders that require admin rights, and therefore your app can't write in them.


Program Files and Program Data should be read-only so even the NSIS created folders should be read-only. (They're the equivalent of /usr on Mac/Linux.)

In Topic: Native Ubuntu apps directly on Windows 10, or just CLIs?

01 April 2016 - 01:56 AM

This is great news. I don't care about the cloud, big data, Azure or all that nonsense, but Bash on Windows? Shut up and show me where to put my signature? :P


As far as I'm concerned, they may as well go all the way and replace the NT kernel with Linux and then port the Win32 API and the Universal Windows Platform. I don't actually dislike Windows, I think it's a great platform and gets blamed way too often when anything goes wrong, it's just that Unix-based platforms tend to get generally better development tools outside of Visual Studio, so if I get to run VS natively on Linux I would be one hell of an happy developer!  :)

In Topic: (split thread) c-style casts

22 March 2016 - 11:09 PM

The point of C++ style casts is to specify your intent, so that the compiler can ensure that you're actually asking it to do what you meant to do. If you use C-style casts the compiler won't help you unless what you're writing is actually illegal code.


The way my C++ teacher taught us over a decade ago:

  • static_cast<T> = "I know that type is naturally convertible to T."
  • reinterpret_cast<T*> = "Yeah, I REALLY meant it."
  • (T) = "Convert and shut the f... up!"

Personally, I don't use C++ casts in my code, but I don't have a strong opinion for or against using them: I just don't use them today, and perhaps I will start using them if it bites me in the face tomorrow. I don't really care.


EDIT: But I think having long and annoying to type keywords like reinterpret_cast<T>(...) hinders the use of C++ casts. I know it's supposed to encourage you to write code that does not need casting in the first place but I wonder if it's really working the way the C++ people saw it. If you could do a static cast by writing something like (static int) and I dunno maybe (mutable int) for a const cast I think there would be less lazy C++ programmers out there.

In Topic: Naming conventions, software documentation and version control

22 March 2016 - 04:32 PM


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... 



I would not use the C++ standard library coding style as the definite coding style for C++. It's not that simple.


Stroustroup, for example, recommends to capitalize the first letter of your class names to distinguish them from the standard library names, which is not what the C++ standard library does. He also recommends using UPPER_CASE for macro names (if you can't avoid them in the first place) to emphasize on the fact that they are alien in C++ and do not respect language's grammar, even though standard macros like assert(...) are in lower.


So no I don't think the C++ standard library standard is meant to be a hint of how you should name your things. (Unlike Java which tries to impose the JFC naming on your own code to the point where Eclipse generates compiler warnings if you don't use the prescribed style!) Boost uses lower_case everywhere because its libraries aspire to be part of the C++ standard library so it's different from your game engine.


But by all means, if you like the all_in_lower_case style go ahead and use it! My point is just that the C++ standard library coding style is not necessarily meant to be imported in your code, the way the JFC coding style is meant to be used by all Java programmers.