Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Author
Message
Mike Johnson
TGC Developer
21
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 21st Jan 2011 11:02
There was an interesting discussion in the main Commands thread about variables and how they are declared. Originally in DB Pro it would work like this:

age = Str$( 100 )
height# = Val( "104.6" )
name$ = "Bill"

An alternative and much cleaner method is this:

age = String( 100 )
height = Float( "104.6" )
name = "Bill"
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 21st Jan 2011 11:36 Edited at: 21st Jan 2011 11:37
What about:

age = str(100)
height = val("104.6")
name = "Bill"

(This seems a nicer way than either of those ^ )

I'd be against using string as a function name as well as a variable type definition. It could get confusing for writing help files and newer people may not be able to tell the difference between string(var) and var as string

baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 21st Jan 2011 12:11
I'd say leave the options in. Sometimes it helps to be obvious with your code. I guess it also depends on whether we are making people define their variables?

Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 21st Jan 2011 12:20
Personally I use the second method all the time by explicitly declaring my (global or local) variables beforehand:

global age as integer = 100
global height as float = 104.6
local name as string = "Bill"

So not having to do that would be a bonus.

knxrb
FPSC Tool Maker
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: United Kingdom
Posted: 21st Jan 2011 12:26 Edited at: 21st Jan 2011 12:28
I personally think that it would be good to have a single variable type that contains anything with the engine processing what it is as well as the integer, float and string types.

For example:

And the above would then show this on-screen:
Hello There.
58
42.3
Back to text again!


The idea is that the variable can contain anything and the system converts it automatically from string to integer or decimal and vice versa.
This just means you don't have to waste time converting variables with things like 'str$()' and 'val()', the engine should do it for you.

Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 21st Jan 2011 12:30
@knxrb
Not a good idea!

If I do this:
a = "123"
b = "456"
c = a + b

What should c be?
"123456"
579
Is c a string or in integer?

baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 21st Jan 2011 12:34
I would have thought by using "" you are implicitely defining both as strings so the answer is "123456"...

Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 21st Jan 2011 12:35
The point I was making is: I might want and expect the answer to be 579. With knxrb's method there is no way to do that.

baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 21st Jan 2011 12:42
I don't think it's possible anyway as variable types are likely to remain the same once defined. I imagine there'd be an exception thrown if you tried to change the type.

I guess I'm saying that implied variable type definition might be nice. If you define a type as:
x=1.0 it would assume a float
x=1 it would assume an integer
x="1" it would assume a string

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 13:00
In the last few years I've used a language based on knxrb's method. It was frankly liberating - but I'm not convinced it's suitable for a language beginners might use. For example, the following code would be perfectly acceptable:



In that snippet the object "a" would in turn be three different things, a float, a string and finally an integer. It's up to the programmer to do sensible things with those objects. If you've finished with the current object "a" you can just replace it with a new one defined by whatever is on the right-hand side of the assignment.

When you get used to it, it is a tremendous step forward.
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 21st Jan 2011 13:03
Variants appear in many languages, can be handy, can be slow and clunky also.

dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 21st Jan 2011 13:06
Quote: "What about:

age = str(100)
height = val("104.6")
name = "Bill""


What's the difference between str() and string(), besides the user having to learn twice as much? And 'val' is very unclear about what type it is being cast to, it could be an integer/float/double float, having Integer(), Float(), DoubleFloat(), DoubleInteger() etc solves all these issues and remains consistent with the 'a as Integer' syntax.


Quote: "I personally think that it would be good to have a single variable type that contains anything with the engine processing what it is as well as the integer, float and string types."


This is an easy way to write code that breaks, and the IDE would be unable to tell you what type anything is.

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 13:17
Quote: "This is an easy way to write code that breaks, and the IDE would be unable to tell you what type anything is."


That's what I thought till I tried it. And it isn't true of course.

If you try to add a string object and an integer object then you get an incompatible type error. Simple.

