• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

248 Neutral

About Valere

  • Rank

Personal Information

  • Interests
  1. Have you looked into ICU? It's pretty much the gold standard for working with Unicode in C, C++ and Java. YConsider using its UnicodeString as your internal format, and use its conversion functions at the platform boundry. http://site.icu-project.org/
  2. [C++] Coding Styles

    As many have said: as long the code you or your team write is consistent, you're good. Many (if not most) people who are used to C++ are used to the variety of code conventions popular and built in libraries use. 1.) Person 2.) m_Member 3.) DoSomething() 4.) If I am using a struct as a pure data holder, with all public members and no functions: Struct::member 5.) DoSomething() 6.) g_ or s_ 7.) enum ENUM{ ENUMERATED }, const T CONSTANT;
  3. The bike shed should definitely be blue :) The goal is to write code that you can easily read. If you have a team, then amend that to "you and your team." If prefixes help, use them. But mostly, be consistent. I use the Allman style, with systems hungarian prefixes at work ( Coding Standards ), and without prefixes at home, because I find non-prefixed code easier to read.
  4. A statement My professor made

    Do you learn more about data structures by building them, or by using them? Do learn more about more general ideas of computer science by building data structures, or by using them?
  5. Quote:Original post by cache_hit For what it's worth, this is one of the many things about Java that make me hate with a passion reserved for few things in life. How simple is it in practically every other language in the world to write a function that returns multiple values? For example, suppose you have some item cache and for speed you want to write a TryGet function that if successful returns true as well as the item, and if failed simply returns false? Simple in every language in the world except Java. In Java you have to do something crazy like create a new class just for the return value, like: *** Source Snippet Removed *** You aren't the only one. In University, my compilers prof's idea of a joke was to get us to generate a partial grammar for Java. Then we generated one for LISP. We were only graded on the second :). If you find yourself having to work in Java, ever again, Someone wrote a tuple library. I suspect it was because they got tired of having to work around Java's limitations.
  6. constrain sprite to path

    So, each line segment has 1 to n legal exit segments, and each path has a radius of free movement? Would something like this work? 1) Assign sprite to a starting segment 2) When the sprite moves, check to see if it's movement takes it more than the radius from the path (find closest point on the current line segment, check if distance > than threshold). ---If in radius, do nothing ---If out of radius: ------a) Check if the sprite is a legal distance from all legal exit segments, if so, assign the sprite to the segment it is closest to. ------b) Otherwise, reverse the sprite's last movement until it is just inside the threshold of the current path
  7. When you took your data structures course you learned the algorithmic complexity (both in time and space for each algorithm), as well as the details of each Abstract Data Type, right? When you need to solve a problem, first pick the structure with the most convenient ADT. Then, if performance becomes an issue, pick the data structure with the complexity characteristics that best suit the problem at hand. To get a feel for this, pull out your algorithms text, and flip to your favorite chapter. A good text on this will discuss how the data needs to be stored to support the algorithm. If you haven't taken algorithms yet, relax, these details will be made very clear there :). In most pragmatic programming you will deal with ordered sequences, queues, and lookup tables (implementation varies) more often than anything else. You're either processing lists of things, or looking things up. Traversing trees is not uncommon, but it's still rare compared to these tasks. As mentioned earlier, game programming and simulations programming tends to be where the fancy data structures come out and play. In these cases, real time processing is crucial, and data structures and algorithms that minimize complexity are needed.
  8. Inheritance vs Composition

    Adding an engine to every car is desirable if you have more than one kind of engine, or say suspension. Otherwise you start getting strange inheritance hierarchies like Vehicle -> PoweredVehicle -> Car -> CarWithV12AndCustomSuspension -> Diablo Vehicle -> PoweredVehicle -> Car -> CarWithCustomBuiltFluxCapacitorAndCustomSuspension -> Delorian Vehicle -> PoweredVehicle -> Car -> CarWithFourCylinderAndCheapSuspension -> Civic With composition, you can stop at car. Creating different cars is just a matter of writing factory methods (Omitting smart pointers for brevity): Car* CreateCivic() { return new Car( new FourCylinderEngine(), new CheapSuspension() ); };
  9. [C++] ANSI/Unicode transition

    ICU (mentioned above) is not quite bulletproof and has a hefty (but well designed) api, but it has the advantage of doing what you expect. If you are doing any sort of internationalization in C++, and aren't using a ui toolkit with proper Unicode support. Qt has a good enough solution in the QtGui library with the QString class + TR macro + support, should you be doing any standard application UI work. The holes in the Win32 Unicode support are small, but when they are important, they tend to be really important (like the ability to handle capitalization in non Latin alphabets). Bitter experience has taught me to convert to windows Unicode at the last possible moment.
  10. The Humble Dialog/Passive View goes along way to making it possible to mock out user interaction. I don't work with anything more complex than an sqlite database, but I do use mock replacements to simulate as many reasonable failures as I can, to make sure that my code responds in a sane manner. I can't see how Big problems (like configuration problems with your live database) can't really be corrected for in unit tests. Quote:It can take hours to setup the tests to use a database and the tests are slow. If all your code does is communicate with external system, it can be real pain in the ass to test it. I don't think you are the only one in this position. Most software written these days is database/CRUD work. I find there's a fair bit of literature on how to structure your code to make it easy to switch the databases that I tend to skim past because it doesn't apply to me. Have you skimmed through Google's Test Automation Blog and papers? Edit: I really found the massive tome xUnit Patterns helpful when I decided to commit to unit testing. I like the before and after approach, and the huge number of example tests it has. I'm not sure I buy the technique wholesale, but it was useful to bridge the "Oh, that's what a good test looks like" gap. [Edited by - Valere on January 26, 2010 5:14:00 PM]
  11. I am a C++ developer, on a medium large system, with over 10 years of legacy code. I've found that: 1) The better tests I have, the more confident I can be about the code covered by those tests. 2) I can fix bugs and iterate faster on tested code because I can cleanly separate it from the production environment. It's proved to me that most bugs really are in the new code I just wrote, not the code I depend on. Where code I depend is at fault, it's usually because I made incorrect assumptions about its model. 3) Tested code tends to have clean entry and exits. It also tends to have a lot of similarities to functional code (few side effects). 4) Writing tested code takes more time at first. But I feel (I don't have objective proof of this) that the time to get code ready for production is shorter as a result. 5) Many developers don't want to write automated tests. It is a very different mode of working ( get the "algorithm right", vs "just get it done" ). Those developers that do want to write tests often want to write component tests, not unit tests. The connection between getting the whole system to work and the kind of thing you write tests around is not immediately clear. 6) I don't write tests around everything. I don't always write tests first. The style is a tool in the toolbox, especially when working with legacy code. I use it much more often when developing new systems, or when I need to pull legacy code into new systems. There's a lot of work that can only be made testable by refactoring huge amounts of existing code. I don't believe it reduces the number of defects that I write, but it does make it faster to find them, and fix them. Your tests are only as good as you write them, so there are regressions that happen that tests do not detect. Since I typically write tests to fix bugs, when I'm done, that regression is covered. Overtesting is definitely possible. I generally try to only test the desirable features (and ensure particilarly undesirable things can't happen), rather than characterize the quirks of the implementation.
  12. Scheme and Common Lisp

    I really liked emacs (well, Aquamacs) + Scheme + working through SICP for wrapping my head around functional programming. It all ties together very nicely, but it doesn't really provide a visual studio "project" view without a fair number of emacs addons. Even then, it's clunky, so probably not worth it. There's nothing wrong with learning Common LISP and Scheme at the same time. They are both LISPs and the tricky part for me with functional languages wasn't libraries. It was the organization of my code (and thoughts) in a functional manner. Common LISP is a little too practical for my taste as far as exploratory programming goes. It felt a bit like learning C++ to get a handle on Object Oriented programming. But learning in scheme and applying in CLISP seems like a good approach to me. HINT: A list comprehension will provide a much cleaner way of permuting three lists. A lot of functional programming is stepping back from "How do I get there" and stating "What does the result look like".
  13. You can dereference boost::shared_ptr like a regular pointer which would allow you to write: (*costs)[i][j]
  14. Sorry, I wasn't clear. We don't compile with /Za, but code that we write avoids the extensions except where you can't use the win32 API without them. Things like the >> to terminate nested template definitions wouldn't be allowed, for example.
  15. Quote:Original post by cache_hit Quote:Original post by phresnel Quote:Original post by Zao Visual Studio accepts >> with language extensions enabled (which shouldn't be turned off anyway). Why not? For one thing, even including windows.h isn't supported with language extensions disabled. Secondly, the compiler devs are quoted as saying that disabling language extensions opens you up for all kinds of crazy compiler bugs that don't surface otherwise. Still, can doesn't mean should. :) After a particularly painful port from Win to Mac made harder by language extension use, we added "ensure new code doesn't use VS language extensions" to our code review process.
  • Advertisement