doynax

Members
  • Content count

    1555
  • Joined

  • Last visited

Community Reputation

850 Good

About doynax

  • Rank
    Contributor
  1. Common notation

    Quote:Sorry, but no, it is a matter of absolutes. You can get familiar with another naming convention, so that removes the validity of that argument. There's no reason to advocate a defective naming convention just because you personally are too lazy to spend the time necessary to get used to another naming convention.That's like arguing that hungarian notation is as good as any other naming convention because you can become familiar with it. Quote:Wrong. Ever look at STL implementation headers? Most of the implementation specifics use the reserved underscore identifiers for their internals because thats what they are there for. It's actually becoming more important that you avoid these identifiers unless you want bizarre Koenig lookup problems in code that uses the standard library. If you want to try something fun, name a class _Ty, pass it to some MSVC 6 template classes and watch the compiler crash in a mass of internal compiler errors. (Admittedly this isn't much of an accomplishment since MSVC 6 will internal compiler error if you look at it funny.) Even with MSVC 7 a good using declaration in the right (wrong) place will send the compiler into C1001 land.I've looked at VC's STL implementation once or twice, and I'm not doing it again voluntarily.. You're right and that's a good technical example. Why didn't you say so to begin with? ;) Is this likely to cause anything beyond compiler crashes? In most cases I guess these would be shielded within the std namespace or overloaded when inheriting from a template class. I guess I was thinking mostly about various special declarations that the truly magical things rather than "normal" implementation details, perhaps not that surprising given that I spent several hours yesterday translating utility __declspecs to GCC.. Quote:Unless you're using a completely brain dead compiler, the preprocessor has the ability to emit a list of all symbols that were defined. Ask the preprocessor nicely, and it will give you that list. No random voodoo necessary.I primarily use VC6 and I can't find a way to get a direct list of defined symbols from it, so I guess it's what you'd call a brain dead compiler. Anyway you can always invoke it separately and look at the output for much the same effect (I tend to use it to debug complex macro hacks, boost pp-ish things). But changing the compiler settings and finding the appropriate output file or dropping out to the command line and hope you've got the right environment macros defined takes me a lot of time. Redefining or renaming the symbol and recompiling takes almost none, especially since I most often use it just to be able to eliminate that class of bugs. Quote:Quote:First of all I would never try to promote my own coding style, at least not unless explicitly asked.Isn't that what you're doing? Let me refresh your memory about how you entered this thread:Quote:Oh, come on. Stop nitpicking on this issue already. I realize that it may be good to know that they're technically reserved, in fact I like trivia and obscure language details as much as the next guy, but do we really have to comment on it every single time someone shows a code snippet containing a leading underscore in one of the identifiers? I mean if someone uses "foo" then no one complains but apparently "_foo" is some kind of sin, now which one do you think is more likely to cause problems? I personally use them all over the place to mark internal things (i.e. private or local), mostly because I find trailing underscores quite ugly. In fact the consistent use of underscores to separate all of those short local names combined with the use of module prefixes and namespace has significantly reduced the number of collisions I've had to deal with during the last few years. Isn't that promoting your own defective programming style? And every post you make trying to justify this reprehensible practice acts as further promotion.I'd say calling that promoting my programming style is quite a stretch. The whole point of that quote is obviously to put things into perspective. I say that while _foo is technically bad, there are much worse things out there. I guess you could also interpret it as promoting a style with leading underscores and prefixes compared to not using anything at all, which is hardly a controversial statement. Most of all I'm trying to tell those who may be about to abandon the style because it's "evil" that they may not have heard the whole story, and that the supposed problems seem to have been exaggerated. Look deeper into the advantages and disavantages and judge for yourself. Quote:And I'm saying that when you do have that problem (not if, but when) it most likely will be bizarre annoying problem that will take a disproportionately large amount of time to solve that you could have avoided if you hadn't used a defective naming standard in the first place.I doubt it. The wast majority of these problems result in direct compiler errors which are generally quite easy to fix by determining if or with what it's colliding. When I get a weird compiler error I usually proceed by splitting the code into as tiny pieces as possible, and when all I'm left with is an identifier then I'd almost certainly suspect a collision. A bizarre and annoying problem would rather be something silent, consider something truly nasty like inadvertantly changing the alignment of a variable. I've also almost certainly spent more time writing these posts then I ever will solving bugs caused by leading underscores. Quote:If a beginner is not qualified to make that decision, why did you bother posting in a thread in the For Beginners forum in the first place? Why continue to defend your ill-conceived naming conventions in this thread?Well, sorry.. That was an honest mistake, I tend to watch active topics directly so it's easy to miss which forum the thread is in. Anyway, it seemed better to continue posting here then trying to move this discussion to another thread. To quote myself:Quote:I'll have to admit that I never noticed this was a For Beginners thread, I apologize for that. I suppose I should've waited for a thread in General Programming instead. Quote:Oh, but here you go trying to defend it again.Actually, it was more of an attempt to cool down any hot feelings really.. Quote:No, not really. I haven't seen you advance a single argument with technical merit. Only trying to downplay the problems, which you admit are still there, and trying to advance your own lack of flexibility as some sort of mitigating factor.It's simple, either the style has merits compared to others or it doesn't. Furthermore I'm arguing that it has advantages and that there's more to it than just a lack of flexibility (which isn't a bad argument per-se if applied at a different scale). Length (that is overhead) is easily and objectively quantifyable, so we're basically left with the alternative of using a trailing underscore instead. I read from left to right, I sort from left to right (for identifiers anyway), I compose hierarchies from left to right, I line up code from left to right, etc. It's hardly surprising that I perceive a prefix as more significant than a postfix. At least that's my technical explanation. But more importantly for me personally is that I tried it out and never got as comfortable with it as the prefix-based naming conventions. Quote:Again, I'm not touching C. If you want to be foolish enough to try using the same standard for multiple languages, be my guest.It's really not that stupid. Having a familiar coding convention makes a big difference when you're mixing C and C++ on a project, and except for the identation rules my current convention works quite well in assembly language too (where I otherwise tend to spend half the coding time lining up comments or something equally silly). But I wouldn't try using them in Lisp if that's what you mean.. ;)
  2. Ellipses as arguments

    #include <stdarg.h> void printf_wrapper(const char *format, ...) { va_list args; args = va_start(format); vprintf(format, args); va_end(args); };edit: Too late.. If you're using GCC then you may want to inform the compiler that it's a printf wrapper in order to get type checking. Just declare the function using this macro (suppling the position of the format and ellipse arguments):#ifdef __GNUC__ # define PRINTF_WRAPPER(format, ellipse) __attribute__((format(printf, format, ellipse))) #else # define PRINTF_WRAPPER(format, ellipse) #endif void PRINTF_WRAPPER(1, 2) printf_wrapper(const char *format, ...);
  3. Common notation

    Quote:Original post by GameMasterXL Sorry but personaly i think style is crap it restricts you and people should get out of using code styles and just go with there own thought instead of continuing what other people have done which is going in an inheriting chain from old to new ages and is just boring.I don't think anyone here has claimed that you should religiously follow your style at all costs, or even that you should stick with a single one. However, if nothing else, having a know coding style work with relieves a lot of the thinking behind writing code. You don't have to consider where to put the braces or which words to captialize in an identifier, since that work has already done been for you. edit: Or maybe I misunderstood you completely. Are you saying that we shouldn't feel restricted by what's already out there and try to find the best style for ourselves? If that's the case then I wholeheartedly agree.
  4. Common notation

    Quote:Original post by SiCrane Quote:Original post by doynax I'm not quite sure what you mean when you say that the other coding conventions don't have the same problems. I've used compilers with non-standard reserved keywords before (FAR, pascal, etc), and new keywords may of course be introduced when switching standards (there's lots of examples between C89 and C99 or between C and C++). But in my experience the vast majority of the clashes are with 3rd party libraries. Namespaces. Use them. That limits your name collissions to a great degree. Then most identifier problems come from ill behaved macros, and once you learn to use your preprocessor they become trivial to detect without random changes to identifier names.I do use namespaces when coding in C++, it's just that I write almost as much code in C and a fair bit of assembly too. For instance ony my current probject I wanted to avoid the temptation of the high-level constructs offered in C++ since I eventually plan to translate most of it to assembly language (it's a simply LISP dialect which I intend to use for future GBA projects), additionally it'd be convenient to make all functions callable from assembly language in order to be able to port it incrementally. I don't quite know why I'm defending my use of C here, but I guess it could hurt.. As for macros collisions (and other types of collisions), they are for the most part trivial to detect. Most of the time I get a visual hint by Visual Assist, otherwise the compiler generally generates some weird error message and I try renaming it to see if it's a macro. Other common tricks involve trying to define the identifier yourself to see if the compiler complains or checking the preprocessor's output manually. Once in a great while I even dump the resulting symbols to see if there's something odd going on (i.e. name decoration problems). For instance not too long ago a friend of mine got completely stuck trying to figure out why he couldn't call zlib. The problem was that he was trying to wrap zlib into a namespace in C++, which should've worked if zlib hadn't redefined all it's functions with macros. The problem here is that he had no idea how to proceed to find the bug (and he's not a bad coder, really). So I honestly believe that most C++ programmers use and should know about these kind of "voodoo" practices. Of course there are many other methods to try in order to detect other kinds of problems, but these are primarily useful for collisions. Quote:Original post by SiCrane Quote:There are many mroe of these magical problems in C++ though, the static initialization order is a good example. You don't have to deal with static initialization order problems because your naming conventions are defective.My point was that there are many problems in C++ which are hard to solve without resorting to "unconventional" methods. And it's hard to deny that there's a fair bit of witchcraft involved in debugging. Quote:Original post by SiCrane Quote:Don't forget that one of these subjective advantages is familiarity. Vastly overrated. A competent professional programmer can switch between naming conventions without problem.I agree that this should'nt really be a big problem. It's just one of those tiny yet undeniable ones I dragged up in order to prove that it wasn't a matter of absolutes. Quote:Original post by SiCrane Quote: I'll let you in on another secret of mine. I have huge motivational problems and only write code in bursts as a hobby for my own pleasure. This may sound harsh, but that means you don't program enough to have a valid opinion. You shouldn't allow your limited experience to warp your judgement so much that you advocate a needless practice that has clear issues in real world development.My point here was that importance of writing beatiful code varies. For myself and many probably many other hackers from around here it's vital, but for a professional game development studio it may be more important to avoid potential pitfalls. You may be right. Still, I'd like to think that I'm a fairly experienced programmer, after all I've dedicated half of my life to it. In any event I do believe that I've written more than enough code for various projects and on various compilers to get a rough idea of how frequent these problems are in practice. OTOH I've never done much work professionally or worked in a team with more than 3 members. Of course I haven't used all compilers out there, but the trend nowadays seems to be for compiler writers to wrap their internal names in as many underscores as possible in order to avoid collisions with user code. After all it's not an uncommon naming convention, so I guess compiler writers choose to avoid problems rather than to defend themselves by being technically correct. Quote:Original post by SiCrane Quote: That's not what I'm saying. The problem itself it quite common (perhaps something I run into every few weeks or so). And it happens with most naming conventions (again, Min and Max from Windows.h are good examples). Then learn to use your preprocessor and stop advocating voodoo programming practices like random variable renaming.I do disagree, it's not vodoo programming if you use it as a tool do detect a special set of problems. The main point here is that you still have to find the underlying reason for the issue, not just say "oh, now it seems to work lets just keep the name foobar13." What other method do you suggest for finding problems like these (lets say a coder has inadvertantly implemented a min method somewhere and is getting weird error messages). Trying to redefine the identifier to see if it's a macro still sounds an awful lot like what you call voodoo programming to me. Quote:Original post by SiCrane Quote: I guess the only reliable way around it would be to minimize the amount of external includes (i.e. make wrap up external headers) and using long identifiers or rare naming conventions. While minimizing depedencies in C++ header structures is always a good idea, using long identifiers isn't necessary. As I mentioned earlier, you can use namespaces, it's practically what they were invented for.I do (including on my current C++ project), unfortunately they're not always available. It doesn't solve macro problems however, which are the ones that generate the weirdest results. Quote:Original post by SiCrane Quote:So, do you consider a trailing underscore as an alternative here? Here's the thing, I've got a harder time noticing trailing underscore than leading ones. Did you give them a fair chance? And keep in mind, there's nothing wrong with a leading underscore followed by a lower case letter in class scope. If all you use your leading underscores for are to denote class members and you restrict your member identifiers to lowercase then there are no issues.Yes, I tried trailing underscores on a project maybe a year or so ago. I didn't have any big problems reading or writing them but I still thought prefixes were easier to deal with. And whatever convention I end up using it's going to apply to the whole project, which includes globally "private" and local static identifiers. The best alternative I've found so far is using m_, g_, s_, etc. I don't quite like having to emphasise the variables scope rather than just it's "privateness". I guess you could use something like i_ for all 'internal' identifiers but it just doesn't look clean to me. Another option would be to switch to CamelCase and use something like iPrivateVariable or even Iprivate_variable. Quote:Original post by SiCrane Quote: Still, the point is that I've found a convention that I like and which is easy to work with. I almost certainly won't stay with it forever but the issue here is whether it right now, for me personally, (given what I'm used to and the possibilites I know about) has any advantages over the others. And I honestly think it does. Fine, I don't care what you do in your programs. The point I've been trying to make is that you can have your deficient programming practices but don't try to claim that they are good, or even acceptable, programming practices, and don't try to spread them to others.And I guess this is our main disagreement. First of all I would never try to promote my own coding style, at least not unless explicitly asked. I'm not trying to deny that there are obvious, undeniable, technical problems with leading underscores. My argument all along has been that their risks appears to be exaggerated, so if they otherwise help you write better/more/prettier code then it's perfectly valid to accept risks. Whether it's "worth it" and where the line goes is all a matter of how much you gain and how much you loose, and highly subjective. A beginner is almost certainly not qualified to make that decision, but think I am (for me personally, not in general). Overall that's another debate which I hope to stay out of, but at least I'm fairly confident that I've made the right decision for myself. Perhaps the most imporant realization is this: it's a minor issue dragged way out of proportion. I think we can both agree that it's unlikely to have a significant impact on your project either way, and this makes quantifying the weights involved all the harder especially given the amount of religion surrounding it. Of course this isn't really getting anywhere, but I hope that I've at least demonstrated that there's more behind my reasoning than just being stubborn (of course I'm being stubborn too, but there's more to it than). Here's what you can do to convince me of choosing a different convention for the next project. 1. Give practical examples of compilers which reserve many common names containing leading underscores, or examples of practical problems they've caused which I don't seem capable of handling in reasonable time. 2. Suggest another coding convention which I'd work almost as well as leading underscores. This is much harder given that C doesn't have any more special characters to play with. edit: How did this post get so huge? [Edited by - doynax on January 8, 2006 10:23:07 AM]
  5. Planning Ahead for Multiplayer...

    Don't forget that UDP has another huge advantage which hasn't been mentioned yet. NAT punch-through is nearly impossible with TCP. It may or may not be an issue in this case, but it's definitely worth considering early on. Of course if you're willing to use an external networking library it should be fairly easy to switch later on..
  6. %APPDATA% is just a normal environment variable AFAIK, although I believe there may be better ways to lookup the application data directory. However %CD% is special (it's even missing from the shell's "env" list), I assume it's automatically expanded by CMD itself. But if you just want to get the current directory rather than expanding environment variables in a shell-compatible manner then I suggest you use the native API (GetCurrentDirectory) instead. Oh, and the standard library already provides functions for getting environment variables. So check out C89's getenv() function if you want Unix compatibility.
  7. Quote:Original post by Luke Hutchinson "68 F3 00 00 00 push 0F3h" could have been better encoded as "6A F3 push 0F3h". This has to be one of the simplest optimisations possible for a compiler to get correct. Wonder why it didn't???Because 0xf3 would get sign extended to a negative integer. At least that's what Nasm's disassembler tells me..
  8. Common notation

    Quote:Original post by SiCrane Quote:Original post by doynax All I'm saying is that it's never been such a big issue, and I want people to be able to make an informed decision about it rather than hearing "it's evil, stay away". Just beware of the risks and choose for yourself. It is evil. You should stay away. The fact that you don't accept this has made my estimation of your skill as a programmer drop significantly. There are a number of different coding styles equally as terse and legible as using underscore prefixes that do not have the same problems. There is simply no good reason to use leading underscore prefixes in your coding style, except for blind prejudice. And there is less than no reason for saying that the practice is acceptable unless you actively enjoy misleading beginner programmers or you're too egotistical to acknowledge that your coding habits are defective.Very well, I accept whatever your estimation of my skills as a programmer might be. I'm not quite sure what you mean when you say that the other coding conventions don't have the same problems. I've used compilers with non-standard reserved keywords before (FAR, pascal, etc), and new keywords may of course be introduced when switching standards (there's lots of examples between C89 and C99 or between C and C++). But in my experience the vast majority of the clashes are with 3rd party libraries. But I definetly agree that there are coding conventions which are likely to cause less collisions. Part of the issue is also how big this problem was to begin with, personally I spend very little time on fixing them. I will admit that years ago as a less experienced C programmer I've spent quite bit of time and headscratching on individual instances of these seemingly impossible problems, but it's hardly a problem anymore mostly because I've developed a strategy to deal with them relatively fast (Visual Assist helps a lot too by making macros stand out). There are many mroe of these magical problems in C++ though, the static initialization order is a good example. Solving these may require all kinds of skillsets but I've gotten much better at dealing with them over the years. As I state below this issue depends entirely on whether you subjectively (altough not religiously) think the convention of leading underscores has any advantages. Don't forget that one of these subjective advantages is familiarity. I hope you don't seriously believe that I'm actively trying to mislead beginners, if you've got to believe something then believe that I'm being egotistical. In any event "defective" is a strong word, but I guess it may have been warranted given the lenght (and apparent lack of ending) of this discussion). Lets put it this way, I belive there are advantages to leading underscores in certain cases (such as my own), and thus I don't consider this as a religious issue but rather as a tradeoff. Sure, I may overestimated the believed benefits of having leading underscores or undervalued the costs of the potential bugs caused by them but from the experience I've had that doesn't seem to be the case. I'll let you in on another secret of mine. I have huge motivational problems and only write code in bursts as a hobby for my own pleasure. And when I write code I almost always do it for the process, rather than the results (i.e. I enjoy coding). Now, writing "pretty" or generally beautiful code is a *big* part keeping my motivation. If things start to get hacky or ugly then I generally dump the project and move on to something else. Quote:Original post by SiCrane Quote:You still have to analyze the issue of course, but the first step towards finding the cause of this particular class of bug is figuring out if there's something strange going on with your identifiers. And so just because you chose a crappy coding standard, you now have to add random identifier changes to your debugging strategy? That's wasted time and effort, which is further amplified if the problems are as rare as you claim. If you chose a coding standard that means you don't need to make random changes to your identifiers then you eliminate an entire class of problems from your code.That's not what I'm saying. The problem itself it quite common (perhaps something I run into every few weeks or so). And it happens with most naming conventions (again, Min and Max from Windows.h are good examples). So unfortunately anyone can run and will run into it in C++. I guess the only reliable way around it would be to minimize the amount of external includes (i.e. make wrap up external headers) and using long identifiers or rare naming conventions. Quote:Original post by SiCrane Quote:Just about everything is bad to one degree or another. Try to make informed decisions and use it right, that's all there is to it. This has never been a matter of absolutes. Yes it is. It is absolutely a bad practice. Just because you've gotten away with it so far is no reason to say that is acceptable. Again, there are no benefits over the alternatives and more problems.So, do you consider a trailing underscore as an alternative here? Here's the thing, I've got a harder time noticing trailing underscore than leading ones. It's not a religious issue, I just think that's the case. Does that not qualify as an advantage over an alternative, because that's what it all boils down to. I once used leading m_ for members and other similar hungarian-notation inspired things. I had no problems seeing these but I disliked that fact that they're two characters long and had a meaning beyond just being internal (i.e. I felt forced to separate external names and fields with different prefixes). There are other less common variants too, such as a single leading m without an underscore. But that basically forces me into CamelCase, wich I don't use for the moment. Undoubtedly there are other naming conventions too, although I can't quite think of any for the moment. Still, the point is that I've found a convention that I like and which is easy to work with. I almost certainly won't stay with it forever but the issue here is whether it right now, for me personally, (given what I'm used to and the possibilites I know about) has any advantages over the others. And I honestly think it does. Oh, BTW, do you have any recommendations for alternative naming conventions? Preferably something I many not have encountered before (and a short sales-pitch on why it's good). Oh, and it'd be good if it's somewhat language independent (within reason).
  9. Common notation

    Quote:Original post by SiCrane Quote:Original post by doynax Even a beginner should feel free to use leading underscores if he think's that makes the code easier to read (or "prettier") and is prepared to deal with the issues that might come up. The important thing to note is that it's a rare occurance but can be hard to analyze when it's happens, especially if you're not experienced to C++. There's no reason to suggest to a beginner that he get used to this coding style to start with. That's just bad advice. So what if you've never had a problem with it? The fact that the issues are rare make it even more important to avoid this kind of crappy coding practice to begin with; by the time someone does run into a problem with it, he may have forgotten that there's an issue with this kind of practice. (Another good reason to mention it whenever appropriate.) The fact of the matter is that people do run into these problems. I've had them, other people who've posted on these boards have had them and people I've worked with have had them.Yes, but I've never recommended anything one way or the other. I mostly try to stay away from coding style debates entirely. All I'm saying is that it's never been such a big issue, and I want people to be able to make an informed decision about it rather than hearing "it's evil, stay away". Just beware of the risks and choose for yourself. Besides, I still think you're considerably more likely to collide with another library than a reserved identifier in the compiler. So I'm quite sure I've got fewer collisions nowadays compared to (one of) my previous styles without the leading underscores or any prefix/postfix at all. Quote:Original post by SiCrane Quote:In general renaming identifiers is a good trick to use when you've got a seemingly bizzare bug to fix. Ah yes, the school of voodoo programming where you try random changes to your code to silence symptoms without understanding what the real problem is. Here's an idea: don't use a coding style that allows these kinds of problems in the first place.You can't get away from this kind of thing in C++, sooner or later something "weird" happens and you've got to deal with it. You still have to analyze the issue of course, but the first step towards finding the cause of this particular class of bug is figuring out if there's something strange going on with your identifiers. Quote:Original post by SiCrane Quote:Thus I judge that it's worth it (for me). Fine, you accept that you have a bad habit. Don't try giving it to others.*Groan* Just about everything is bad to one degree or another. Try to make informed decisions and use it right, that's all there is to it. This has never been a matter of absolutes. What you should ask yourself is if it's the style that you find easiest to read and write. And, if so, if you're prepared (and experienced enough) to deal with a few bizarre bugs if they come up. Also beware that this is another portability when switching compilers (although that's rarely pain-free however carefully you code). Thus the rewards are greater than the risks then I say use it, but for beginners it almost certainly isn't. Quote:Original post by rip-off Quote: In general renaming identifiers is a good trick to use when you've got a seemingly bizzare bug to fix. okay, your style is your own, and i cant stop you using it. but this is the best bit of advice you've given yet. because thats what every programmer does when they've got a bug to fix. out of curiousity how often does this actually work for you? how often does it create even more bugs?It works fairly often actually, often it's an overloaded macro that does unexpected things to your code. But most of the time I just use it to rule out this class of bugs. As I said above it's just another trick coders use to locate bugs, you still want to find the source. The next step may be #define the identifier to see if there's any macros covering it, or googling to see if it's a known identifier. I suppose the min() and max() macros from Windows.h is a good example here. [Edited by - doynax on January 7, 2006 11:17:25 AM]
  10. Common notation

    Quote:Original post by Enigma <continuing-the-off-topic> I'm going to be a little harsh here. doynax - what's the problem with repeatedly mentioning a fact and advice (advice given by true C++ experts and C++ standards committee members I might add)? OK, so you know it already, but this is a public message board. You don't know who else might be reading. And some of them might not have heard it. To point out the rules of C++ identifiers is a perfectly valid comment to make and in my opinion one that should be made since it can save someone debugging time. OK, so maybe it will only save one person in a hundred one hour of debugging time, but that's still better than not saving that debugging time.Yes, it's a valid point (in this particular thread it's almost on topic). It's was just repeated so often as an off topic remark that I thought it had gotten out of proportion compared to the actual risks involved. As of yet I haven't spent a single minute of time on debugging it, but I'm prepared to do it and as a C++ programmer I've gotten quite used to this kind of thing. Quote:Original post by Enigma Also, I get the feeling that it's possible your objection is based more on the fact that you're beginning to get too religiously attached to your coding standard than anything else. I may be wrong, it's just a possibility. Whenever somebody starts arguing against a minor correction on the grounds of prettiness quiet alarm bells go off in the back of my head. 'Pretty' is subjective. It probably just means you've gotten used to that way. I was very protective of my coding style for several years before I came to the realisation that in some ways I was just being petty. I forced myself to change things whenever I could find a decent justification. Nowadays my coding convention looks very different to when I started and things that I used to absolutely despise are now second nature. I still re-examine aspects of my coding style periodically, just so I don't fall back into the trap of style over substance.Heh, believe me when I say that I'm *far* from religious over it. In fact I make a point out of changing part of my coding style and trying out something new on each new project I write (seriously, I'm currently trying out 2-character tabs). I'd argue that it's harder to spot postfixes and the only natural single character prefix to use is the underscore. But of course I could use, and get used to, something else. I just don't think it's worth it. If I encountered a compiler I wanted to use that did magical things on all identifiers with leading underscores then I'd probably permanently switch to something else.
  11. Common notation

    Quote:Original post by SiCrane Quote:Original post by doynax In any case I'm not trying to promote my own style here but rather saying that it's an acceptable one to have, and not an absolute evil as seems to be the general opinion. We've been through this so often that most people using the style are aware of the issue and accept it. Except that it's not acceptable. You're using the same argument that people who free() things they new, use two ++ on the same variable in the same statement, use the literal 4 in the place of sizeof(int), bit manipulate to extract undocumented information from operating system handles, use goto for loops, or rely on buggy behaviour in system calls use to justify they're behavior. And again, it's also not acceptable to try to say it's acceptable in For Beginners.There's nothing wrong with those arguments, in fact feel free to sacrifice portability for convenience or performance. My code relies on a lot of these things (more than unique 8 characters identifiers in C89 code, byte datatypes, two's complement, anonymous structures, etc). As I said it's a tradeoff, the important thing is that it's an informed one (i.e. that you're aware of what you're loosing). Even a beginner should feel free to use leading underscores if he think's that makes the code easier to read (or "prettier") and is prepared to deal with the issues that might come up. The important thing to note is that it's a rare occurance but can be hard to analyze when it's happens, especially if you're not experienced to C++. In general renaming identifiers is a good trick to use when you've got a seemingly bizzare bug to fix. Quote:Original post by SiCrane Quote:Unfortunately C++ programmers have to deal with this kind of magic (and various kinds of psychic debugging) on a regular basis. It comes with the language, whether or not you use leading underscores. That doesn't mean you should say that a completely unnecessary practice that has equally legible alternatives that leads to "psychic debugging" is acceptable. Since C++ programmers already have to deal with these kind of problems, there's no reason to add to the number of potential causes of bizarre behavior just because you're too lazy to write your code correctly in the first place; there are already enough places to screw up your C++ code without tempting fate to add some more.But it's not "completely unnecessary". I find it shorter and easier to read than the alternatives, in fact that's kind of the point. Thus I judge that it's worth it (for me). I mean I *could* use 8-character names in my C89 code, but I've got something to gain from the non-portable assumption. It's precisely the same kind of situation, just with different factors involved. Quote:Original post by SiCrane No, I meant trailing. All identifiers with double underscores are reserved for any use by the implementation, not just leading double underscores. And they're not safe to use. (And for the record, this was a fork of the gcc toolchain, I think off of 2.95, for an embedded processor family.)That's interesting, luckily I've never seen anyone trying to use double underscores in their own names.
  12. Common notation

    Quote:Original post by SiCrane Just don't try to pretend that it's good practice and don't try to foist it off as acceptable on others. You can crap up your own code all you want, but if you know it's not right, there's no reason to infect others with your defective coding style, especially when posting in For Beginners.I'll have to admit that I never noticed this was a For Beginners thread, I apologize for that. I suppose I should've waited for a thread in General Programming instead. But of course it's an acceptable convention. It's a tradeoff, just like with any another other non-standard compiler features. In any case I'm not trying to promote my own style here but rather saying that it's an acceptable one to choose as long as you're aware of the issues, and not an absolute evil as seems to be the general opinion. We've been through this so often that most people using the style are aware of the issue and accept it. Quote:Original post by SiCrane Because these identifiers can be reserved for the implementation for any purpose when you do run into a problem they can be very hard to track down, and it's not something you can expect someone in the For Beginners forum to be able to find.Unfortunately C++ programmers have to deal with this kind of magic (and various other kinds of psychic debugging) on a regular basis. It comes with the language, whether or not you use leading underscores. Just another reason why I don't think it's a good language for beginners. Quote:Original post by SiCrane For example, identifiers with trailing double underscores may not link the way you expect on some compilers because they get treated as if they were placed in anonymous namespaces. Try debugging that one for a while.You mean leading, right? Do you have any concrete examples of such compilers? I've never encountered this issue. Considering that it's a very common coding style I can't imagine it'd be the case in any mainstream compilers. edit: Oh double underscores, I missed that part (and I've never seen a style using them). Still, any examples would be interesting.
  13. Common notation

    Quote:Original post by SiCrane Leading underscore, not trailing underscore.Whoops, I meant leading of course. Quote:Original post by SiCrane And the nitpick was about leading underscore followed by a capital ex: _Foo, not _foo, and it wasn't someone showing an identifier, it was someone trying to explain what identifier patterns to avoid.I was trying to reply to the last post in the discussion (from which your first post had been stripped out), it wasn't even particularily aimed at you personally. And I was trying to deal with the use of leading underscores in general, regardless of what they're followed by or where you use them. Quote:Original post by SiCrane And guess what, I have run into problems with that one. One of the Metrowerks preprocessor versions took the identifier _Line and stripped it out of source code. So yes, it is worth commenting on. Just because you've gotten away with doing a bad practice doesn't mean that it isn't a bad practice.I don't doubt that it does infact happen, the point was that it's exceedingly rare and not at all the big issue it's made out to be. Personally I'm more than willing to deal with a few collisions (especially since I haven't actually had any as of yet) in order to keep my current short and "pretty" coding style, and I doubt that I'm alone. So, yes, I agree that it's bad practice but you have to realize that it's just as bad to use short identifiers or overly generic names. Thus I belive that it's worth dealing with when it comes up rather than banning their use entirely.
  14. Common notation

    Quote:Original post by SiCrane Quote:Original post by Xai As mentioned already, DO NOT start any non-members with an underscore, it just makes life easier (some people do start member variables with an underscore ... which is ok). Underscore followed by a capital letter is not ok, even for member variables.Oh, come on. Stop nitpicking on this issue already. I realize that it may be good to know that they're technically reserved, in fact I like trivia and obscure language details as much as the next guy, but do we really have to comment on it every single time someone shows a code snippet containing a leading underscore in one of the identifiers? I mean if someone uses "foo" then no one complains but apparently "_foo" is some kind of sin, now which one do you think is more likely to cause problems? I personally use them all over the place to mark internal things (i.e. private or local), mostly because I find trailing underscores quite ugly. In fact the consistent use of underscores to separate all of those short local names combined with the use of module prefixes and namespace has significantly reduced the number of collisions I've had to deal with during the last few years. And guess what, they've *never* collided with any reserved identifiers for me. Ever (well, I can't be absolutely certain but it hasn't happened in recent history). On the other hand I've frequently crashed into the WinAPI (I swear they must have defined half the English language in that rat's nest of headers) and various other libraries. And in any event a global search and replace to fix the name is rarely more than a two minute affair, especially with private names since they're by their very nature easy to fix. </off topic rant> [Edited by - doynax on January 7, 2006 8:48:55 AM]
  15. It should work fine provided that the static variable is defined in the source file too. Beware of initialization order problems if you extend this another level though (i.e. a static class in a static class). edit: I'm way too slow for this forum..