OSDev.org

Candy wrote:

Colonel Kernel wrote:I've been working in the software industry for over a decade. I've seen code written by lots of people, most of whom are very smart and not lazy. They make mistakes. They are human beings, after all. Those mistakes cost time and money, and I would rather have the compiler catch those mistakes than my test team, thank you very much.

Most typos and mistakes I've seen didn't involve pointer arithmetic of the variant of adding a random number to a pointer, nor have I seen reinterpret_cast's used at all. Nor C casts with the same effect.

// Vector is just like std::vector.
Vector v = getAVectorFromSomewhere();
assert( !v.isEmpty() ); // Assume for this example that it's not empty.
someOldCFunction( &v[0] ); // Legal in STL, and for our Vector.
// The above trick is explained in Scott Meyer's Effective STL.

// String is not like std::string -- it encapsulates an immutable buffer
// of characters that is managed by a reference count.
String str = getAStringFromSomewhere();
assert( !str.isEmpty() ); // Again, assume it's not empty...
anotherOldCFunctionThatFillsABuffer( &str[0] ); // Aaaaaarrggh!

Foo* foo = getAFooFromSomewhere();
// Assume for the sake of this example that foo really points to an instance of Bar.
Bar* bar = (Bar*) foo; // Bar is derived from foo.
bar->doSomething(); // May crash in the presence of MI.

    +-----+  Where bar *should* point to.
    | Baz |
--> +-----+  Where foo points to.
    | Foo |
    +-----+
    | Bar |
    +-----+

Zekrazey1 wrote:Why waste effort on something that you can get the computer to handle?

Why waste effort on something that you can get the computer to handle?

os64dev wrote:note the '' around lazy, which should have given a less hard meaning but ok, lazy might be wrongly chosen here.

in some of your examples you already see a potential problem, for instance anotherOldCFunctionThatFillsABuffer(&str[0]), the problem here IMHO is that you have designed/used here a function that has a pointer to primitive type char *, so what do you expect.

If you want to do string manipulation then only have string parameters. If you need to link to old c code as the example does, write a wrapper function or better yet don't do it unless you rewrite the code to use strings.

Why waste effort on something that you can get the computer to handle?

1) To let developers understand what they are doing.

2) The get flexibility which might lead to better performance.

PS. If this all sound vague i am sorry, i have just finished 1.5 liter of beer.

1) To let developers understand what they are doing.
2) The get flexibility which might lead to better performance.

Colonel Kernel wrote:

Code: Select all

// Vector is just like std::vector.
Vector v = getAVectorFromSomewhere();
assert( !v.isEmpty() ); // Assume for this example that it's not empty.
someOldCFunction( &v[0] ); // Legal in STL, and for our Vector.
// The above trick is explained in Scott Meyer's Effective STL.

// String is not like std::string -- it encapsulates an immutable buffer
// of characters that is managed by a reference count.
String str = getAStringFromSomewhere();
assert( !str.isEmpty() ); // Again, assume it's not empty...
anotherOldCFunctionThatFillsABuffer( &str[0] ); // Aaaaaarrggh!

Code: Select all

Foo* foo = getAFooFromSomewhere();
// Assume for the sake of this example that foo really points to an instance of Bar.
Bar* bar = (Bar*) foo; // Bar is derived from foo.
bar->doSomething(); // May crash in the presence of MI.

I know that down-casting is typically a dubious practice anyway, but imagine for the sake of argument that this is one of the rare instances when it's necessary. Clearly this code should be using dynamic_cast, or at least static_cast if RTTI can't be used for whatever reason (portability, performance, etc.). For whatever reason, the knob who wrote this code didn't know that C-style casts could very well be interpreted as reinterpret_cast in this context. Imagine that Bar is derived from Foo, but also from Baz. What happens if the object layout looks like this?

static_cast or dynamic_cast will do the appropriate pointer adjustment for you, but reinterpret_cast (or possibly the C-style cast, depending on your compiler) will not. Yes, I've seen this happen (with an older version of GCC).

Most of the time we're stuck with the equivalent of asking a taxi driver to drive a Formula-1. They're good drivers, but way out of their league. But calling them "lazy" is just stupid IMO.

