Zereo wrote: |
---|
I believe you can unsubscribe from this topic to remove it from your topics not sure though. |
Yes, they are update news. Some of this are questions really.
I personally agree with you, it is better if the feature you mentioned above is added (as soon as possible) (Just because they may make you annoyed if you don't like :))
And also like
naraku9333 said before, making a blog is a good idea, but I think just about one, or two weeks later, my first child debug version will be released...
Once again, I am sorry.
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
The question, "
What is the problem which causes the parser accesses small variables (such as char, short) very slowly?" Is my algorithm ok? It seems my function needs a lot of improvements.
The important question about function : What do you think about special type-cast level 3?
Wow, it's hard to explain. Let's say :
LEVEL 1 : The parser casts type for a new member immediately after a new member value is successfully inserted.
Example :
true + '0' + 100 + 100.0f + 100.0
The following variables above will be added with its type-cast :
-
true : boolean
-
100 : int
-
100.0f : float
-
100.0 : double
LEVEL 2 : The parser browses all members, chooses the best suit type, then uses its general
type-cast to handle and perform its calculation.
true + false + '0' - [int] false - false
The parser has to calculate this expression above, it uses
type-cast information to convert the final value of the calculation to a correct value before ending the algorithm.
-
true :
current_type = boolean
-
false : (boolean == boolean) -> boolean
-
'0' :
(boolean < char) ->
type = char
-
[int] false :
(char < int) ->
type = int
-
false :
(int > boolean) -> int
The value is
49, and the final value is
(int) 49
=
49
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
LEVEL 3 (I think it only works with functions) :
The parser will use one sign symbol to control the automatic type-cast browser. That means users can set quickly their own general type-cast for a series of parameters at a time; decide what type of the final value that people should look.
-
Syntax : [#parameter_list]
- Example : [#idci] (int, double, char , int)
To be more detailed, consider this :
var = pow (2.0 , 3.0);
As you can see, both
2.0; 3.0 are double. The function has two parameters with total
16 bytes stack. Normally you may write :
var = pow (2 , 3); // They are int
Or even the example :
var = pow (true , 'a'); // boolean, char
Still works correctly... why?
Just because C++ has a powerful type-cast feature. It searches available function templates for parameter information and then uses them to cast the input values to correct values before calling without causing any problem.
With two examples above, simply the compiler replaces the value with :
double pow (double, double);
var = pow ((double)2 , (double)3);
var = pow ((double)true , (double)'a');
But about my interpreter? No function templates, then how can the interpreter know what you are doing? It doesn't know how to cast a parameter value. Simply push, pop, then a crash error begins... :(
Problem example :
var = pow (2 + 2 , 3.0);
"2 + 2" is an int; 3.0 is a double ->
Two parameters with 12-bytes stack (It should be 16)
So if you don't know what you are doing, your program will always be in danger when it calls a function.
If you know the syntax :
1 2
|
int value = 10,
value = pow([double]value, 2.0)
| |
Then no problem. But only forgetting the
[double] :
1 2
|
int value = 10,
value = pow(value, 2.0) //It collapses the program anyway!!!!!!!!
| |
Therefore now, here is the first solution :
The first solution simply is using the basic type-cast feature.
var = pow([double]2, 3.0)
You are allowed to comment inside the bracket with
"_"; if the comment is not a expression. It's convenient, but in some cases it may make you confused if you have to handle a complex expression, in my opinion it looks very ugly.
var = pow([double](3 + 4 + (3 * 15)), [double]2)
And I decided; my opinion - idea is using the symbol "#" to quickly solve the problem.
An example solution :
var = pow([#dd]6, 2.0f)
After
# sign there are two special characters.
This tells the first character (first parameter) where it stands it's a double, and also the second character says it must be a double value.
-
First character -> First parameter :
double
-
Second character -> Second parameter :
double
So it's equivalent to :
var = pow([double]6, [double]2.0f)
Another example :
var = func([#iicdf]10.0f , 20, 30.00, 40, 50)
The first character (first parameter) must be an int, the second also is an int, the third character now is a char, the forth character says it's a double, and the last character holds a float.
So it's equivalent to :
var = func([int]10.0f, [int]20, [char]30.00, [double]40, [float]50)
What you do think about this idea? Any opinion, improvement or suggestion? : )