1.05.0
-
- Posts: 606
- Joined: Nov 28, 2012 1:27
- Location: CA, USA moving to WA, USA
- Contact:
1.05.0
Thank you for the new build.
Re: 1.05.0
thank you dkl :)
-
- Posts: 1002
- Joined: Nov 24, 2011 19:49
- Location: France
- Contact:
Re: 1.05.0
I can't wait to test it. :)
Re: 1.05.0
@dkl,
thanks for the new Release.
To highlight one of the Fixes, in the FBC 1.05 x64 Release, Line Attribute:
In all previous x64 Versions, above was broken (x32 Versions NOT affected!).
thanks for the new Release.
To highlight one of the Fixes, in the FBC 1.05 x64 Release, Line Attribute:
Code: Select all
WindowTitle "LineAttr.exe -- FBC 1.05 WIN64"
ScreenRes(800,600,32)
' Line Attributes was brocken in prev. 64 bit Versions of FBC
Line ( 50, 50)-(700, 500), &hFFFF0000, B, &h8888 ' attr: Short (16bit)
Line (150, 150)-(750, 550), &hFFFFFF00, B, &hFFFC ' HEX or Bin Definition
Line (100, 100)-(650, 450), &hFF0000FF, B, &hCFFC
Line (225, 225)-(575, 375), &hFF00FF00, B, &hCCCC
Draw String (312, 297), "Press any Key to QUIT!"
Sleep : End 0
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: 1.05.0
@dkl something new in scope of image memory allocation ?
in FBImage http://www.freebasic.net/forum/viewtopi ... 14&t=24105
I use malloc and ImageDestroy() works fine on windows 32/64-bit but not on Linux ?!?
Joshy
in FBImage http://www.freebasic.net/forum/viewtopi ... 14&t=24105
I use malloc and ImageDestroy() works fine on windows 32/64-bit but not on Linux ?!?
Joshy
Code: Select all
FBImage* DLL_EXPORT LoadRGBAFile(const char * filename){
int w,h,c,dpitch,spitch;
FBImage* img=NULL;
if (filename==NULL) {
result_string_pointer="Image load failed no filename !";
return NULL;
}
unsigned char* p = stbi_load(filename,&w,&h,&c,4);
if (p==NULL){
result_string_pointer = stbi_failure_reason();
return img;
}
spitch = w*4;
dpitch = spitch+15;
dpitch = dpitch & 0xFFFF0;
img = malloc(32+h*dpitch); // <--- !!! height x pitch + 32 bytes header !!!
img->image_hdr = 7;
img->image_bpp = 4;
img->image_w = w;
img->image_h = h;
img->image_p = dpitch;
unsigned char * s = p;
unsigned char * d = (unsigned char*)img;
d+=32;
doimg(d,s,dpitch,spitch,w,h);
free(p);
return img;
}
Re: 1.05.0
No, there were no changes since 1.04.0 in that area.
However a long time ago the image allocation was changed to put the buffer pointer at image[-1] (so the image ptr is 16-byte aligned, with the original ptr stored in front).
https://github.com/freebasic/fbc/blob/m ... mage.c#L96
Does your code handle that?
However a long time ago the image allocation was changed to put the buffer pointer at image[-1] (so the image ptr is 16-byte aligned, with the original ptr stored in front).
https://github.com/freebasic/fbc/blob/m ... mage.c#L96
Does your code handle that?
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: 1.05.0
dkl you are right I must fix it.
I wonder me that ImageDestroy does not crash on Windows but gives a segfault on Linux.
How ever thank you for the right link.
Joshy
I wonder me that ImageDestroy does not crash on Windows but gives a segfault on Linux.
How ever thank you for the right link.
Joshy
Re: 1.05.0
Hi,
This class can not inherit.
Result: error 201: Illegal member access, Foo.operator.let
The derived class is copying the object of the base class internally. Why?
Thanks,
This class can not inherit.
Code: Select all
type Foo
public:
declare constructor()
declare destructor()
...
private:
declare operator let(byref as const Foo)
...
end type
The derived class is copying the object of the base class internally. Why?
Thanks,
Re: 1.05.0
It could be in the implicit copy constructor or Let operator. If the derived class does not declare the Let operator, the compiler will generate one automatically, which calls the base's Let operator.
The reason for this is that if the base class has a Let overload, then the derived class must have one too, otherwise assignment would be broken: the base's Let operator wouldn't be called when assigning objects of the derived class.
The reason for this is that if the base class has a Let overload, then the derived class must have one too, otherwise assignment would be broken: the base's Let operator wouldn't be called when assigning objects of the derived class.
Re: 1.05.0
So the Let operator of the base type must not be private but protected or public.
Example demonstrating this behavior:
Example demonstrating this behavior:
Code: Select all
type Foo
public:
declare constructor()
declare destructor()
protected:
declare operator let(byref as const Foo)
private:
dim as integer dummy
end type
constructor Foo()
end constructor
operator Foo.let(byref f as const Foo)
print "Foo.let(byref as const Foo)"
end operator
destructor Foo()
end destructor
type FooChild Extends Foo
end type
Dim As FooChild fc1, fc2
fc1 = fc2
Print
Dim As FooChild fc3 = fc1
Sleep
Re: 1.05.0
@dkl
@fxm
The compiler generated the error because of the derived class has no the copy assignment operator.
I'm thinking about creating a non-copyable class like the following code in C++, but there is not a meaning. The derived class must explicitly implement a Let operator as private member, mmm...
BTW, I think that FB needs to have class qualifiers, such as STATIC, FINAL(or SEALED).
Those implementation is difficult?
Thank you for the answers.
@fxm
Now I get it!The reason for this is that if the base class has a Let overload, then the derived class must have one too, otherwise assignment would be broken: the base's Let operator wouldn't be called when assigning objects of the derived class.
The compiler generated the error because of the derived class has no the copy assignment operator.
I'm thinking about creating a non-copyable class like the following code in C++, but there is not a meaning. The derived class must explicitly implement a Let operator as private member, mmm...
Code: Select all
class noncopyable {
protected:
noncopyable() {}
~noncopyable() {}
private:
noncopyable(const noncopyable&);
const noncopyable& operator=(const noncopyable&);
};
Those implementation is difficult?
Thank you for the answers.
Re: 1.05.0
I downloaded the latest daily build 03-27-2016: 1.06.0
Is the keyword "__FB_MIN_VERSION__" about to go extinct?
Command executed:
"C:\FreeBasic\fbc.exe" "C:\fb_01\FBIDETEMP.bas"
Compiler output:
C:\fb_01\FBIDETEMP.bas(639) error 41:
Variable not declared, __FB_MIN_VERSION__ in 'print "fb min version: "; __FB_MIN_VERSION__'
Results:
Compilation failed
System:
FBIde: 0.4.6
fbc: FreeBASIC Compiler - Version 1.06.0 (03-27-2016), built for win32 (32bit)
OS: Windows XP (build 2600, Service Pack 3)
It is not a serious problem; just wondering.
Is the keyword "__FB_MIN_VERSION__" about to go extinct?
Command executed:
"C:\FreeBasic\fbc.exe" "C:\fb_01\FBIDETEMP.bas"
Compiler output:
C:\fb_01\FBIDETEMP.bas(639) error 41:
Variable not declared, __FB_MIN_VERSION__ in 'print "fb min version: "; __FB_MIN_VERSION__'
Results:
Compilation failed
System:
FBIde: 0.4.6
fbc: FreeBASIC Compiler - Version 1.06.0 (03-27-2016), built for win32 (32bit)
OS: Windows XP (build 2600, Service Pack 3)
It is not a serious problem; just wondering.
Re: 1.05.0
Hi,
It needs some parameters, see documentation.
print __FB_MIN_VERSION__(0, 18, 2) --> true or false
It needs some parameters, see documentation.
print __FB_MIN_VERSION__(0, 18, 2) --> true or false
Re: 1.05.0
THANK YOU.SARG wrote:Hi,
It needs some parameters, see documentation.
print __FB_MIN_VERSION__(0, 18, 2) --> true or false
I did not realize that the parameters were part of the keyword.
If the err msg had been "missing parameters" it would have been clear,
but "variable not declared", confused me.
Thanks for evaporating that fog.
Re: 1.05.0
Hi all,
just noticed a "funny" behavior, while using: OverLoad(ed) Function and an Array() As Const 'Type-Name' Parameter.
FBC Error: "no matching overloaded Function"
As soon as "Const" is removed, everything works as expected, is this intentional or a BUG?
The intention with Const was, to "write protect" the Array (inside of Function) ... without OverLoad: no Problem!
Testing Code here, modify the FileInfo Function(s) to test.
just noticed a "funny" behavior, while using: OverLoad(ed) Function and an Array() As Const 'Type-Name' Parameter.
FBC Error: "no matching overloaded Function"
As soon as "Const" is removed, everything works as expected, is this intentional or a BUG?
The intention with Const was, to "write protect" the Array (inside of Function) ... without OverLoad: no Problem!
Testing Code here, modify the FileInfo Function(s) to test.