Candy wrote:That should give a compile error, or one out of four people screwed up. In increasing order of likelyhood:
1. The compiler writer, for not checking const correctness.
2. The function writer for taking an argument of type const char * and stripping const
3. You, for stripping const off explicitly (which I don't see here, so it's not likely)
4. The author of String who knows that his buffer is CONST and returns a non-const pointer to it.

Your compiler should / must handle this case properly to be C++ compliant. It can never assume that the base class is at the same place if it even barely touches MI.

You should have a checkin script that makes people that use reinterpret_cast ask you personally for agreement. It should never be used unless you're hacking - and when you're hacking you shouldn't be working on a product in an archive.

Did you consider sidewheels?

On your "must use library, library is evil" note - wrap it. Basics of OO programming - if you have ANYTHING non-trivial, encapsulate it and hide the complexity. If your library can write to a buffer, wrap it so you can use the string class for holding a result, or some other class. If it offers only a buffer-overflow unsafe function, wrap it with code that makes it impossible (effectively) to overflow the buffer. If it offers only a excruciating interface to use, design your own and wrap the library into that interface.

• bit
• int8 (8-bit signed integer)
• int16 (16-bit signed integer)
• int32 (32-bit signed integer)
• int64 (64-bit signed integer)
• uint8 (8-bit unsigned integer)
• uint16 (16-bit unsigned integer)
• uint32 (32-bit unsigned integer)
• uint64 (64-bit unsigned integer)
• float32 (32-bit floating point, IEEE format)
• float64 (64-bit floating point, IEEE format)
• int (platform-specific signed integer)
• uint (platform-specific unsigned integer)
• float (platform-specific floating point)
• char (8-bit unsigned integer)

• pointer
• function pointer
• array (not pointer; statically declared dimensions)
• array pointer (pointer to array plus length)
• struct (as in C)
• union (as in C, but no overlapping of pointers)
• tuple (like structs, but with unnamed members)
• volatile (as in C)
• atomic (use atomic instructions to access the variable)
• enum (as in C, but typed)
• set (as in Pascal)
• endianess type.

• constant (a non modifiable memory location)
• logical union (algebraic type)
• value (for avoiding invalid constant value mixing)
• range (from .. to)
• strong type (copy a type to another type)
• state type (for avoiding invalid states)
• null
• cpu register (for accessing CPU registers)
• alias (as in C typedef)

typedef Point = {x:int, y:int};
typedef NullablePointPtr = @Point | null;

typedef VALUE1 = 0;
typedef VALUE2 = 1;
typedef VALUE3 = 0;
typedef VALUE4 = 1;
typedef foo = struct {
    x:VALUE1 | VALUE2,
    y:VALUE3 | VALUE4
};

typedef flip_flop = 0 => 1 => 0;

type EAX_INTEGER = EAX :> int32;
type EAX_UNSIGNED_INTEGER = EAX :> uint32;

• variables can be declared anywhere in a block, as in C++.
• the goto statements 'break', and 'continue' can have an optional label to indicate the jump target.
• switch cases do not need break; cases can accept multiple expressions.

• bitwise operations would have precedence over arithmetic operations.
• assignment would no longer be an expression; it will only be a statement; hence postfix ++/-- is no longer allowed.
• there is no implicit conversion from and to any type (to avoid type mixing problems).

var x : 10 .. 20 = 15;

fun main(args : string[]) : int {
    var y : int = 0;
    
    match (y) {
        case 10..20:
            x = y;
        other:       
    }
    
    return 0;
}

import foo.bar.cee, a.b.c, mymodules.myunit;

public:
var x : int = 0, y : int = 0;

private:
var data : @int | null = null;

protected foo.bar.cee, a.b.c:
var internals : char = 'a';

typedef POINT = {x : int, y : int};

fun main(args : string[]) : int {
    var p1 : @Point = new (0xfff0000) Point;
    var io1 : int8 = input (0x60) int8;
    var io2 : int8 = output (0x60) int8;
}

fun new() : @POINT {
    var buffer : byte[] | @POINT = alloc(sizeof(POINT));
    match (typeof(buffer)) {
        case typeof(byte[]):
			for(i : uint8 = 0; i < sizeof(POINT); ++i) {        
				buffer[i] = 0;    
			}
    }
    return buffer;
}