If you define a variable to be a string then, guess what, it's a string. The compiler would know that and give you a warning if you tried to use it as an integer or whatever.
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 21st Jan 2011 13:23
What if for example:


Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 13:25
Of course - for the reason you've given.
bitJericho
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 21st Jan 2011 14:12 Edited at: 21st Jan 2011 14:13
Quote: "age = String( 100 )
height = Float( "104.6" )
name = "Bill""


Yeah, I don't mind that.

I like declaring my variables with things like height AS FLOAT

[center]
Join the TGC Group!
http://tehcodez.groups.live.com
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 21st Jan 2011 14:50
TBH, I wasn't quite sure what Mike meant with this post - I understand why everyone has determined that he meant variable declaration, but is that the case? Is he suggesting that the variable type is automatically set by the first assignment that the compiler sees?

Anyway, I'd like for force variables to be declared before use (at the very least, a compiler mode switch to enable it).

I'm also happy with the current '<var> AS <type>' format, as that deals with UDT's too, which this doesn't.

Also, I'm against having typeless or variant (dynamically typed) variables - conversion from one to another can be a problem, not only as previously noted by earlier posters, but also when including UDT's, and potentially arrays and (very unlikely to appear) anonymous functions too.

TBH, I'm fairly happy with DBPro's loosely-typed static variable method as it is. I'm not convinced it needs to change (except maybe to loosen up the initial assignment to allow them to be set from other variables).

thenerd
15
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 21st Jan 2011 15:36
Quote: "I'm also happy with the current '<var> AS <type>' format, as that deals with UDT's too, which this doesn't."

I agree, something like this:
variable1 as integer = 10
variable2 as float = 100.2
variable3 as string = "Bill"

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 21st Jan 2011 16:07 Edited at: 21st Jan 2011 17:16
I agree that you should have to declare variables before use, and with using the type name to do conversion.

For a reason why, just try converting an integer to a float without declaring an extra pointless variable.

DBPro


That only simple way to convert to a float is to add 0.0 or multiply by 1.0.

Alternative for AGK


The second makes much more sense to me!

[b]
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 16:31
In those snippets is "result" supposed to be a float or an integer?

If you mean it to be a float then I agree the second is better.
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 21st Jan 2011 17:17
Fixed

[b]
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 21st Jan 2011 18:09
These last few posts are the reason why I was questioning what Mike meant.

A conversion function that has the same name as the type it is converting to is a good idea, but shouldn't be needed for every conversion (eg, WORD to DWORD or INTEGER should be automatic)

Mike Johnson
TGC Developer
21
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 21st Jan 2011 21:03
The main thing I'm wanting to do is to open the topic for discussion, as it's really helpful for us to get valuable feedback and understand what people are looking for. In general looking for ideas on how you think variables should be declared and handled.
Fatal Berserker
13
Years of Service
User Offline
Joined: 2nd Jul 2010
Location:
Posted: 21st Jan 2011 21:40
Quote: "age = str(100)
height = val("104.6")
name = "Bill"""


id FAR rather:

string age = "100";
double height = 104.6
string name = "Bill";

Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 21st Jan 2011 21:45
I really don't like the none specific declaration.

I would be happy with:

integer age = 100;
float height = 104.6
string name = "Bill";

or

age as integer = 100;
height as float = 104.6
name as string = "Bill";

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 21st Jan 2011 21:51
I agree, but I also think we should be able to use the type name to convert to that type. At the moment, DBPro is probably the only language where you CAN'T explicitly cast one type to another.

VB for example has the CType() function which converts from one type to another if possible, but IMO it makes more sense to just use the type name directly.

[b]
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 22:00
Quote: "At the moment, DBPro is probably the only language where you CAN'T explicitly cast one type to another."


Yes, that is often annoying.

Quote: "but IMO it makes more sense to just use the type name directly"


Yes.

For declarations I also agree with Scraggle.
LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 21st Jan 2011 22:17
Sounds like most of you guys are happy with:

<var> as <type>

I do find it useful when coding a prototype very quickly to skip the declaration step and charge into coding the logic. Are we all happy with allowing compiler (under a compiler option) to allow variables to be used with being declared, i.e.:

A=10
B=20
C=A+B
PRINT C

