MadKeithV

Moderators
  • Content count

    3331
  • Joined

  • Last visited

Community Reputation

992 Good

About MadKeithV

  • Rank
    Moderator

Personal Information

  • Interests
    Art
    Audio
    Business
    Design
    DevOps
    Programming

Recent Profile Visitors

5141 profile views
  1. Coding-Style Poll

    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: 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. 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. 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".
  2. Ear Damage

    Quote: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?
  3. Quote: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?
  4. Quote: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.
  5. Quote:Original post by nlbs Quote: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. Quote:Original post by nlbs Quote: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.
  6. C++/STL - Slow? SOLVED

    Quote:Original post by dae_coderonin My question here is this: Are stl vectors really that slow, is it just the Debug setting (I'm working with MS VS2003) You should NEVER base ANY performance judgements on the debug build of a project. There are many, many things that could be going on behind the scenes in a debug build that slow things down, such as checked allocations and iterations, additional logging, and also some optimizations that more advanced classes may rely on will not happen in debug. I have some code around that takes a minute to complete in Release mode, and four hours in Debug. Try it in Release mode first and if you still have a problem it's worth looking into.
  7. Populating an array - in c

    Also, your iteration overruns the array bounds - the last valid array index is 9, not 10. i <= MAXSIZE should be i < MAXSIZE.
  8. Quote:Original post by Hodgman Thanks for the reg-ex advice. I'm still torn as to which approach to take. The reg-ex isn't a simple win because the old/existing code still needs to be maintained as well. In other words, if I do a find replace then I will end up with two copies of that code to maintain. It's not 100% clear to me why the change causes a branch. Do you mean that the same API is used for other code besides the code you are refactoring, or for code you cannot touch (or cannot rely on being available at certain client sites)? Are there already multiple branches of this code? Or are you afraid that you will affect the stability of the code with your refactoring? [Edited by - MadKeithV on October 24, 2008 5:05:49 AM]
  9. To me this seems a lot more like a job for a regexp find-and-replace in the user code. Introducing that adapter might make your job easier, but I pity the person that has to do the next bit of maintenance (and consider that the next person may be you!). Just try a regexp find-and-replace in the old API code - the convoluted syntax of the old calls make me think it would be highly unlikely to get any false hits.
  10. C++ testing frameworks

    Quote:Original post by jpetrie I've been using UnitTest++ recently. I'm a UnitTest++ -user too. At my company we evaluated a number of unit test suites and this one had the best combination of features and ease-of-use at that time. Some niggles: the lack of unicode support, as well as the difficulty in selecting specific tests to run. I also liked CxxTest which uses Python (or Perl) to pre-process the test files. Easy-to-use, but with a lot of setup requirements that made it less suitable to the development environment here.
  11. STL std::vector problems

    Quote:Original post by Modena360 I've played around with including the #define _HAS_ITERATOR_DEBUGGING 0 #define _SECURE_SCL 0 lines and when enabled these actually make it crash earlier, on the first std::vector it encounters. My best guess would be that it's still one of these definitions (probably _SECURE_SCL). How complex is your project? If you are linking multiple libs or DLLs and one of them is compiled with a different definition of any of these from the others you'll get issues like this.
  12. What is the best 2D art program?

    GIMP on Win32 did not support Wacom tablets' pressure sensitivity last time I tried it. Without it the GIMP is not a serious contender for a 2D art package.
  13. I didn't mean to imply that the SM57 or SM58 were condensers. I was trying to give an example of preferring the dynamic SM58 to an LDC in particular circumstances. A dynamic microphone can sometimes (often) be a good choice and condenser mics aren't "better" by default. But one of the prerequisites is that you already have a nice mic preamp. Also note that phantom power is not the same as a mic pre, you can have one without the other. Several cheap mixing desks of old did not have phantom power for their channel preamps, and I have a separate phantom power box somewhere in a pile of old stuff too. However, I've been browsing around and it seems to be the Samson USB mic should work fine (C01u?). Kylotan - did you install "SoftPre" (http://www.samsontech.com/main/misc.cfm?pageID=45) to get the additional driver support? The FAQ mentions using the MME32 driver for it.
  14. LDCs *are* usually more desirable for vocals because of the extended upper range and the bass roll-off. SDCs are better for recording bass. Both are still very much multi-purpose and much depends on the vocalist's sound and the sonic quality of the mic preamp. I use an SM-58 dynamic for my own vocals even though I have a Haipheng Neuman TLM193 rip-off. Important to consider is that you'll need a mixer or mic pre with phantom power to be able to use a condenser microphone. If you're going to spend any serious amount of money, spend it on a good mic pre first - get the cheapest condenser mic you can find. A good pre can make even a cheap mic sing (like the SM58 and 57), and a bad pre will sound bad with even the best mics. Suggestions: Get the Samson or Behringer LDC to save some money, and then try to find the best mic pre you can afford. Secondhand is good - I got my TL Audio PA-1 that way - plenty of stuff on the market. Alternatively, try the sE Electronics USB2200A. Also a USB microphone, but targeted more to pro audio rather than podcast audiences.
  15. Quick guess: you could try creating templates with an integer non-type parameter, specializing them for each valid case, and giving a compile-time error in the default case.