• Content count

  • Joined

  • Last visited

Community Reputation

180 Neutral

About aclysma

  • Rank
  1. Do you want to make a game or learn how to program? Do you know any languages yet? If you don't even know what language/technology you want to leverage, you might want to use something that less programming-oriented. In any case, it would let you do some prototyping so you can figure out if your idea is fun or not.
  2. [quote name='darkhaven3' timestamp='1355935655' post='5012486'] After being a C++ programmer for a little while and dabbling with Java, I have to say that in my opinion object-oriented programming is relatively worthless to me. I honestly don't see why I should ever bother worrying about whether or not a particular set of functions can "see" each other, or whether or not I can make two functions with the same name. Why would I ever want more code obfuscation like that -- two functions with identical names that can do two completely different operations? Why on earth would I ever want such a thing? But this is of course only my opinion. I'm not unique in the way I think, surely, but I'm also probably not at all a rare, dying species of programmer. [/quote] Most of the projects I've worked on professionally did NOT do much in the way of data hiding. 99% of the member variables in a class were public. It was annoying at times.. every time you reached in to set a value you had to be careful that you wouldn't cause side effects, but ultimately those projects shipped. Unrealscript is an example of an everything-is-public OO implementation. Data hiding is a good idea. But can you ship without doing it? Yes, definitely. It raises the requirement of others not screwing up when working with your code though. In the case of unrealscript, they made the explicit choice to not hide data for performance reasons of calling a getter/setter (in C++ it's essentially no extra cost due to inlining, but in script.. there was definitely cost.) But that decision was not without other consequence in the form of maintenance hassle.
  3. I have no statistics so I'll make unsubstantiated sweeping generalizations instead [img][/img] Most places outside of games DEFINITELY do OOP, whether or not they understand why they are using it and its advantages and disadvantages. Most game studios/engines I'm aware of also do OOP. I've seen a very small shift away from OOP in favor of thinking in terms of data transformations. In my opinion OOP is very often a good choice. But unfortunately it seems like this is the way *everyone* learns how to program and don't understand the pros/cons of that style. "This is the way thou shalt make software." You benefit from OOP by easy data hiding/encapsulation, and if we mean OOP as in common language features, ability to use polymorphic functions and type safety/inheritance. It's also a well-understood style by the person coming behind you. A bad side of OOP is that few people succeed in only having a single concern per each object type and so what often happens is you get large classes that throw a bunch of unrelated functionality together with its data, and it makes it very difficult to extract a single aspect of the class out for reuse. You end up creating generalized objects that are more complex than necessary to solve a problem. OOP is also a trap for people to make code that attempts to model the real world (i.e. your objects are "chair" or "car" when maybe the better solution would be SitableComponent or DrivableComponent that's attached to something more general). It's difficult to have the discipline to break down a seemingly simple object into the various concerns it has, but failing to do so makes bad OOP designs. One alternative might be a data transformations style, where you have lots of homogeneous data and you simply rip through it all using loose functions. Even with such a style, you can think in terms of OOP and limit how/when/where you access data in those lists. And yet you can keep data and logic separated. In other words, you can get the advantages of OOP without using the class keyword. I think OOP is so prevalent because it's almost always a decent solution and it's very intuitive. So for big companies that just want to grow a workforce of moderately skilled people who can make standard business software without needing to have the depth of understanding to choose what style to use, OOP is a good choice. I think the most important thing is realize that you can get the benefits of OOP without using the class keyword, while skirting the negative aspects of it by either being careful to keep your objects single-minded or thinking in a more raw form of data transformations in sequence. Consider many solutions/styles and *think* about the tradeoffs you make with your choice.
  4. std::Queue and multithreading

    The easy solution is to use a lock or someone else's thread safe queue as has already been suggested. If you're just trying to solve a problem, this is definitely the way to go. If you're interested in really digging into concurrent programming for the purpose of learning, you may want to investigate writing your own lockless queue where exactly one thread can write and exactly one thread can read. It doesn't require a ton of code to do something simple and it's well worth the learning experience. The need to pass data continuously from thread A to thread B in this way is extremely common. An easy implementation is to have a "read pointer" and a "write pointer" that wraps in a circular buffer - just be careful of order of operations and make the read pointer and write pointer volatile. The "pointer" can be an index into the static-sized circular buffer. Using a queue like this is great for passing data to be processed. It can also proxy a function call to another thread by using the "command" pattern. You can even pass exceptions this way.
  5. I'm thinking #1 won't work for me as I don't think static members in the template would be shared across DLLs. I was hoping I wouldn't have to do something like #2 but looks like there aren't better options. Thanks for the suggestions.
  6. There's two ways I read your post. Here's my opinion on your question approached from both angles, and it's worth exactly what you paid for it. "Cosmetic" Style: I wrap all my enums with a namespace and typedef it kind of like what you did with a class. I tend to name like this: ClassNames, _param_vars, and local_vars. You won't see any of that in STL, but it's all opinion. Unlike C# or java, c++ doesn't have "accepted standards." If you look at a bunch of different c++ libraries, they all approach the nuts and bolts of the code differently. In some ways is unfortunate to not have consistency, but on the other hand, different people have different opinions. There is absolutely nothing built-in to the language to force you to go in a particular direction. I'd look at the API for stl and see how they do their naming, but I personally don't care for it and prefer my own "standard" I've settled on over my time with C++. The only thing I'd suggest is that you consider namespaces rather than classes to wrap your constants because it seems like a more natural fit to me. Not that it will really matter after the compiler gets done with your code. Do what feels comfortable. "Functional" Style: Java/C# treat memory completely differently from C++. They are meant to be more restrictive than C++ (i.e. you can't just dereference whatever memory you want at will.) There's plenty of good/bad aspects to this. But this abbreviated conclusion is that the optimal design in Java/C# that embraces OOP may not be the optimal design in C++. I'd say in general if you want to do something "like Java/C#" you can, but in C++ you may be able to work in a different paradigm more suited to your problem. In particular if you're creating a library you'll want to be careful about how memory gets passed around. This can bite you, especially if you want to distribute it as a DLL. While Java/C# will make sure everything magically works, in C++ you need to be aware of what you're actually asking the computer to do (i.e. if you allocate memory in one DLL and free it in another, will it try to return that memory to the same heap?). If you want your design to succeed, carefully consider the problem AND the environment you're trying to solve it in!
  7. I have the following code: [code]template <class T> class __declspec(dllexport) MyTemplate1 { }; template <class T> class MyTemplate2 { }; template MyTemplate1<int>; template __declspec(dllexport) MyTemplate2<int>;[/code] In dependency walker, I can see that this exports the symbol "??4?MyTemplate1..." There is no export for MyTemplate2. In my case, I have multiple projects that can be built as a single monolithic .exe or into a small .exe with a collection of DLLs. I want multiple projects to be able to export different instantiations of the template. I have no need to "hide" the templates implementation code from downstream projects. I cannot use the syntax in MyTemplate1 because each project has its own define for __declspec(...) (i.e. RENDERER_API, FRAMEWORK_API, etc.). If I used the syntax of MyTemplate1, only one of the DLLs could ever export the template. I was really hoping the syntax I am using in MyTemplate2 would work, but this sample demonstrates that it does not. I understand that DLLs and templates do not play well together. I also understand that __declspec(...) needs to be a define, and that downstream projects will need to extern the template instantiation. In my actual project, I have done this. What I'm asking specifically is this: Is there a way to write MyTemplate2 such that it is declared once but can have different instantiations exported by different DLLs? Thanks in advance!
  8. Thank you both for your help! In particular, the explanation of *why* ClassA and ClassB don't implement InterfaceA::fn() or InterfaceB::fn(). I haven't finished what I'm working on, but I fully expect that making a "shared" interface is the right answer.
  9. Thanks for your suggestion alvaro. I think I stripped down my sample source too much, so here's a version that's a bit closer to what I'm actually doing: [code] struct InterfaceA { virtual void fn() = 0; virtual void fnA() = 0; }; struct InterfaceB { virtual void fn() = 0; virtual void fnB() = 0; }; class BaseClass { public: void fn() { } }; class ClassA : public BaseClass, public InterfaceA { void fnA() { } }; class ClassB : public BaseClass, public InterfaceB { void fnB() { } }; [/code] While your suggestion certainly works well for my original post, it does not work for this case. The above code will complain that ClassA and ClassB do not have an implementation for fn(). If I make the base class extend both interfaces, ClassA will complain about missing fnB() and ClassB will complain about missing fnA(). Using your idea, I did come up with this. While it's a bit weird, it does remove the need for the proxy functions, and it gives compile-time errors because the dummy functions in BaseClass are private. [code]struct InterfaceA { virtual void fn() = 0; virtual void fnA() = 0; }; struct InterfaceB { virtual void fn() = 0; virtual void fnB() = 0; }; class BaseClass : public InterfaceA, public InterfaceB { public: void fn() { } private: // Dummy methods that should always be extended.. we get compile errors // if we try to call them because they are private void fnA() { assert(0); } void fnB() { assert(0); } }; class ClassA : public BaseClass { public: void fnA() { } }; class ClassB : public BaseClass { public: void fnB() { } }; [/code] Far from elegant, and I'm not really sure that it's better than having proxy functions. I am still interested in: - Solutions that are not a hack like this one that uses visibility - An explanation as to why a compiler couldn't or shouldn't do what I expected with the very original code sample
  10. I'm writing a library that is exposed as a DLL, so I am using the standard pImpl method with exposed factory functions to create the Impl objects. I'd like for some of the common "Impl" functionality to be in a base class, and have those implementation satisfy the exposed interface. So, I have some code that's like this: [code]struct InterfaceA { virtual void fn() = 0; }; class ClassA { public: void fn() { } }; class ClassB : public ClassA, public InterfaceA { }; [/code] I expected that this would work, however, I get the following: [code]1>****(38) : error C2259: 'ClassB' : cannot instantiate abstract class 1> due to following members: 1> 'void InterfaceA::fn(void)' : is abstract 1> ****(19) : see declaration of 'InterfaceA::fn' [/code] I know that I could include something in class B like [code]void fn() { ClassA::fn(); }[/code] but at that point I might as well just use composition rather than inheritance. While in general I'm a huge fan of composition, I wanted to use inheritance so that the "ClassB" classes have only the unique code in them (would make the code pleasant to read.) Is there a way to make ClassB automatically use the method in ClassA to satisfy InterfaceA? My question is exactly the same as [url=""]http://stackoverflow...-abstract-inter[/url], but I didn't see a real "solution" to my question of not having to add a proxy function. Also, if there is a good reason why this is not possible for a compiler to figure out, or why you wouldn't want this behavior, I'd love to know.
  11. 1) You don't need a big int class to solve the linked problem. There is a much, much easier way to do it. (Apologies if you already know that.) 2) To answer your more direct question, I would implement a software ALU. While I have not done it myself, you could consider keeping an array of 64-bit numbers. You'll have to do the carrying manually (i.e. add the low order pair of 64-bit numbers together.. if you detect an overflow manually add 1 to the next higher order 64-bit numbers. It may help to look up some very basic computer engineering stuff to see how an ALU works so that you can imitate it.. you'd use the hardware though to do 64 bits at a time.. certainly not bit-by-bit :) Detecting the overflow is easy.. C = A + B. If C < A, you overflowed. Addition is the easy operation though. I'd suggest taking a look at how Melekor's linked code works. 3) Wikipedia has a page specifically about how to find square roots, but using Newton's Method is just dead simple. Your equation would be 0 = x^2 - Y where x is your answer and Y is the number you're taking the square root of. I'm sure an algorithm at is much faster though (particularly the one using digit by digit work on binary numbers.) BTW, don't try to think in base 10. Think in base 2 or 16. A + 9 = 14. That's an overflow to the next digit (the 1) and you have 4 left for the ones column. The next column is the 16s column, the next is the 256s column, etc. F00 is 15*16*16 + 0*16 + 0*1 = 3840
  12. [C++] RTTI Issues

    Quote:Original post by Hodgman From what I remember, type_info's name function will return different strings depending on the compiler that was used, *but* it's == operator always works. Quote:I understand that if I use typeid(T) on two different types that live in different DLLs, I can get matching type_info pointers when the types are not the same. Even if this is true (which I don't think it is), you shouldn't be comparing the pointer values anyway! You should be comparing the actual type_info objects themselves (using their overloaded == operator). Good point on the ==s. I need to go double-check that that's how I'm testing for equality. I decided to go back and re-read what I had found that led me to my conclusion about type_info non-uniqueness across DLLs: The comment by dmail at the end concerns me. The page he linked makes it seem that boost python developers decided that string comparisons of the name are safer than the == comparison on GCC and a couple other platforms (not MSVC though). I am wondering if I'm going to have to adopt a similar strategy, and that's what got me to thinking there might be some other nasty traps I don't know about. But of course, if this is not true, (which would explain why SiCrane made no mention of it in that post, and why I could not find any additional information about this) then I would be very pleased. :) Thanks!
  13. [C++] RTTI Issues

    I am not interested in turning this into a performance/pros/cons thread, as I said first thing. For clarity, by DLL I mean whatever dynamic linking mechanism that happens to be on the target OS. I would like to support msvc, gcc, and try to be standard enough that any other modern compiler should be expected to work fine. From my understanding, .so files on linux have the same sorts of issues. And btw, I'm sure almost any implementation of dynamic linking is going to have some quirks, simply because the dynamically linked code at compile time has no way to guarantee uniqueness between modules. What I'm looking for here is to find out about as many gotchas up front as possible, and to confirm that what I *think* is right, is correct, before I get too invested into my own ignorance. :)
  14. [C++] Dll Issue

    I have never messed much with DLLs but it sounds like something is out of sync - have you tried doing a full rebuild? If you swap the two functions like that of identical prototypes, it would not surprise me if now the functions had swapped memory addresses.
  15. Speed up Compile Times

    Not to derail but.. /MP cannot be used at the same time as /Gm (enable incremental build). In which cases is one better than the other? As for release mode, Gm was already turned off for me, but I don't notice a difference in debug mode.. I post numbers when I try them both. EDIT: Dropped my 3.5 min compile time to 2.5 min - so MP is an improvement but still not sure if it is faster than incremental builds). [Edited by - aclysma on May 15, 2008 1:51:21 PM]