Quick to type and run. And then you can go into the compiler preferences and tick a box 'variable declaration required', which means the same program would produce an error 'A is not declared', to which the solution would be:

A AS INTEGER = 10
B AS INTEGER = 20
C AS INTEGER = A + B
PRINT C

or

A AS INTEGER
B AS INTEGER
C AS INTEGER
A=10
B=20
C=A+B
PRINT C

The reason I am against variant types is that it's a performance hit, and I want AppGameKit to be as fast as possible, which means the run-time needs to know what the variable type is well in advance.

Keep the dialog going, as we have the time to make these determinations to ensure we get a good result.

I drink tea, and in my spare time I write software.
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 22:19
Good points Lee.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 21st Jan 2011 22:45 Edited at: 21st Jan 2011 22:46
@Lee,
I do believe that I agree with you
The only choice left to make on what has already been discussed is whether auto-creation of variables is the default or not.

Now onto other related 'Variables' topics . Variable types in particular:
- Pointers to type.
Probably out of the question, due to cross-platform issues, but I'll throw it on the table. Not sure what use it would be in the locked-down world of 'small-devices' anyway.

- Reference types.
BYREF as a modifier to function input types:


Function return values should only ever be returned by value, not by reference (otherwise we'll have people complaining that the stack has been corrupted when they return a reference to a local stack variable and then update it).

If BYREF input variables are allowed, that mitigates against the need to allow UDT's to be returned (although that would be good too).

- arrays
Passing arrays to functions - allow them to be passed only BYREF (or force that for arrays) and I'll be happy. I'm sure others will be too, as long as the functionality is included to interrogate the structure of the array.

On that subject, how about considering this form of array creation?:


That should be enough 'dialog' to start with

LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 21st Jan 2011 23:05 Edited at: 21st Jan 2011 23:06
[Lee closes eyes and puts hands over ears] I do like this approach, and I don't think Dim ( Lee[100] ) As Integer looks right somehow. I do agree Lee As Array Of Integer[10,10] looks better, but I will be sad to see DIM and UNDIM go. Does this mean I don't have to do dynamic arrays Maybe we just drop the bracket for the Dim, so it would be:

Dim lee[10,10] As Integer

I drink tea, and in my spare time I write software.
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 23:09
Why not simply



What useful purpose does the extra "Dim" serve?
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 21st Jan 2011 23:35 Edited at: 21st Jan 2011 23:36
I would prefer this syntax myself:


It's a bit more compact, and I think it's just as readable.

Arrays should still be dynamic, so we would need a way to resize them, but the number of dimensions would be defined at compile time.

[b]
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 21st Jan 2011 23:55 Edited at: 21st Jan 2011 23:56
The concept is fine, but to rely on the number of commas in the function definition seems a little unlike BASIC (one less comma than the number of dimensions). It makes it hard to fix from a search/modify point of view if you change the number of dimensions, and I agree my suggestion has the same problem.

Also, I too am not aware of anyone changing the number of dimensions during run-time.

@GG,
I agree, but there's the issue that DIM serves another purpose beyond allocating memory - it signals to the programmer that something different than normal variable declaration is happening, for example that an array is global by default. It's something to consider at least.

@Lee,
If you put your hands over your ears, I'm just gonna SHOUT LOUDER!

Quote: "Does this mean I don't have to do dynamic arrays"

Oh no, I'm pretty sure we don't want that.

We do need some way to dynamically grow storage - you have to at the very least allow us to drop existing array storage and to allocate a new array of a different size (Ok, you don't, but you'll upset a lot of people if you don't).

I'd like to be able to manipulate arrays as if they were normal variables too:

(I'm not attached to the syntax, just the idea is nice - the above also implies reference-counted array storage)

Also, you didn't comment on my BYREF suggestion...

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd Jan 2011 00:16
The problem with that method is when it comes to UDTs within arrays. What would happen if you did this:



Assuming you're using reference counting to see when an array's data should be freed, you will end up with a circular reference.

[b]
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 22nd Jan 2011 00:19 Edited at: 22nd Jan 2011 00:21
Simple - don't allow self-references within types
It's currently disallowed by DBPro, and I see no reason to allow it.

[quick edit]
I've suddenly realised, thanks to your example code, that allowing dynamic arrays within UDT's allows us to create tree-like structures! Wicked! Who the heck needs pointers!

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd Jan 2011 00:29 Edited at: 22nd Jan 2011 00:32
But we can only make true tree structures if we allow self references within types

edit:
BTW, I don't like the way you have to use both "array of ..." and "[]" at the end to declare an array type. Surely it should be one or the other, not both?

[b]
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 22nd Jan 2011 00:39
Doh! Ok, so now I see a reason to allow it.

I was just trying to avoid suggesting a system that required a proper garbage collection system, or the programmer to break the self-referencing structure manually.

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 22nd Jan 2011 00:55 Edited at: 22nd Jan 2011 00:57
I don't like the sound of this:



It's far simpler and less error prone if the statement



merely means that SecondArray is another array having the same values as FirstArray. Then it's just one more step for real array arithmetic like



If different names can point to the same memory things can get very confusing as changes to one will affect the other. I've never yet successfully written anything bug-free in such languages and if allowed it wouldn't resemble BASIC at all.

Or have I misunderstood you (yet again )?
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd Jan 2011 01:04 Edited at: 22nd Jan 2011 01:05
You know, maybe instead of making it complicated and having self referencing types, etc. there could be a built in tree data type, just like we have a built in array data type?

It would simplify things considerably. No need for complicated memory management, best possible speed because it is implemented natively, best ease of use because it's been specifically designed for the task rather than emulated using arrays.

You would declare it just like an array but with the tree keyword. Each node in the tree would be a tree itself. Instead of allowing any type to reference itself, you choose one built in type which has this ability, and write an implementation specific to that one type.

Example, not sure about the set/get to change the data but can't think of a better syntax atm.


[b]
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 22nd Jan 2011 01:28 Edited at: 22nd Jan 2011 01:29
Actually, the whole tree idea needs a rethink - without some sort of pointer, how can you get to the n'th level of the tree? It's a bit cludgy, but with arrays-as-references, you can grab a reference to the array at the current level and follow it down another level, repeating until you get to where you were heading.

Nah, needs more thought.

@GG,
Yet most languages do pass around arrays (and more) as references, not copies, and don't have problems.

The problem with copying arrays is that they take time, and they take up extra memory, which is OK if you actually want a copy, or are dealing with small arrays, but not if you want to pass an large array to a function, or swap two or more large arrays (Remember: Small devices).

Anyway, as I said, I'm not attached to the syntax, and everything here is up for discussion (or not: Lee may be saying to himself 'it'll be a cold day in hell before I implement that pile' right now).

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd Jan 2011 01:42 Edited at: 22nd Jan 2011 01:48
Internally a tree would be a pointer, just like an array, so if you assign one tree to another, the variable just points to a place in the other tree rather than copying any data. You can easily get to any depth you want this way.

Managing memory is simple. Each group of tree nodes has a single reference count shared by all the nodes. When a variable is assigned to one of the tree nodes in the group, the reference count is increased, and when something replaces it, it is decreased. When it reaches zero the entire tree is freed, including all the data attached to it.

There is no more complexity than this because the user can't just move one branch of a tree to another (as all "tree" types are references).

I suppose you would have to limit it so that the data in a tree can't include a tree itself, as that would defeat the point.

Example of getting the Nth level in a tree:


Alternatively, this might be a better syntax to access the data on a tree.


I'm actually starting to quite like this syntax.

[b]
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 22nd Jan 2011 01:47
Strongly typed languages make debugging code easier. Not declaring variables initially with a specific type that doesn't change is bad practice and can lead to bugs that are difficult to detect.

I really hate the way you can just magically create a variable by referencing them in DBP and I hope you don't go down that route.

If you look at C's syntax: everything there has been done for a reason. Then look at Java, they've looked at C and tried to improve it further; notice that nearly everything is the same syntactically. I think in general its a safe bet to mimic C, it includes tried and tested industry standard practices.

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 22nd Jan 2011 02:02
Quote: "Yet most languages do pass around arrays (and more) as references, not copies, and don't have problems."


I don't see the point if they refer to the same memory - except in the context of passing parameters to functions of course. The languages I've used enable me to work on a copy without disturbing the original - essential if the original is to be re-used. To take DBPro as an example, a bitmap is effectively a 2 dimensional array and we have copy bitmap bmp1 bmp2. Why should arrays be treated differently?

Quote: "The problem with copying arrays is that they take time, and they take up extra memory, which is OK if you actually want a copy, or are dealing with small arrays, but not if you want to pass an large array to a function, or swap two or more large arrays (Remember: Small devices)."


Maybe - but surely it's the programmer's responsibility to work within the hardware constraints? Also, isn't it better to have optimised arithmetic for arrays rather than cumbersome nested for/next loops written by the programmer?
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 22nd Jan 2011 03:31
Quote: " To take DBPro as an example, a bitmap is effectively a 2 dimensional array and we have copy bitmap bmp1 bmp2. Why should arrays be treated differently?"


Because passing structures by value is way too slow, since the passed resource needs to be copied.

By value is acceptable for simple data types, but performance killing for anything bigger.

tiresius
21
Years of Service
User Offline
Joined: 13th Nov 2002
Location: MA USA
Posted: 22nd Jan 2011 06:18
Should the defined variables require or utilize the usual # and $ postfix somehow? I find them helpful when looking through long listings or accessing fields within a UDT, I know exactly what type of variable it is.

type Me
hp as integer
speed# as float
name$ as string
endtype


A 3D marble platformer using Newton physics.
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 22nd Jan 2011 06:29 Edited at: 22nd Jan 2011 06:44
@IanM

I would prefer the 'as reference' modifier to 'byref', i.e.



Sure it makes the code rather long, but I think it's best to avoid abbreviations when dealing with things the user cannot rename, and makes it more apparent what's going on. Plus, most of the time the user won't even want references, so the average code should remain unchanged.

I also think all data types should be passed as a copy by default, I'm aware that many similar languages pass almost everything by reference, but this can be incredibly confusing without any 'const' system. If everything's a copy by default then the system would remain more consistent and there would be far less beginners making code that breaks. The worst that happens is that people write slow code, but find they can fix it by adding 2 words, I think the trade off is better.


I also don't see the problem with allowing variable declaration by assignment as shown in the OP, i.e. 'a as integer' would be identical to 'a = 0'. Otherwise 'for i = 1 to 10' would be an exception, and I don't think integers should be some magical special case.


As for arrays, I'm leaning toward removing the ability to define their size on definition, because it means there would be a syntax difference between declaring one and declaring one as a function argument.

Something like this seems clearer:



I don't think there should be a way to discriminate the amount of dimensions or the size of the array when passed to a function, because that would require arguments be formatted like: 'a as Array of Float[,,]', which doesn't seem very consistent with anything else in the language, i.e. there is no ability to call functions with 'plop(,,)' to use default values or something, so why should arrays be any different?

Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 22nd Jan 2011 06:33
Regarding passing by reference I'd be happy with an 'out' modifier before the identifier.

Either way, passing by reference is absolutely essential for writing modular code, so I urge you guys to support it even if only for arrays.
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd Jan 2011 11:17
I would prefer "byref", "ref" or "out" before the parameter. It's shorter, and it's still obvious what's going on.

[b]
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 22nd Jan 2011 12:08
Quote: "Because passing structures by value is way too slow, since the passed resource needs to be copied.

By value is acceptable for simple data types, but performance killing for anything bigger."


But if you want a copy, how do you suggest we do it? Not by cumbersome for/next loops surely? I agree simple copies should be avoided if possible for large arrays but if you are processing arrays then it's highly desirable to have efficient ways provided by the language rather than potentially inefficient ways provided by the programmer.

Also, if a programmer finds that their array copies slow things up too much then they should think about doing things differently. Why make it impossible for them to make a copy efficiently via the language for those occasions when it works?

Login to post a reply

Server time is: 2024-04-19 05:54:03
Your offset time is: 2024-04-19 05:54:03