Thread: Performing One's complement on Pointers

  1. #16
    Registered User gardhr's Avatar
    Join Date
    Apr 2011
    Posts
    151
    Quote Originally Posted by Elysia View Post
    Minus points for obfuscation, though. Use proper variable names and typedef names. Also get rid of the pointer typedef.
    Also, conversion from T* to unsigned char* is either a compile error or a warning. You should fix that.
    Well, I've been writing software professionally for many years now, and I can assure you that the only true measures of good coding practices are stability, portability, and reuseability. Focusing on such inconsequentials like style conventions and so forth is really just a waste of time, IMO. Developers that yield aesthetically pleasing crap are a dime a dozen; the best ones often produce the most quirkily written code imaginable, but are yet as rare as diamonds and thus worth their weight in gold! Bottom line: substance always trumps style. Full stop.

    Quote Originally Posted by oogabooga View Post
    Code:
            *begin++ ^= ~0;
    Just bear in mind that the literal ~0 is an int and so the left-hand-side gets widened to an int before the XOR, then narrowed back to unsigned char for the assignment, which may result in undefined behavior (correct me if I'm wrong). Just to be safe, you should always use explicit casts in such situations. In other words:

    Code:
            *begin++ ^= (unsigned char)~0;

  2. #17
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    O_o

    I don't know what mean tricks reality has pulled on you gardhr, but you need to realize now that what you've said in post 16 is moronic.

    "Substance", as you call it, it extremely important, but source is written for humans. Clarity is crucial. (Anyone who says differently is an idiot or simply never had to maintain COBOL.) And the important part is, it doesn't cost anything. The changes Elysia suggested aren't going to make the code less stable, portable, or reusable; those changes only make the code more readable and the intent more obvious.

    Soma

  3. #18
    - - - - - - - - oogabooga's Avatar
    Join Date
    Jan 2008
    Posts
    2,808
    the best ones often produce the most quirkily written code imaginable
    I disagree. "Super-programmers" are an old-fashioned idea that has proven disastrous. Modern practice is to write for humans.

    Just bear in mind that the literal ~0 is an int and so the left-hand-side gets widened to an int before the XOR, then narrowed back to unsigned char for the assignment
    I don't see why that would be the case. Surely it can all be handled at compile time (a disassembly shows that gcc handles this efficiently).
    The cost of software maintenance increases with the square of the programmer's creativity. - Robert D. Bliss

  4. #19
    Registered User gardhr's Avatar
    Join Date
    Apr 2011
    Posts
    151
    Quote Originally Posted by phantomotap View Post
    O_o

    I don't know what mean tricks reality has pulled on you gardhr, but you need to realize now that what you've said in post 16 is moronic.

    "Substance", as you call it, it extremely important, but source is written for humans. Clarity is crucial. (Anyone who says differently is an idiot or simply never had to maintain COBOL.) And the important part is, it doesn't cost anything. The changes Elysia suggested aren't going to make the code less stable, portable, or reusable; those changes only make the code more readable and the intent more obvious.

    Soma
    Sure, but at what expense do you enforce such practices? In this industry, time is invaluable; time consumed cleaning up code would have been much better spent shoring it up, so why even bother? In the company that I work for now, for example, I manage a large number of developers but enforce no style constraints whatsoever, yet we still manage to produce code that requires very little bug maintenance. Our code review team doesn't seem too concerned with having to sift through the unregulated mass of prose either, no doubt due to the fact that the quality of the code produced is so good. Simply put, ignoring trivial details allows you to focus all of your energy on what's truly important. Pleasant sounding platitudes aside, you have to learn to see the forest for the trees in this business (otherwise you might end up such incontrovertible garbage as the android operating system or what have you).

  5. #20
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    O_o

    You spend so much time actually writing new code that the time you would have spent writing clear code instead signifies a real cost!?

    That's unfathomable. I admit it; I have no answer for that. The "lines per minute" you produce must be insane if taking a couple extra seconds per line is going to significantly affect that number.

    I'm not joking; I'm literally shocked by that claim. I, and every decent programmer I've ever worked with, spend I'd say 60%-80% of new development time reasoning about what to write next. For me, those couple of seconds per line in the cycle of new development is insignificant when compared with the vast amount of time spent reasoning about issues of "substance".

    Soma

  6. #21
    - - - - - - - - oogabooga's Avatar
    Join Date
    Jan 2008
    Posts
    2,808
    In the company that I work for now, for example, I manage a large number of developers but enforce no style constraints whatsoever
    What company do you work for?
    The cost of software maintenance increases with the square of the programmer's creativity. - Robert D. Bliss

  7. #22
    Registered User gardhr's Avatar
    Join Date
    Apr 2011
    Posts
    151
    Quote Originally Posted by phantomotap View Post
    O_o

    You spend so much time actually writing new code that the time you would have spent writing clear code instead signifies a real cost!?

    That's unfathomable. I admit it; I have no answer for that. The "lines per minute" you produce must be insane if taking a couple extra seconds per line is going to significantly affect that number.

    I'm not joking; I'm literally shocked by that claim. I, and every decent programmer I've ever worked with, spend I'd say 60%-80% of new development time reasoning about what to write next. For me, those couple of seconds per line in the cycle of new development is insignificant when compared with the vast amount of time spent reasoning about issues of "substance".

    Soma
    Maybe I should have been clearer. I'm not implying that it's acceptable to produce obfuscated code. I'm talking about minor style issues: indentation, spacing, variable naming conventions, etc. What I'm saying is that when you insist upon arbitrary coding conventions, you are essentially depriving your developers from working at their optimum comfort level, even forcing them to spend precious time formatting code in a way that is frankly unnatural to them. That's counterproductive, is it not?

  8. #23
    Registered User gardhr's Avatar
    Join Date
    Apr 2011
    Posts
    151
    Quote Originally Posted by oogabooga View Post
    What company do you work for?
    Why, are you looking for work? Seriously though, I can't disclose that sort of information on a message board, although I can tell you the company's been around for a very long time and holds a large market share in software for consumer devices of all sorts. I've been with the company for a little over five years now, the last two years of which I've been a senior developer.

  9. #24
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by gardhr
    In the company that I work for now, for example, I manage a large number of developers but enforce no style constraints whatsoever, yet we still manage to produce code that requires very little bug maintenance.
    I too find that hard to believe. If you're managing a small number of good developers, then it is certainly possible that no style constraints need to be enforced or even spelled out, because it comes naturally from their skill and experience. But the larger the number of developers, the more likely that you'll have rotten apples who write unreadable code and still managed to get hired, and for whom a coding convention is necessary, even if it is not rigidly enforced.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  10. #25
    Registered User gardhr's Avatar
    Join Date
    Apr 2011
    Posts
    151
    Quote Originally Posted by laserlight View Post
    I too find that hard to believe. If you're managing a small number of good developers, then it is certainly possible that no style constraints need to be enforced or even spelled out, because it comes naturally from their skill and experience. But the larger the number of developers, the more likely that you'll have rotten apples who write unreadable code and still managed to get hired, and for whom a coding convention is necessary, even if it is not rigidly enforced.
    Again, there's a difference between obfuscated code and code written using one's own preferential style. You may think the line between the two to be rather subjective, but in practice it's really pretty straight-forward: the former is nearly impossible to follow and the latter is merely annoying to read, at worst! Either way, it's not an issue affected by scale so much as it is by the organization of your development process and the nature of your (corporate) culture...

  11. #26
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    O_o

    There is a difference between between obfuscation and unfamiliar style! When a "personal style" imposes no reasonable layout or allows meaningless names it devolves into simple obfuscation. Demanding clear, reasonable, and maintainable source isn't the same thing at all as saying that every '{' characters must be indented 3 spaces from the previous indentation level and variable names must begin with "foo".

    You don't need a rigid style guide to require naming variables after what real data they represent or functions after the task implemented. You don't need to manage a million lines and a hundred programmers to understand the benefit of "self documenting code". You don't need to have worked a decade to know that following a reasonable style isn't actually time consuming.

    Drawing an imaginary line between "This is obfuscated source." and "This is source written in my personal style." will not get you anywhere if the code is an ambiguous, inconsistent, semantically meaningless, nightmare of spaghetti code.

    Soma

  12. #27
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by gardhr
    Again, there's a difference between obfuscated code and code written using one's own preferential style. You may think the line between the two to be rather subjective, but in practice it's really pretty straight-forward: the former is nearly impossible to follow and the latter is merely annoying to read, at worst!
    Aye, and if we go back to the context, "use proper variable names and typedef names" is not the imposition of any personal preferential style. It is simply stylistic common sense that can hardly be disputed in a sensible coding standard. Getting rid of the pointer typedef makes sense: we're not dealing with an opaque pointer or a typedef for an iterator type, so hiding the fact that it is a pointer is just obfuscation.

    EDIT:
    Basically, I think you're picking the wrong bone here. If this was a "tabs versus spaces" issue, then certainly it is fair to criticise the style critique as inconsequential.
    Last edited by laserlight; 03-11-2012 at 07:45 AM.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Two's complement
    By matthayzon89 in forum Tech Board
    Replies: 7
    Last Post: 08-30-2010, 12:22 AM
  2. 1's and 2's complement
    By Jaguar in forum C Programming
    Replies: 3
    Last Post: 10-14-2003, 09:12 AM
  3. how to complement
    By stautze in forum C++ Programming
    Replies: 2
    Last Post: 09-28-2002, 06:16 AM
  4. 2's complement in C
    By Kokila in forum C Programming
    Replies: 3
    Last Post: 09-07-2002, 11:51 AM
  5. Two's Complement
    By Unregistered in forum C Programming
    Replies: 9
    Last Post: 02-26-2002, 05:52 AM