Though implementation problem

This is a discussion on Though implementation problem within the C++ Programming forums, part of the General Programming Boards category; Yes, the code compiles, but it is far from correct. In the first case, -1 is converted to unsigned and ...

  1. #286
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Yes, the code compiles, but it is far from correct.
    In the first case, -1 is converted to unsigned and 255 is added.
    In the second case, the number is truncated and 255 is added.
    What's "correct"? Given that you're dealing with an unsigned 8-bit value which uses modulo math, adding -1 and adding 255 are mathematically identical. So are adding 2^64 - 1 and adding 255.
    If you don't actually want modulo-256 ring math, why are you using a CInt<uint8_t>?
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  2. #287
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,887
    CInt<uint8_t> is just a way of saying "I want this integer to be 8 bits."
    But it doesn't stop me from adding 64-bit integers. Yes, it will overflow, but in some instances, you might want to or ignore that.
    And besides, the point is that it's misleading. The result is pretty undefined and that's wrong. You would expect to be able to add something without truncating it. The behavior is just... too wrong.

    For example:
    Code:
    	uint8_t i = 0;
    	i += 0xFFFFFFFFFFFFFFFF;
    This code will perform the addition in full 64-bit addition operation on i, and then truncate it when moving it back into i.
    However, the class would truncate the number to 0xFF and then add it, which wouldn't produce the same operation, though I'm unsure if it would produce the same result.

    I don't know the impact of this but it's certainly not a good thing, because it destroys warnings (especially unsigned/signed warnings).

    phantomotap:
    However, I still see no reason as to not use templates. They are a generic way of doing the same thing for an infinite range of types, right?
    Since all types would be handled the same, I see it as a means to remove code duplication and maintenance for the class. The real beauty lies in that I can specialize a template if I need a specific type to behave differently.
    Last edited by Elysia; 05-31-2008 at 11:06 AM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #288
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    And besides, the point is that it's misleading. The result is pretty undefined and that's wrong. You would expect to be able to add something without truncating it. The behavior is just... too wrong.
    Not, it's perfectly defined and correct. You just have to understand the mathematics of modulo rings.
    http://en.wikipedia.org/wiki/Modular_arithmetic

    However, the class would truncate the number to 0xFF and then add it, which wouldn't produce the same operation, though I'm unsure if it would produce the same result.
    It would. That's why your concern is unfounded.

    because it destroys warnings (especially unsigned/signed warnings).
    None that I know of. Shouldn't it already warn you upon creating the implicit CInt<uint8_t> because of the truncation?
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  4. #289
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,887
    Quote Originally Posted by CornedBee View Post
    None that I know of. Shouldn't it already warn you upon creating the implicit CInt<uint8_t> because of the truncation?
    It doesn't.
    This produces a warning:
    Code:
    	uint8_t i = 0;
    	i += -1;
    	i += 0xFFFFFFFFFFFFFFFF;
    This doesn't:
    Code:
    	CInt<uint8_t> i;
    	i += -1;
    	i += 0xFFFFFFFFFFFFFFFF;
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #290
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    How about this?
    Code:
    	CInt<uint8_t> i;
    	int i = rand() - (RAND_MAX / 2);
    	i += i;
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #291
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,887
    No warning. Change to uint8_t, I do get a warning.
    Wait. It might be because of something implementation. I'll run a test.
    EDIT: Now I get a warning for both.

    I see now. It's basically the same behavior as if doing with native types.
    Code:
    	uint8_t i = 0;
    	i += 0xFFFF; // Truncation
    	i += -1; // Signed/unsigned
    My fears are unfounded. Good.
    Last edited by Elysia; 05-31-2008 at 12:04 PM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #292
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,356
    However, I still see no reason as to not use templates.
    I didn't say not to use templates. I'm against the notion of not using templates.

    They are a generic way of doing the same thing for an infinite range of types, right?
    No, but they can be used to express such a thing; even dumb C macros are capable of that.

    Since all types would be handled the same, I see it as a means to remove code duplication and maintenance for the class.
    You need to learn the difference between a class and a template class.

    The point stands, a template class can most certainly benefit from doing things properly because it may benefit every instantiation.

    The real beauty lies in that I can specialize a template if I need a specific type to behave differently.
    You can't specialize a template method; you can only specialize the behavior or overload the interface/implementation.

    Why attempt a specialization or partial specialization at some later point if you find you require a compiler that doesn't handle temporaries/forwarding well?

    Well, anyway, you have a possibility and a possible proof that it isn't useful here--as provided by CornedBee. So, what are you going to do with them?

    Soma

  8. #293
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,887
    I've already changed it to:
    Code:
    	CInt& operator &#37;= (const CInt& Data);
    And it seems to behave just as with normal integers, so I'm all happy now with less complexity


    Ah yes, quick question:
    I'm trying to check for overflow/underflow, but instead of taking into account everything (including the possibility of negative numbers) and using templates/traits for max/min range of numbers, isn't there some assembly equalient that can check for overflow/underflow?
    I'm not sure if there are some other functions that may check or if it's possible to check in assembly after the operation has been done (ie check flags)?

    Suggestions?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #294
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,742
    Why is this thread nearly 300 replies long?
    Haven't you fixed the original problem yet, or is this just a meandering "Elysia" support thread?

    Just a suggestion, but if these are new questions, they should be new threads, with links if you think it's relevant.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  10. #295
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,356
    I'm trying to check for overflow/underflow, but instead of taking into account everything (including the possibility of negative numbers) and using templates/traits for max/min range of numbers, isn't there some assembly equalient that can check for overflow/underflow?
    It depends on the architecture and operation, but I think 'x86' has a flag that it sets after an operation is performed if any overflow/underflow occurs.

    Soma

  11. #296
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,887
    Oh, I could fit in a 100 questions to this generic topic title, but if you insist, I can make new threads.
    But I found it exciting to enlarge the thread and see how many replies could get crammed into it.

    Quote Originally Posted by phantomotap View Post
    It depends on the architecture and operation, but I think 'x86' has a flag that it sets after an operation is performed if any overflow/underflow occurs.
    Soma
    Yes, it's x86. I don't do much other than Windows™ programming.
    I'd rather do it in assembly than a fat code and additional complications to check for under/overflow.
    I'll try looking in an assembly manual.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  12. #297
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,356
    I'd rather do it in assembly than a fat code and additional complications to check for under/overflow.
    So?! If you don't want "fat" code, write "lean" code. I mean: hack away...

    Soma

    hackersdelight.org

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. WS_POPUP, continuation of old problem
    By blurrymadness in forum Windows Programming
    Replies: 1
    Last Post: 04-20-2007, 07:54 PM
  2. Laptop Problem
    By Boomba in forum Tech Board
    Replies: 1
    Last Post: 03-07-2006, 06:24 PM
  3. implementation file
    By bejiz in forum C++ Programming
    Replies: 5
    Last Post: 11-28-2005, 01:59 AM
  4. Replies: 5
    Last Post: 11-07-2005, 11:34 PM
  5. Memory Problem - I think...
    By Unregistered in forum C Programming
    Replies: 4
    Last Post: 10-24-2001, 01:14 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21