Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 18 Feb 2000
Offline Last Active Oct 05 2016 02:04 AM

Posts I've Made

In Topic: Coding-Style Poll

28 September 2016 - 03:13 AM

Over the years I've become a lot more tolerant of different coding styles, I've changed my own style several times, and I've been involved in defining code styles a number of times.

Currently, the client I'm working for has automatic code formatting inside the IDE for every save (something based on CLang-format), which I find really nice because there are no more discussions on style, it just happens.


In the past, where there's been contention, the decision process has been quite simple:

  1. Is there a rational argument against the style being introduced?  If I can't come up with a convincing one very quickly, then I dismiss my own reservations and just adhere to the new style.
  2. Is the change important enough to warrant me spending additional time building up a data-supported argument?  Often when balancing the cost of me doing so against the aggravation of having to follow the new style, the new style still wins out.
  3. So there's a rational argument and I care about it enough to dig deeper: I write down the argument in technical terms, with supporting data where possible.  I present this argument to the team responsible for the coding style.  They make the decision, and I abide by it.

It is often a case of "pick your battles" - do you really want to waste time and energy arguing code style, or are there more important things to do?


Finally, in my 20-odd years as a developer (damn, I'm getting old) I don't recall any truly insane styles in any project or place of work.  If a bunch of rational developers work out a decent coding style, I think everyone should be able to "get on with it".

In Topic: Ear Damage

02 September 2009 - 12:35 AM

Original post by kal_jez
Just as an aside I read some papers suggesting that compressed audio like mp3 can actually be more damaging to hearing as the sound can peak higher than perceived in certain frequencies due to the compression process.

File size compression (as in the mp3 format) is something completely different from dynamic range compression (as done with a compressor unit). Which one are you talking about?

In Topic: "Object Only" Languages and Free Functions

01 December 2008 - 10:08 PM

Original post by Ravyne
Ah, but I didn't say that C++ was inferior across the board. What I said specifically was that C++'s implimentation of certain OOP and OOP-like features are in many cases generally inferior to those same features as implemented in a "pure" OOP language. Yes, this implies that OOP features are best implemented by pure OOP languages, but that stands to reason, doesn't it?

Cool - this is an interesting topic. I am not sure I agree that C++ is even inferior in the area of OOP, but I would really like to discuss it. What areas of OOP do you feel are done better by specific, pure OOP languages?

The first big question is how do you define OOP? Is the core of OOP polymorphism? Is it encapsulation of functionality? Is it both and more? (All of the above! ;-) )

Some potential arguments that C++ might be inferior to pure OOP languages:
- C++ doesn't have a true "interface" concept. You can of course create a class with no members and only pure virtual functions, or you can go halfway and have some pure virtual functions, some not pure, some implementation and some members, and get the best of all worlds! </devils_advocate>. Is there any specific circumstance where you truly need a pure interface?
- C++ doesn't have a base CObject class from which everything is derived. Well, you could do this in your own frameworks and programs, and personally I don't really see the value in it.
- C++ encapsulation is easily broken. This one is absolutely true. A bit of const-casting, some pointer trickery, there are a lot of ways to get access to internals in C++. You don't have to hack your way around it, but the fact that it's possible does weaken certain concepts and it can lead to "broken" frameworks where hacks have destroyed the intended design.

Any more ideas?

In Topic: "Object Only" Languages and Free Functions

30 November 2008 - 11:08 PM

Original post by Ravyne
The thing is that C++ is not an OOP language. C++ is a multi-paradigm language which supports some OOP or OOP-like features in ways which are generally inferior to the ways in which they are implemented in first-class OOP languages.

You have to be careful with value-statements like this - calling C++ "inferior" to what you consider first-class OOP languages. OOP is not a silver bullet, and "pure OOP" only limits language expressiveness for no good reason. What would you consider a first-class OOP language? Java and C# "pepper classes with static methods because you don't have free functions"? I'd hope not.

You know what they say - if all you have is a hammer, everything looks like a nail.

In Topic: Is it bad style of coding ??

06 November 2008 - 04:41 AM

Original post by nlbs
Why the need to store pointers for basic types like int, floats, etc?
Thats by applications requirments

It seems highly unlikely that this is exactly what your requirements specify. Are you trying to create a container for an "any" type? In other words, a heterogeneous container that can contain any kind of element, through storing void pointers?
If so, take a look at boost::any to wrap around objects you want to store.

Original post by nlbs
I would at least remove the += operator that takes a reference, since you are actually storing the pointer.

I've already said that one of my target is syntactic ease.
so can you fulfill the application requirments without using const X& or X& arguments on += operator overload.

As several posters have said before me, (ab)using operator+= for adding things to a container class is not "syntactic ease". There are various accepted ways of adding something to a vector, list or other container, such as push_back or insert. The C++ standard library defines those quite clearly and the concepts will be known to most of your users. Doing something else is going to accomplish nothing, besides confusing your users.
The only halfway good reason I can see to use operator overloading is for chaining (ex = a + b + c;// -> ex contains a, b, c) , and in that case you will need to implement operator+ too.

I'll remark that your users might now expect that operator= will act as follows:

Example ex;
ex += 1;
ex += 2; // ex now contains 1, 2
ex = 3; // ex now contains only 3

After all, that's not an illogical conclusion from the way that you defined operator+= (and probably operator+).

You should follow the advice of the other posters in this thread:
1. Define whether your container will have ownership of the objects contained, or not. And stick to it.
2. Stop using operator+= for adding elements. It really is going to cause more trouble than it's worth.
3. Carefully review your requirements and check if boost::any might solve them.