Bug finding game!

[cha0s]

Well, the last few days on compiler development has been implementing the const attributes for variables. I think it's doing pretty well, and I'd like people to test it... if you're up to the challenge =P.

This code works in latest SVN:

Code: Select all

type some_important
	as integer x, y, z
end type

type some_type
	
	as integer a, b
	
	declare constructor _
		( _
			byval x as integer = 1, _
			byval y as integer = 2, _
			byval z as integer = 3 _
		)
	
	declare function view_important( ) as const some_important ptr
	
	private:
	important as some_important
	
end type

constructor some_type _ 
	( _
		byval x as integer, _
		byval y as integer, _
		byval z as integer _
	)
	important = type(x, y, z)
end constructor

function some_type.view_important _ 
	( _
	) as const some_important ptr
	function = @important
end function

dim as some_type s

? s.view_important->x

'' illegal, can't modify that location
'' s.view_important->x = 0

'' illegal, the destination pointer has to be const
'' dim as some_important ptr si = s.view_important

var si2 = s.view_important
? si2->x

'' nothing magic, still illegal
'' si2->x = 0

sleep

Mangling should be compatible with c++ const parameters, I haven't done much testing there though, I think v1ctor has. Any issue you find, please just report them here instead of the tracker for now.

Thanks!

[voodooattack]

here's a very weird one.. :)

Code: Select all

    sub t (byref arg as const string)
        print trim(lcase(arg))
    end sub
    
    t(" hi ")
    
    'output should be:
    'hi
    
    'output is:
    '0
    
    sleep

Edit: it worked when i changed the byref to byval, however, here's what i get when try to compile this:

Code: Select all

    sub e (byval arg as const string)
        print trim(lcase(arg))
    end sub
    
    sub t (byval arg as const string)
        print trim(lcase(arg))
        e(arg)
    end sub
    
    t(" hi ")

test3.bas(7) error 159: Invalid assignment/conversion, at parameter 1 (arg) of E() in 'e(arg)'

[Ryan]

If you don't mind me asking... what's the use of the const attribute? I've noticed this in several places while working on porting this MUD code, and I don't get why you'd have to use it... couldn't you just make sure your doesn't modify the value?

[notthecheatr]

Mostly, it makes your code cleaner I think. Most OOP features (protection, especially) are not really NEEDED per se, but they sure do simplify things.

[Deleter]

couldn't you just make sure your doesn't modify the value?

And couldn't you just manually make sure you don't make any typos and allow the compiler to make new variables for every different letter combination? And couldn't you just make everything public in types and make sure only the proper methods modify the variables?

The point is that not only does this ensure that you will use things correctly, but every bloke down the road who is going to look at your code also has to follow the same rules or else consciously break them. If you don't care for the future of your code and prefer to keep things straight in your head then go ahead and look over this command. However it is a sensible command and serves a definite purpose in the world of coding, and I am glad to see freebasic adopt it.

[VirusScanner]

I think one of the main reasons is C++ compatibility. FB aims to be as close to compatible as possible with GCC/G++, and since most well-written C++ libraries use the const attribute (and it is a part of the mangling), it is needed.

[coderJeff]

In simple terms, a CONST qualifier is a declaration of what the code promises to do ( actually, not to do ) with a variable or argument. Because the declaration is explicit, the compiler can check to see that the programmer keeps that promise ( usually ). And as VirusScanner points out, porting any C++ header is pretty much impossible without CONST qualifiers.