Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Hi,

> which is the harbour recommended C compiler for the windows platform?

mingw (4.4), or msvc (2005 or upper).

[ these msvc versions don't support Win9x, if that's a concern. ]

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Maurilio Longo]

Viktor,

is mingw able to create stand-alone .EXEs and or .DLLs or does it require to
deliver some runtime code with them?

Best regards.

Maurilio.

Viktor Szakáts wrote:
> Hi,
> 
>> which is the harbour recommended C compiler for the windows platform?
> 
> mingw (4.4), or msvc (2005 or upper).
> 
> [ these msvc versions don't support Win9x, if that's a concern. ]
> 
> Brgds,
> Viktor
> 
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
> 

-- 
 __
|  |  | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

> is mingw able to create stand-alone .EXEs and or .DLLs or does it require to
> deliver some runtime code with them?

mingw in context of Harbour requires only standard msvcrt.dll.

(hbqt additionally requires mingwm10.dll, but it's an "issue" 
with QT)

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Maurilio Longo]

Smu,

what are the differences between mingw and dragon media?

Maurilio.

smu johnson wrote:
> It should be stated that the best one might be the one Harbour uses,
> which is not the official MinGW release, but Twilight Dragon Media's
> release, which is a build of a newer version of MinGW GCC.
> 
> On Tue, Mar 9, 2010 at 2:05 AM, Viktor Szakáts  > wrote:
> 
> > is mingw able to create stand-alone .EXEs and or .DLLs or does it
> require to
> > deliver some runtime code with them?
> 
> mingw in context of Harbour requires only standard msvcrt.dll.
> 
> (hbqt additionally requires mingwm10.dll, but it's an "issue"
> with QT)
> 
> Brgds,
> Viktor
> 
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org 
> http://lists.harbour-project.org/mailman/listinfo/harbour
> 
> 
> 
> 
> -- 
> smu johnson mailto:smujohn...@gmail.com>>
> 
> 
> 
> 
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour

-- 
 __
|  |  | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[smu johnson]

It should be stated that the best one might be the one Harbour uses, which
is not the official MinGW release, but Twilight Dragon Media's release,
which is a build of a newer version of MinGW GCC.

On Tue, Mar 9, 2010 at 2:05 AM, Viktor Szakáts  wrote:

> > is mingw able to create stand-alone .EXEs and or .DLLs or does it require
> to
> > deliver some runtime code with them?
>
> mingw in context of Harbour requires only standard msvcrt.dll.
>
> (hbqt additionally requires mingwm10.dll, but it's an "issue"
> with QT)
>
> Brgds,
> Viktor
>
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



-- 
smu johnson 
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[smu johnson]

TDM just released a newer version of GCC, while the official MingW site
releases and old version of GCC from the 3.x.x branch.  TDM is 4.4.1
currently.

On Tue, Mar 9, 2010 at 3:52 AM, Maurilio Longo wrote:

> Smu,
>
> what are the differences between mingw and dragon media?
>
> Maurilio.
>
> smu johnson wrote:
> > It should be stated that the best one might be the one Harbour uses,
> > which is not the official MinGW release, but Twilight Dragon Media's
> > release, which is a build of a newer version of MinGW GCC.
> >
> > On Tue, Mar 9, 2010 at 2:05 AM, Viktor Szakáts  > > wrote:
> >
> > > is mingw able to create stand-alone .EXEs and or .DLLs or does it
> > require to
> > > deliver some runtime code with them?
> >
> > mingw in context of Harbour requires only standard msvcrt.dll.
> >
> > (hbqt additionally requires mingwm10.dll, but it's an "issue"
> > with QT)
> >
> > Brgds,
> > Viktor
> >
> > ___
> > Harbour mailing list (attachment size limit: 40KB)
> > Harbour@harbour-project.org 
> > http://lists.harbour-project.org/mailman/listinfo/harbour
> >
> >
> >
> >
> > --
> > smu johnson mailto:smujohn...@gmail.com>>
> >
> >
> > 
> >
> > ___
> > Harbour mailing list (attachment size limit: 40KB)
> > Harbour@harbour-project.org
> > http://lists.harbour-project.org/mailman/listinfo/harbour
>
> --
>  __
> |  |  | |__| Maurilio Longo
> |_|_|_|| farmaconsult s.r.l.
>
>
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



-- 
smu johnson 
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Hi Maurilio,

> what are the differences between mingw and dragon media?

tdragon release is easy to setup/install, while mingw 
is extremely time-consuming and frustrating experience 
(and it doesn't get any better with newer versions).

tdragon was also more agile in releasing usable packages
(now at gcc 4.4.1), official mingw tend to wait years between 
releases (recently released 4.4.0, but was stuck at 3.4.5 
for many many years)

tdragon has sjlj default unwinding, with dwarf-2 as easy 
to install option, while official 4.4.0 is fixed to dwarf-2, 
previous releases fixed to sjlj. (important for QT in 
regards of Harbour). Note that dwarf-2 in tdragon has 
special tool postfix.

tdragon has a usable homepage, mingw has the most 
frustrating (and broken) homepage of all open source projects 
we have to interface with in regards of Harbour.

Besides unwinding, from a C programmers POV they seem 
pretty much identical, but I personally haven't done 
any side-by-side speed / executable size / etc comparison, 
theoretically they should be pretty close as well.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Maurilio Longo]

Viktor,

I had the same impression about mingw being a nightmare to install and make it
work.

I'll try dragon media :)

One more question, for harbour should I use sjlj unwinding or dwarf2?

Thanks.

Maurilio.


Viktor Szakáts wrote:
> Hi Maurilio,
> 
>> what are the differences between mingw and dragon media?
> 
> tdragon release is easy to setup/install, while mingw 
> is extremely time-consuming and frustrating experience 
> (and it doesn't get any better with newer versions).
> 
> tdragon was also more agile in releasing usable packages
> (now at gcc 4.4.1), official mingw tend to wait years between 
> releases (recently released 4.4.0, but was stuck at 3.4.5 
> for many many years)
> 
> tdragon has sjlj default unwinding, with dwarf-2 as easy 
> to install option, while official 4.4.0 is fixed to dwarf-2, 
> previous releases fixed to sjlj. (important for QT in 
> regards of Harbour). Note that dwarf-2 in tdragon has 
> special tool postfix.
> 
> tdragon has a usable homepage, mingw has the most 
> frustrating (and broken) homepage of all open source projects 
> we have to interface with in regards of Harbour.
> 
> Besides unwinding, from a C programmers POV they seem 
> pretty much identical, but I personally haven't done 
> any side-by-side speed / executable size / etc comparison, 
> theoretically they should be pretty close as well.
> 
> Brgds,
> Viktor
> 
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
> 

-- 
 __
|  |  | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Hi Maurilio,

> I had the same impression about mingw being a nightmare to install and make it
> work.
> 
> I'll try dragon media :)
> 
> One more question, for harbour should I use sjlj unwinding or dwarf2?

It only matters if you want to use HBQT. For 4.5.x 
you need SJLJ, for 4.6.x you need DWARF-2.

If you don't use HBQT, it just doesn't matter for 
Harbour.

Brgds,
Viktor


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Maurilio Longo]

Viktor,

if I read it correctly a dwarf2 .exe which loads a .dll which has an exception
inside itself cannot work, since you're traversing a stack frame which
receives an exception from windows. Am I right?

Maurilio.

PS. I've installed dragon media, smartsvn and I was able to build harbour on
win32 very smoothly.

Viktor Szakáts wrote:
> Hi Maurilio,
> 
>> I had the same impression about mingw being a nightmare to install and make 
>> it
>> work.
>>
>> I'll try dragon media :)
>>
>> One more question, for harbour should I use sjlj unwinding or dwarf2?
> 
> It only matters if you want to use HBQT. For 4.5.x 
> you need SJLJ, for 4.6.x you need DWARF-2.
> 
> If you don't use HBQT, it just doesn't matter for 
> Harbour.
> 
> Brgds,
> Viktor
> 
> 
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
> 

-- 
 __
|  |  | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Hi Maurilio,

> Viktor,
> 
> if I read it correctly a dwarf2 .exe which loads a .dll which has an exception
> inside itself cannot work, since you're traversing a stack frame which
> receives an exception from windows. Am I right?

I don't have academic answer for the unwinding topic, 
so locally I'm just avoiding any mixture (both static 
and dynamic) of these modes.

> PS. I've installed dragon media, smartsvn and I was able to build harbour on
> win32 very smoothly.

Good to hear, thanks for the positive feedback.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Massimo Belgrano]

I remember an intresting pritpal posting

Here are some results of 3 compilers:

MSVC 2008
  EXE SIZE: 6573 KB
  DIFFERENCE: Links one external lib statically ( www.dosadi.com )
  RUN:   PASS16.75 Secs
   PASS24.97 Secs
   PASS35.00 Secs

BCC 5.5.1
  EXE SIZE: 6706 KB
  DIFFERENCE: Links one external lib dynamically pulled via implib
  RUN:   PASS15.72
   PASS25.69
   PASS35.63

MINGW
  EXE SIZE: 8287 KB
  DIFFERENCE: Does not include above lib, does not include 2 .prgs 1 .res
  RUN:   PASS14.48
   PASS24.51
   PASS34.53

All above runs are on the same execution, i.e., moves a browser first to
last with 1408 recs.

Personal observation:
  * MINGW is the fastest though it has larger executable ( does not matter
).
  * MINGW has the limitation not to allow more than 1 resource files (
really a shame ).
  * MINGW is very tricky when you need Windows .dlls to be manipulated (
again a severe limit ).
  * BCC is handy to include any external lib because of "implib" utility
but slowest of all.

So one's choice may be affected by many factors.
Suggesstion: go for MINGW if you never plan to include more than one .RES
file and
  do not have to include external party Windows .DLLs without a MINGW
export by the author.
2010/3/9 Maurilio Longo 

> Hi,
>
> which is the harbour recommended C compiler for the windows platform?
>
> best regards.
>
> --
>

-- 
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

> Personal observation:
>   * MINGW is the fastest though it has larger executable ( does not matter
> ).

MSVC is the fastest, closely followed by MINGW.

>   * MINGW has the limitation not to allow more than 1 resource files (
> really a shame ).

This is not true.

>   * MINGW is very tricky when you need Windows .dlls to be manipulated (
> again a severe limit ).

I can't comprehend this statement. MinGW is 
no trickier than any other C compiler. In fact  
it has extra features which makes it much easier 
to work with .dlls and "implibs". It's not a limit, 
but a difference in usage, and after you "got" it, 
it's even simpler than implib tools.

>   * BCC is handy to include any external lib because of "implib" utility
> but slowest of all.

BCC is a joke these days. IMPLIB is buggy 
and not fixed since 10 years. It has almost 
non-existent 3rd party support. It's only 
useful for draft builds because of fast 
compile time and because it emits one type of 
useful warning which other compilers don't.

BTW MinGW also supports 64-bit and ARM 
targets (requires different binary distros).

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[francesco perillo]

> BCC is a joke these days.

ooops... I have a production site working with a bbc version of Harbour...
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

>> BCC is a joke these days.
> 
> ooops... I have a production site working with a bbc version of Harbour...

Well, it does work, it just has limited capabilities 
compared to other compilers. If you don't need those 
capabilities, you might be okay with bcc. Though at 
least if runtime speed is a concern, you may want to 
try something else.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Przemysław Czerpak]

On Wed, 10 Mar 2010, francesco perillo wrote:

Hi,

> > BCC is a joke these days.
> ooops... I have a production site working with a bbc version of Harbour...

It works but it's not very good choice.
There are some very serious bugs in BCC but for the ones known for us
we have workarounds, i.e. we do not use any floating point BCC low level
functions like _fpclass[l]() because they break 'double' number
calculations reducing the precision to 'float' level or we use
DLMALLOC as default memory manager because the one in BCC can cause
memory corruption in some situations.
But more important is the fact that BCC was not extended in last years
and now in comparison to other modern C compilers it does not have many
important features and optimization methods.
In contrast nearly each new GCC version has some important extensions
which improve optimization code and performance of final applications,
i.e. GCC 4.4 generates nearly twice faster code then 2.9x. (see results
below).

Harbour core code is written in a way which should help in optimization
process for compilers using some advanced optimization methods like
automatic autoinlining or automatic detecting of restricted areas due
to constant declarations or strict aliasing rules. It even does not have
such simple optimization methods like using assembler inline code for
commonly used CTRL functions like memset(), memcmp(), memmove(),
str*(), etc.
The results can be visible in the speed of final binaries.
You can use harbour/tests/speedtst.prg to compare the speed of Harbour
compiled with different C compilers.
You can also use it with other xbase/clipper compatible languages like
xHarbour, Clipper, CLIP, FlagShip, xBase++.

Below I'm attaching results for current Harbour SVN code. I cannot make
any tests with MSVC because I cannot use it with WINE. The speedtst.prg
code does not make any IO operations which may effect execution speed
so WINE and DOSEMU can execute final binaries naively without any time
consuming interrupts which may the results.
I used "official" MinGW with GCC 3.4.5 which gives slower code then GCC4.4.
I also do not have the newest PelleC 6.0.

GCC4.5 was used with -flto which enable link time optimization (LTO).
As you can see GCC4.4 in C++ mode and GCC4.5 gives the fastest code
and old PelleC compiler used by xHarbour.com (XCC) gives the slowest
code.
I haven't installed yet C++ compiler for GCC4.5 which potentially should
give the fastest code.
Please note that all OpenWatcom builds were created with disable IPO
optimization in HVM code. Due to compilation time we disabled HB_HVM_ALL=yes
optimization which improve the performance of final OW binaries.

Here are sorted the results.

Harbour 2.1.0dev (Rev. 14060) GNU C 4.5 (64-bit) x86-64
   [ total application time: ]14.66

Harbour 2.1.0dev (Rev. 14060) GNU C++ 4.4 (64-bit) x86-64
   [ total application time: ]14.65

Harbour 2.1.0dev (Rev. 14060) GNU C 4.4 (64-bit) x86-64
   [ total application time: ]14.95

Harbour 2.1.0dev (Rev. 14060) Intel(R) (ICC) C 11.0 (64-bit) x86-64
   [ total application time: ]16.22

Harbour 2.1.0dev (Rev. 14060) Open64 C 4.2.1 (64-bit) x86-64
   [ total application time: ]16.29

Harbour 2.1.0dev (Rev. 14060) LLVM/Clang C 4.2.1 (64-bit) x86-64
   [ total application time: ]17.57

Harbour 2.1.0dev (Rev. 14060) GNU C 4.4 (32-bit) x86
   [ total application time: ]18.13

Harbour 2.1.0dev (Rev. 14060) Sun C (ident 0x5100) (64-bit) x86-64
   [ total application time: ]18.21

Harbour 2.1.0dev (Rev. 14060) MinGW GNU C 3.4.5 (32-bit) x86
   [ total application time: ]19.09

Harbour 2.1.0dev (Rev. 14060) Delorie GNU C 4.3.2 (DJGPP 2.04) (32-bit) x86
   [ total application time: ]23.18

Harbour 2.1.0dev (Rev. 14060) Open Watcom C 12.80 (32-bit) x86 (LINUX)
   [ total application time: ]23.54

Harbour 2.1.0dev (Rev. 14060) Open Watcom C++ 12.80.8 (32-bit) x86 (WIN)
   [ total application time: ]25.65

Harbour 2.1.0dev (Rev. 14060) Open Watcom C 12.80 (32-bit) x86 (DOS)
   [ total application time: ]25.76

Harbour 2.1.0dev (Rev. 14060) Borland C++ 5.5 (32-bit) x86
   [ total application time: ]27.48

Harbour 2.1.0dev (Rev. 14060) GNU C 2.96 (32-bit) x86
   [ total application time: ]29.39

Harbour 2.1.0dev (Rev. 14060) Pelles ISO C Compiler 4.50 (32-bit) x86
   [ total application time: ]30.83

Harbour 2.1.0dev (Rev. 14060) Pelles ISO C Compiler 2.70 (32-bit) x86 (XCC)
   [ total application time: ].

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Hi Przemek,

Is it also true that C++ mode enhances speed for 
x86 code? I see it slightly does for x86_64.

Brgds,
Viktor

On 2010 Mar 10, at 16:43, Przemysław Czerpak wrote:

> On Wed, 10 Mar 2010, francesco perillo wrote:
> 
> Hi,
> 
>>> BCC is a joke these days.
>> ooops... I have a production site working with a bbc version of Harbour...
> 
> It works but it's not very good choice.
> There are some very serious bugs in BCC but for the ones known for us
> we have workarounds, i.e. we do not use any floating point BCC low level
> functions like _fpclass[l]() because they break 'double' number
> calculations reducing the precision to 'float' level or we use
> DLMALLOC as default memory manager because the one in BCC can cause
> memory corruption in some situations.
> But more important is the fact that BCC was not extended in last years
> and now in comparison to other modern C compilers it does not have many
> important features and optimization methods.
> In contrast nearly each new GCC version has some important extensions
> which improve optimization code and performance of final applications,
> i.e. GCC 4.4 generates nearly twice faster code then 2.9x. (see results
> below).
> 
> Harbour core code is written in a way which should help in optimization
> process for compilers using some advanced optimization methods like
> automatic autoinlining or automatic detecting of restricted areas due
> to constant declarations or strict aliasing rules. It even does not have
> such simple optimization methods like using assembler inline code for
> commonly used CTRL functions like memset(), memcmp(), memmove(),
> str*(), etc.
> The results can be visible in the speed of final binaries.
> You can use harbour/tests/speedtst.prg to compare the speed of Harbour
> compiled with different C compilers.
> You can also use it with other xbase/clipper compatible languages like
> xHarbour, Clipper, CLIP, FlagShip, xBase++.
> 
> Below I'm attaching results for current Harbour SVN code. I cannot make
> any tests with MSVC because I cannot use it with WINE. The speedtst.prg
> code does not make any IO operations which may effect execution speed
> so WINE and DOSEMU can execute final binaries naively without any time
> consuming interrupts which may the results.
> I used "official" MinGW with GCC 3.4.5 which gives slower code then GCC4.4.
> I also do not have the newest PelleC 6.0.
> 
> GCC4.5 was used with -flto which enable link time optimization (LTO).
> As you can see GCC4.4 in C++ mode and GCC4.5 gives the fastest code
> and old PelleC compiler used by xHarbour.com (XCC) gives the slowest
> code.
> I haven't installed yet C++ compiler for GCC4.5 which potentially should
> give the fastest code.
> Please note that all OpenWatcom builds were created with disable IPO
> optimization in HVM code. Due to compilation time we disabled HB_HVM_ALL=yes
> optimization which improve the performance of final OW binaries.
> 
> Here are sorted the results.
> 
> Harbour 2.1.0dev (Rev. 14060) GNU C 4.5 (64-bit) x86-64
>   [ total application time: ]14.66
> 
> Harbour 2.1.0dev (Rev. 14060) GNU C++ 4.4 (64-bit) x86-64
>   [ total application time: ]14.65
> 
> Harbour 2.1.0dev (Rev. 14060) GNU C 4.4 (64-bit) x86-64
>   [ total application time: ]14.95
> 
> Harbour 2.1.0dev (Rev. 14060) Intel(R) (ICC) C 11.0 (64-bit) x86-64
>   [ total application time: ]16.22
> 
> Harbour 2.1.0dev (Rev. 14060) Open64 C 4.2.1 (64-bit) x86-64
>   [ total application time: ]16.29
> 
> Harbour 2.1.0dev (Rev. 14060) LLVM/Clang C 4.2.1 (64-bit) x86-64
>   [ total application time: ]17.57
> 
> Harbour 2.1.0dev (Rev. 14060) GNU C 4.4 (32-bit) x86
>   [ total application time: ]18.13
> 
> Harbour 2.1.0dev (Rev. 14060) Sun C (ident 0x5100) (64-bit) x86-64
>   [ total application time: ]18.21
> 
> Harbour 2.1.0dev (Rev. 14060) MinGW GNU C 3.4.5 (32-bit) x86
>   [ total application time: ]19.09
> 
> Harbour 2.1.0dev (Rev. 14060) Delorie GNU C 4.3.2 (DJGPP 2.04) (32-bit) x86
>   [ total application time: ]23.18
> 
> Harbour 2.1.0dev (Rev. 14060) Open Watcom C 12.80 (32-bit) x86 (LINUX)
>   [ total application time: ]23.54
> 
> Harbour 2.1.0dev (Rev. 14060) Open Watcom C++ 12.80.8 (32-bit) x86 (WIN)
>   [ total application time: ]25.65
> 
> Harbour 2.1.0dev (Rev. 14060) Open Watcom C 12.80 (32-bit) x86 (DOS)
>   [ total application time: ]25.76
> 
> Harbour 2.1.0dev (Rev. 14060) Borland C++ 5.5 (32-bit) x86
>   [ total application time: ]27.48
> 
> Harbour 2.1.0dev (Rev. 14060)

Re: [Harbour] recommended C compiler for Win

[Qatan]

Maurilio,


PS. I've installed dragon media, smartsvn and I was able to build harbour
on
win32 very smoothly.

Maurilio.


Just to share my humble experience I've installed "MingW-5.1.6",
"TortoiseSVN-1.6.7.18415-win32-svn-1.6.9.", "UPX-304w" without any problems
and I was able to build harbour from SVN on WinXP very well.

The mingw installation I found here:
http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/
It was very simple for me. Maybe I was a lucky "sailor in the first voyage"?

Qatan


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Lorenzo Fiorini]

On Wed, Mar 10, 2010 at 7:11 PM, Qatan  wrote:

> It was very simple for me. Maybe I was a lucky "sailor in the first voyage"?

No, I have the same experience: I just run the mingw installer, the
msys installer, get gd, zlib, openssl from gnuwin32 and run the
installers, get eclipse and git and run the installers, get postgresql
and apache and run the installers.
Using dirs like c:\opt, c:\usr and c:\var is hard to see the
differences between XP/msys, OSX and Linux environment.

best regards,
Lorenzo
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Massimo Belgrano]

reading version 5.2 i think to a new version of gcc that is 4.4.1 (afaik
dwarf)
http://nuwen.net/mingw.html#about

Instead http://www.tdragon.net/recentgcc/
use a updated .4.4.1 TDM-2

2010/3/10 Lorenzo Fiorini 

> On Wed, Mar 10, 2010 at 7:11 PM, Qatan  wrote:
>
> > It was very simple for me. Maybe I was a lucky "sailor in the first
> voyage"?
>
> No, I have the same experience: I just run the mingw installer, the
> msys installer, get gd, zlib, openssl from gnuwin32 and run the
> installers, get eclipse and git and run the installers, get postgresql
> and apache and run the installers.
> Using dirs like c:\opt, c:\usr and c:\var is hard to see the
> differences between XP/msys, OSX and Linux environment.
>
> best regards,
> Lorenzo
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



-- 
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Hi,

On 2010 Mar 10, at 19:11, Qatan wrote:

> Maurilio,
> 
>> PS. I've installed dragon media, smartsvn and I was able to build harbour
>> on
>> win32 very smoothly.
>> 
>> Maurilio.
> 
> Just to share my humble experience I've installed "MingW-5.1.6",
> "TortoiseSVN-1.6.7.18415-win32-svn-1.6.9.", "UPX-304w" without any problems
> and I was able to build harbour from SVN on WinXP very well.

Just don't be mistaken by the misleading versioning of 
"mingw" here, 5.1.6 has nothing to do with the gcc version 
which the distro is based on, it's their own numbering 
(similar to cygwin (1.7) and djgpp (2.04b) verison).

> The mingw installation I found here:
> http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/
> It was very simple for me. Maybe I was a lucky "sailor in the first voyage"?

Now it's fine, the only problem is that it gives 
you gcc version 3.4.5, which is a 6 years old version, 
much less efficient than current ones.

[ Even if you chose "candidate" or "current". ]

[ Besides it install itself into start menu, plus 
saves temporary files without asking about it or 
deleting them. But that's really minor issue compared 
to the rest. ]

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Przemysław Czerpak]

On Wed, 10 Mar 2010, Szak�ts Viktor wrote:

Hi,

> Is it also true that C++ mode enhances speed for 
> x86 code? I see it slightly does for x86_64.

I do not know. In general C++ mode is a little bit more restrictive then
pure C so it's possible that some compilers which want to keep strict C
standards do not make some optimizations which can be safely enabled in
C++ mode. This is the only reason of potential differences because C++ RTL
usually is a little bit more heavy and slower.
I remember that in the past we have in the source code some notes about
MSVC "bugs" with workarounds for them. In fact it was examples of code
which interacts with optimizer and in C++ mode may not work so the problem
was in our code not in MSVC. For very long time we were using MSVC in C++
mode only so I cannot say if MS enabled all possible optimization also for
C mode or it was exploited in C++ mode only.
It's interesting to check if there are any speed differences in MSVC C and
C++ builds.
Can you check it?

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

> reading version 5.2 i think to a new version of gcc that is 4.4.1 (afaik 
> dwarf)
> http://nuwen.net/mingw.html#about

This is another binary distro with yet another package 
versioning scheme. 5.2 cannot be compared to mingw official 
package version numbering.

Also DWARF support is not connected to gcc version number. 
Both DWARF and SJLJ exist for version 4.4.1 on tdragon site.

Please don't different release package version numbers 
with gcc version numbers.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Qatan]

Viktor,


  Just don't be mistaken by the misleading versioning of
"mingw" here, 5.1.6 has nothing to do with the gcc version
which the distro is based on, it's their own numbering
(similar to cygwin (1.7) and djgpp (2.04b) verison).


  Thanks for the nice explanation. It brings light for us to understand all 
that.



Now it's fine, the only problem is that it gives
you gcc version 3.4.5, which is a 6 years old version,
much less efficient than current ones.
[ Even if you chose "candidate" or "current". ]
[ Besides it install itself into start menu, plus
saves temporary files without asking about it or
deleting them. But that's really minor issue compared
to the rest. ]


   Ok, Thanks again. I just downloaded TDM bundled installer and installed 
it. Pretty easy.
   Didn't notice much difference (my app is very small) but your advise 
gives me the centainty that I am now using the best tool for harbour.


   What do you think about changing the INSTALL file where it says:



Tools:
...
GNU Make
Windows binary + source:
   http://sourceforge.net/projects/mingw/files/MinGW%20make



   And put: http://www.tdragon.net/recentgcc/ instead (or as an option)?



   Just a humble suggestion, of course.

   Thanks


Qatan

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Hi Lorenzo,

> On Wed, Mar 10, 2010 at 7:11 PM, Qatan  wrote:
> 
>> It was very simple for me. Maybe I was a lucky "sailor in the first voyage"?
> 
> No, I have the same experience: I just run the mingw installer, the
> msys installer, get gd, zlib, openssl from gnuwin32 and run the
> installers, get eclipse and git and run the installers, get postgresql
> and apache and run the installers.
> Using dirs like c:\opt, c:\usr and c:\var is hard to see the
> differences between XP/msys, OSX and Linux environment.

I think it would be useful for many users if you could 
create a short HOWTO for official MinGW 4.4.0 installation.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Przemysław Czerpak]

On Wed, 10 Mar 2010, Szak�ts Viktor wrote:

Hi,

> >> It was very simple for me. Maybe I was a lucky "sailor in the first 
> >> voyage"?
> > No, I have the same experience: I just run the mingw installer, the
> > msys installer, get gd, zlib, openssl from gnuwin32 and run the
> > installers, get eclipse and git and run the installers, get postgresql
> > and apache and run the installers.
> > Using dirs like c:\opt, c:\usr and c:\var is hard to see the
> > differences between XP/msys, OSX and Linux environment.
> I think it would be useful for many users if you could 
> create a short HOWTO for official MinGW 4.4.0 installation.

The above Lorenzo text is such HOWTO.
I use MS-Windows very seldom so it's possible that sth has changed in last
years but last time I was using MinGW and MSys in real MS-Windows environment
the whole installation process was reduced to two things:
   1. run installers
   2. confirm defaults

Anyhow recently when my friend asked me about installing
Harbour in his laptop I simply downloaded Harbour 2.0.0 windows binaries
with integrated MinGW and I have to say it was real pleasure to install
everything in few clicks and have working Harbour "out of the box" just
like after installing RPMs or DEBs in Linux systems.
My congratulations to you for this package. Very very good job.
It should perfectly resolve the problems which novice users usually
had: "how to start using Harbour?"

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Hi Qatan,

>>  Just don't be mistaken by the misleading versioning of
>> "mingw" here, 5.1.6 has nothing to do with the gcc version
>> which the distro is based on, it's their own numbering
>> (similar to cygwin (1.7) and djgpp (2.04b) verison).
> 
>  Thanks for the nice explanation. It brings light for us to understand all 
> that.
> 
>> Now it's fine, the only problem is that it gives
>> you gcc version 3.4.5, which is a 6 years old version,
>> much less efficient than current ones.
>> [ Even if you chose "candidate" or "current". ]
>> [ Besides it install itself into start menu, plus
>> saves temporary files without asking about it or
>> deleting them. But that's really minor issue compared
>> to the rest. ]
> 
>   Ok, Thanks again. I just downloaded TDM bundled installer and installed it. 
> Pretty easy.

You're welcome.

>   Didn't notice much difference (my app is very small) but your advise gives 
> me the centainty that I am now using the best tool for harbour.
> 
>   What do you think about changing the INSTALL file where it says:
> 
> Tools:
>...
>GNU Make
>Windows binary + source:
>   http://sourceforge.net/projects/mingw/files/MinGW%20make
> 
>   And put: http://www.tdragon.net/recentgcc/ instead (or as an option)?
> 
>   Just a humble suggestion, of course.

It's there already, take a look at the 'C/C++ Compilers/Shells:' 
subsection right at the beginning of '13. LINKS TO EXTERNAL COMPONENTS' 
main section.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Hi,

 It was very simple for me. Maybe I was a lucky "sailor in the first 
 voyage"?
>>> No, I have the same experience: I just run the mingw installer, the
>>> msys installer, get gd, zlib, openssl from gnuwin32 and run the
>>> installers, get eclipse and git and run the installers, get postgresql
>>> and apache and run the installers.
>>> Using dirs like c:\opt, c:\usr and c:\var is hard to see the
>>> differences between XP/msys, OSX and Linux environment.
>> I think it would be useful for many users if you could 
>> create a short HOWTO for official MinGW 4.4.0 installation.
> 
> The above Lorenzo text is such HOWTO.

Sorry, but it isn't. I've installed official 4.4.0 
mingw a few month ago (even commented the experience 
here), and it was everything but not simple, obvious, 
or quick, or anything what Lorenzo described in one 
sentence.

> I use MS-Windows very seldom so it's possible that sth has changed in last
> years but last time I was using MinGW and MSys in real MS-Windows environment
> the whole installation process was reduced to two things:
>   1. run installers
>   2. confirm defaults

It doesn't work like that for 4.4.0 unfortunately.

First I had to find the documentation which described the 
process, then you have to pick separate binary packages from 
the long list of available sf.net downloads, all of them available 
in multiple versions (not matching the documentation of course), 
then you download these files (hopefully the right ones), each 
of them is packed using different tool (gzip, bzip2, lzma), 
then you unpack them, and some of the packages went into their 
own subdir, some of them don't, so in a final pass you have to 
manually assemble the dev tree using some intuition.

That experience is the reason why we still don't support 
QT 4.6 in Harbour.

> Anyhow recently when my friend asked me about installing
> Harbour in his laptop I simply downloaded Harbour 2.0.0 windows binaries
> with integrated MinGW and I have to say it was real pleasure to install
> everything in few clicks and have working Harbour "out of the box" just
> like after installing RPMs or DEBs in Linux systems.
> My congratulations to you for this package. Very very good job.
> It should perfectly resolve the problems which novice users usually
> had: "how to start using Harbour?"

Thank you very much. That was the goal, and also the 
goal of "INSTALL" doc, hbmk2 and getting rid of old dual 
make-system. It good to hear that now it's usable for 
human beings :)

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Qatan]

Viktor,



  What do you think about changing the INSTALL file where it says:

Tools:
   ...
   GNU Make
   Windows binary + source:
  http://sourceforge.net/projects/mingw/files/MinGW%20make

  And put: http://www.tdragon.net/recentgcc/ instead (or as an option)?

  Just a humble suggestion, of course.


It's there already, take a look at the 'C/C++ Compilers/Shells:'
subsection right at the beginning of '13. LINKS TO EXTERNAL COMPONENTS'
main section.



  You are right. I didn't notice that before. Thank you again for taking 
time to help.

  Regards,


Qatan 


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Hi,

>> Is it also true that C++ mode enhances speed for 
>> x86 code? I see it slightly does for x86_64.
> 
> I do not know. In general C++ mode is a little bit more restrictive then
> pure C so it's possible that some compilers which want to keep strict C
> standards do not make some optimizations which can be safely enabled in
> C++ mode. This is the only reason of potential differences because C++ RTL
> usually is a little bit more heavy and slower.
> I remember that in the past we have in the source code some notes about
> MSVC "bugs" with workarounds for them. In fact it was examples of code
> which interacts with optimizer and in C++ mode may not work so the problem
> was in our code not in MSVC. For very long time we were using MSVC in C++
> mode only so I cannot say if MS enabled all possible optimization also for
> C mode or it was exploited in C++ mode only.
> It's interesting to check if there are any speed differences in MSVC C and
> C++ builds.
> Can you check it?

I checked mingw-tdm-2 4.4.1, and C++ turned out to be consistently 
faster by 5% than plain C. Calculated by 4-4 speedtst runs, dropping 
min/max and averaging rest 2-2 results.

Env: MBP iC2D/2.8 -> OS X 10.6 (64-bit kernel) -> VMWare 3.0.2 -> Win7 x64

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Przemysław Czerpak]

On Wed, 10 Mar 2010, Szak�ts Viktor wrote:

Hi,

> > It's interesting to check if there are any speed differences in MSVC C and
> > C++ builds.
> > Can you check it?
> I checked mingw-tdm-2 4.4.1, and C++ turned out to be consistently 
> faster by 5% than plain C. Calculated by 4-4 speedtst runs, dropping 
> min/max and averaging rest 2-2 results.
> Env: MBP iC2D/2.8 -> OS X 10.6 (64-bit kernel) -> VMWare 3.0.2 -> Win7 x64

It's similar to mine results.
GCC4 in C++ mode for sure uses more extensively strict aliasing
optimization. At least it was reporting more errors and warnings
for Harbour core code which was using casting ignoring aliasing
rules.

BTW this ones are still reported:

../../../hb_btree.c: In function ‘ioOneBufferAlloc’:
../../../hb_btree.c:275:3: warning: dereferencing type-punned pointer will 
break strict-aliasing rules

This seems to be also real bug which may cause GPF on some platforms but
I'm not familiar enough with this code to fix it myself.

../../../sddfb.c: In function ‘fbDisconnect’:
../../../sddfb.c:181:4: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
../../../sddfb.c: In function ‘fbOpen’:
../../../sddfb.c:209:4: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
../../../sddfb.c:219:4: warning: dereferencing type-punned pointer will break 
strict-aliasing rules

This is also danger casting though it should work if void * is large enough
to hold FB handlers. Anyhow it's potential problem so it should be fixed.

BTW it would be good to check what GCC does when it detects such code or
even real problems (it can report also: "dereferencing pointer ... does
break strict-aliasing rules").
Does it disable optimization or generates potentially wrong code.

Can you compare C and C++ mode in MSVC too?

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[smu johnson]

Official MinGW installation reminds me of the old Xvid.org site before its
new website... so back around in the pre-2007 years...   Also reminds me of
how annoying installing and using Cygwin can be.  Interesting thread!

2010/3/10 Przemysław Czerpak 

> On Wed, 10 Mar 2010, Szak�ts Viktor wrote:
>
> Hi,
>
> > > It's interesting to check if there are any speed differences in MSVC C
> and
> > > C++ builds.
> > > Can you check it?
> > I checked mingw-tdm-2 4.4.1, and C++ turned out to be consistently
> > faster by 5% than plain C. Calculated by 4-4 speedtst runs, dropping
> > min/max and averaging rest 2-2 results.
> > Env: MBP iC2D/2.8 -> OS X 10.6 (64-bit kernel) -> VMWare 3.0.2 -> Win7
> x64
>
> It's similar to mine results.
> GCC4 in C++ mode for sure uses more extensively strict aliasing
> optimization. At least it was reporting more errors and warnings
> for Harbour core code which was using casting ignoring aliasing
> rules.
>
> BTW this ones are still reported:
>
> ../../../hb_btree.c: In function ‘ioOneBufferAlloc’:
> ../../../hb_btree.c:275:3: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
>
> This seems to be also real bug which may cause GPF on some platforms but
> I'm not familiar enough with this code to fix it myself.
>
> ../../../sddfb.c: In function ‘fbDisconnect’:
> ../../../sddfb.c:181:4: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> ../../../sddfb.c: In function ‘fbOpen’:
> ../../../sddfb.c:209:4: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> ../../../sddfb.c:219:4: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
>
> This is also danger casting though it should work if void * is large enough
> to hold FB handlers. Anyhow it's potential problem so it should be fixed.
>
> BTW it would be good to check what GCC does when it detects such code or
> even real problems (it can report also: "dereferencing pointer ... does
> break strict-aliasing rules").
> Does it disable optimization or generates potentially wrong code.
>
> Can you compare C and C++ mode in MSVC too?
>
> best regards,
> Przemek
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



-- 
smu johnson 
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Hi,

> It's similar to mine results.
> GCC4 in C++ mode for sure uses more extensively strict aliasing
> optimization. At least it was reporting more errors and warnings
> for Harbour core code which was using casting ignoring aliasing
> rules.

Maybe we should switch to C++ as default for 
mingw or gcc in general.

mingw C++ build speed is about 15% slower, so 
that's the price.

(maybe it's possible to achieve C++ optimization 
levels by some extra C compiler option? so g++ is 
not needed to reach the same effect)

> BTW this ones are still reported:
> 
> ../../../hb_btree.c: In function ‘ioOneBufferAlloc’:
> ../../../hb_btree.c:275:3: warning: dereferencing type-punned pointer will 
> break strict-aliasing rules
> 
> This seems to be also real bug which may cause GPF on some platforms but
> I'm not familiar enough with this code to fix it myself.
> 
> ../../../sddfb.c: In function ‘fbDisconnect’:
> ../../../sddfb.c:181:4: warning: dereferencing type-punned pointer will break 
> strict-aliasing rules
> ../../../sddfb.c: In function ‘fbOpen’:
> ../../../sddfb.c:209:4: warning: dereferencing type-punned pointer will break 
> strict-aliasing rules
> ../../../sddfb.c:219:4: warning: dereferencing type-punned pointer will break 
> strict-aliasing rules

Strangely, these are not reported by mingw.

> This is also danger casting though it should work if void * is large enough
> to hold FB handlers. Anyhow it's potential problem so it should be fixed.

Definitely. It's a long time problem with FB client 
interface that it uses ints for handles in 64-bit 
mode, but void pointers in 32-bit mode. Seems even 
current solution is not perfect to make them both 
work without warnings.

See this in ibase.h:
---
#if defined(_LP64) || defined(__LP64__) || defined(__arch64__) || 
defined(_WIN64)
typedef unsigned intFB_API_HANDLE;
#else
typedef void*   FB_API_HANDLE;
#endif
---

> BTW it would be good to check what GCC does when it detects such code or
> even real problems (it can report also: "dereferencing pointer ... does
> break strict-aliasing rules").
> Does it disable optimization or generates potentially wrong code.
> 
> Can you compare C and C++ mode in MSVC too?

With same methodology there is about 1% speed 
advantage for C++ mode. It seems consistent, 
but minor. The size different is also very 
minor, C++ being same or somewhat larger 
(by 0-0.1%, or +0-5KB in case of Harbour tools). 
Tested with MSVC 2008 (as part of Win SDK 7)

BTW, mingw created noticeably larger executables, 
by about 1-6% (+20-100KB in case of Harbour tools).

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

BTW, here is the full result matrix for mingw 4.4.1 and MSVC 2008:

 mingwmsvc
C++  13.57   *13.59
C   *14.2713.76

(* is default build mode in Harbour)

This means that in C++ mode msvc and mingw are very close, 
in C mode msvc still leads, and in default Harbour builds, 
msvc also leads.

I have to correct mingw size increase results 
(forgot to strip them), so mingw in C++ is about 
0.3-1.5% larger than C counterpart. In practice,
it's negligible.

msvc and mingw sizes are a little fuzzy to compare:
---
 mingw C++ mingw C   msvc C++ msvc C
harbour-21.dll   3.523.584   3.499.520  2.569.216  2.567.680
harbourmt-21.dll 3.553.280   3.526.144  2.595.840  2.594.816
harbour.exe577.024 568.832583.168583.168
hbformat-dll.exe26.112  26.112 60.416 60.416
hbformat.exe   745.984 744.448462.848462.848
hbi18n-dll.exe  11.776  11.776 46.080 46.080
hbi18n.exe 726.016 724.480446.464446.464
hbmk2-dll.exe  696.320 689.152704.512704.512
hbmk2.exe1.474.048   1.460.224  1.107.968  1.105.920
hbpp.exe   133.632 130.560172.544172.544
hbrun-dll.exe  591.872 585.216600.064600.064
hbrun.exe3.393.536   3.372.032  2.589.184  2.584.576
hbtest-dll.exe 373.760 374.272407.552407.552
hbtest.exe   1.477.120   1.472.512  1.100.288  1.099.776
---

Some binaries are smaller, some others are much 
larger in mingw.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Results in 64-bit mode using MSVC 2008 (same as 32-bit) 
and mingw 4.4.4 20100129 (prerelease):

 mingw  msvc
C++ 11.63
C11.08

mingw seems to be the winner here in default 
Harbour builds, even though msvc had the advantage 
of C++ mode.

Plus, 64-bit mode has a clear advantage over 32-bit.

Sizes:
  ming64 C   msvc64 C++
harbour-21-x64.dll   3.380.7363.091.456
harbourmt-21-x64.dll 3.403.2643.130.880
harbour.exe625.152  720.384
hbformat-dll.exe35.840   61.952
hbformat.exe   706.560  524.800
hbi18n-dll.exe  20.480   45.568
hbi18n.exe 684.032  506.880
hbmk2-dll.exe  751.616  847.360
hbmk2.exe1.462.7841.342.976
hbpp.exe   133.632  171.520
hbrun-dll.exe  643.072  738.304
hbrun.exe3.314.6883.127.808
hbtest-dll.exe 391.168  417.280
hbtest.exe   1.419.7761.239.552

I will make more tests, but it seems it's 
worth switching to mingw also for 64-bit mode.

Last time the problem was weak or none (yet) 
3rd party support for mingw64 (f.e. openssl).

Brgds,
Viktor

On 2010 Mar 11, at 09:10, Viktor Szakáts wrote:

> BTW, here is the full result matrix for mingw 4.4.1 and MSVC 2008:
> 
> mingwmsvc
> C++  13.57   *13.59
> C   *14.2713.76
> 
> (* is default build mode in Harbour)
> 
> This means that in C++ mode msvc and mingw are very close, 
> in C mode msvc still leads, and in default Harbour builds, 
> msvc also leads.
> 
> I have to correct mingw size increase results 
> (forgot to strip them), so mingw in C++ is about 
> 0.3-1.5% larger than C counterpart. In practice,
> it's negligible.
> 
> msvc and mingw sizes are a little fuzzy to compare:
> ---
> mingw C++ mingw C   msvc C++ msvc C
> harbour-21.dll   3.523.584   3.499.520  2.569.216  2.567.680
> harbourmt-21.dll 3.553.280   3.526.144  2.595.840  2.594.816
> harbour.exe577.024 568.832583.168583.168
> hbformat-dll.exe26.112  26.112 60.416 60.416
> hbformat.exe   745.984 744.448462.848462.848
> hbi18n-dll.exe  11.776  11.776 46.080 46.080
> hbi18n.exe 726.016 724.480446.464446.464
> hbmk2-dll.exe  696.320 689.152704.512704.512
> hbmk2.exe1.474.048   1.460.224  1.107.968  1.105.920
> hbpp.exe   133.632 130.560172.544172.544
> hbrun-dll.exe  591.872 585.216600.064600.064
> hbrun.exe3.393.536   3.372.032  2.589.184  2.584.576
> hbtest-dll.exe 373.760 374.272407.552407.552
> hbtest.exe   1.477.120   1.472.512  1.100.288  1.099.776
> ---
> 
> Some binaries are smaller, some others are much 
> larger in mingw.
> 
> Brgds,
> Viktor
> 

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Massimo Belgrano]

Borland allow function to be replaceable so  you can replace a single
function without replace entire module
not good way but can be easy:

in my.lib other than other function
func stato
will be replaced
in myprg with simply
func stato
sequence link define result
2010/3/9 Maurilio Longo 

> Hi,
>
> which is the harbour recommended C compiler for the windows platform?
>
> best regards.
>
> --
>  __
> |  |  | |__| Maurilio Longo
> |_|_|_|| farmaconsult s.r.l.
>
>
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



-- 
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Hi,

> Borland allow function to be replaceable so  you can replace a single 
> function without replace entire module
> not good way but can be easy:
> 
> in my.lib other than other function
> func stato
> will be replaced 
> in myprg with simply
> func stato
> sequence link define result

There is nothing to thank for bcc to hide 
important link-time problems caused by wrong 
coding / linking practices, like using multiple 
definitions of the same symbol. Such problems 
are best to be fixed in app code ASAP.

BTW, mingw also "supports" it, you only need to 
disable the fatal error using '-Wl,--allow-multiple-definition' 
option. Same goes for msvc.

We've been talking a lot about this on the 
list in the past, so I'm surprised there is 
still misunderstanding here.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Przemysław Czerpak]

On Thu, 11 Mar 2010, Szak�ts Viktor wrote:

Hi,

> Results in 64-bit mode using MSVC 2008 (same as 32-bit) 
> and mingw 4.4.4 20100129 (prerelease):
>  mingw  msvc
> C++ 11.63
> C11.08
> mingw seems to be the winner here in default 
> Harbour builds, even though msvc had the advantage 
> of C++ mode.

Finally I installed for tests GCC 4.5 (devel version)
and in C++ mode with -flto it gives also better results
then in C mode so it's potentially the fastest code.
I have to say that I vary like how the meta code is
implemented. Unlike other compilers GCC can be used
with LTO without any complicated settings and programmer
can easy control if he wants or not link time optimization
using one link time switch.

> Plus, 64-bit mode has a clear advantage over 32-bit.

I have similar results in Linux.
64bit Harbour programs are faster then 32bit ones.

> I will make more tests, but it seems it's 
> worth switching to mingw also for 64-bit mode.

The very strong thing in GCC is really good performance
for different hardware. The optimization logic is not
hardcoded to one processor family so it can be easy adopt
to completely different CPUs. Anyhow I do not know what
it the quality of Win64 GCC ports so here you will have
to took the decision yourself. It's quite new port anyhow
I think that in short time it should be very stable and
efficient. 64big GCC ports for different *nixes have been
existing for _very_ long time.

Thank you for your tests.

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Hi,

>> Results in 64-bit mode using MSVC 2008 (same as 32-bit) 
>> and mingw 4.4.4 20100129 (prerelease):
>> mingw  msvc
>> C++ 11.63
>> C11.08
>> mingw seems to be the winner here in default 
>> Harbour builds, even though msvc had the advantage 
>> of C++ mode.
> 
> Finally I installed for tests GCC 4.5 (devel version)
> and in C++ mode with -flto it gives also better results
> then in C mode so it's potentially the fastest code.
> I have to say that I vary like how the meta code is
> implemented. Unlike other compilers GCC can be used
> with LTO without any complicated settings and programmer
> can easy control if he wants or not link time optimization
> using one link time switch.

Sounds good, I will try 4.5.0 a bit later.

>> Plus, 64-bit mode has a clear advantage over 32-bit.
> 
> I have similar results in Linux.
> 64bit Harbour programs are faster then 32bit ones.
> 
>> I will make more tests, but it seems it's 
>> worth switching to mingw also for 64-bit mode.
> 
> The very strong thing in GCC is really good performance
> for different hardware. The optimization logic is not
> hardcoded to one processor family so it can be easy adopt
> to completely different CPUs. Anyhow I do not know what
> it the quality of Win64 GCC ports so here you will have
> to took the decision yourself. It's quite new port anyhow
> I think that in short time it should be very stable and
> efficient. 64big GCC ports for different *nixes have been
> existing for _very_ long time.

With some time investment I could build everything 
required for my local application using mingw64. 
In fact mingw support is starting to overtake the 
MSVC level for 3rd party libs, though there are still 
bugs in mingw Windows headers which have to be dealt 
with.

The only so far known problem is ignored -mwindows 
option when using mingw64 4.4.4, so app doesn't 
pop with GTWVT, with GTWIN it runs beautifully. 
I'm not sure if the problem is with Harbour or 
mingw64.

Binary size is just a bit larger than mingw 32-bit 
build (and still larger than msvc64).

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Przemysław Czerpak]

On Fri, 12 Mar 2010, Szak�ts Viktor wrote:

Hi,

> The only so far known problem is ignored -mwindows 
> option when using mingw64 4.4.4, so app doesn't 
> pop with GTWVT, with GTWIN it runs beautifully. 
> I'm not sure if the problem is with Harbour or 
> mingw64.

It sounds like an old issue.
If main() function is found in linked object files or
libraries then console application is created with main()
as startup entry. Otherwise windows application is created
with WinMain() startup entry. It's the reason why we created
separated libraries hbmainstd and hbmainwin with console and
GUI startup entries. It should be enough to chose the valid
one. I thought that hbmk2 does it.

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Hi,

>> The only so far known problem is ignored -mwindows 
>> option when using mingw64 4.4.4, so app doesn't 
>> pop with GTWVT, with GTWIN it runs beautifully. 
>> I'm not sure if the problem is with Harbour or 
>> mingw64.
> 
> It sounds like an old issue.
> If main() function is found in linked object files or
> libraries then console application is created with main()
> as startup entry. Otherwise windows application is created
> with WinMain() startup entry. It's the reason why we created
> separated libraries hbmainstd and hbmainwin with console and
> GUI startup entries. It should be enough to chose the valid
> one. I thought that hbmk2 does it.

It does it for shared builds.

hbmk2 behaves the exact same for mingw and mingw64, 
yet it doesn't work for mingw64 and does for mingw.

So either it's just a coincidence that mingw works, 
and there is hbmk2 bug, or there is a difference 
in either in Harbour mingw64 builds or mingw64 
itself.

.c stub rightly issues hb_forceLinkMainWin() in 
both cases, which should be enough to pull WinMain().

If I try 'hbmk2 a.prg -shared', it works, but 
if I try 'hbmk2 a.prg -shared -gtwvt', it tells: 
  'Can't locate the starting procedure: 'MAIN''

Then just 'hbmk2 a.prg -gtwvt':
  'It's not a GUI program'

a.prg is:
---
FUNCTION MAIN()
ALERT( "hello" )
RETURN 0
---

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Przemysław Czerpak]

On Fri, 12 Mar 2010, Szak�ts Viktor wrote:

Hi,

> hbmk2 behaves the exact same for mingw and mingw64, 
> yet it doesn't work for mingw64 and does for mingw.

This problem was exploited in different MINGW version.
Not in all ones.
Seems that now HBMK2 is tuned only for some chosen MinGW
versions.

> So either it's just a coincidence that mingw works, 
> and there is hbmk2 bug, or there is a difference 
> in either in Harbour mingw64 builds or mingw64 
> itself.

I noticed differences between different mi...@32
releases so it's nothing amazing that they may
exist also between 32 and 64 bit MinGW versions.

> .c stub rightly issues hb_forceLinkMainWin() in 
> both cases, which should be enough to pull WinMain().

It not a problem of linking WinMain() but giving the
highest priority to main().

> If I try 'hbmk2 a.prg -shared', it works, but 
> if I try 'hbmk2 a.prg -shared -gtwvt', it tells: 
>   'Can't locate the starting procedure: 'MAIN''

It means that using -gtwvt hbmk2 switch activates sth
what forces using MAIN() as startup entry. We only have
to locate what it is and fix it. For sure you cannot
pass hbmainstd as one of linked libraries because in such
case console application will be created.

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Maurilio Longo]

Przemyslaw,

could this issue explain some of my troubles the other day?

Maurilio.



-- 
 __
|  |  | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Hi,

>> hbmk2 behaves the exact same for mingw and mingw64, 
>> yet it doesn't work for mingw64 and does for mingw.
> 
> This problem was exploited in different MINGW version.
> Not in all ones.
> Seems that now HBMK2 is tuned only for some chosen MinGW
> versions.

There is nothing special done for mingw in hbmk2, 
it uses the .c stub along the same lines as hbmk 
script.

Command line is clean from tricks. The only 
"special" thing done is '-mwindows' option.

Here is the link command:
   x86_64-w64-mingw32-gcc.exe C:\Users\vszakats\AppData\Local\Temp\a.o 
C:\Users\vszakats\AppData\Local\Temp\hbmk_oiiufu.o-mwindows 
-Wl,--start-group -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage 
-lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd 
-lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr 
-lhbpp -lhbcommon -lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -lwinspool 
-lcomctl32 -lcomdlg32 -lshell32 -luuid -lole32 -loleaut32 -lmpr -lwinmm 
-lmapi32 -limm32 -lmsimg32 -lwininet -lhbpcre -lhbzlib  -Wl,--end-group -oa.exe 
-LF:/devl/hb20/lib/win/mingw64

>> So either it's just a coincidence that mingw works, 
>> and there is hbmk2 bug, or there is a difference 
>> in either in Harbour mingw64 builds or mingw64 
>> itself.
> 
> I noticed differences between different mi...@32
> releases so it's nothing amazing that they may
> exist also between 32 and 64 bit MinGW versions.

Yes, it seems there is something here to deal with.

>> .c stub rightly issues hb_forceLinkMainWin() in 
>> both cases, which should be enough to pull WinMain().
> 
> It not a problem of linking WinMain() but giving the
> highest priority to main().
> 
>> If I try 'hbmk2 a.prg -shared', it works, but 
>> if I try 'hbmk2 a.prg -shared -gtwvt', it tells: 
>>  'Can't locate the starting procedure: 'MAIN''
> 
> It means that using -gtwvt hbmk2 switch activates sth
> what forces using MAIN() as startup entry. We only have
> to locate what it is and fix it. For sure you cannot
> pass hbmainstd as one of linked libraries because in such
> case console application will be created.

The only difference is in .c stub content, here it is in 
diff form:
---

 HB_FUNC_EXTERN( MAIN );
+HB_FUNC_EXTERN( HB_GT_WVT );
+
+HB_EXTERN_BEGIN
+void hb_forceLinkMainWin( void );
+HB_EXTERN_END

 void _hb_lnk_ForceLink_hbmk2( void )
 {
HB_FUNC_EXEC( MAIN );
+   HB_FUNC_EXEC( HB_GT_WVT );
+
+   hb_forceLinkMainWin();
 }

 #include "hbinit.h"

 HB_CALL_ON_STARTUP_BEGIN( _hb_hbmk_setdef_ )
+   hb_vmSetDefaultGT( "WVT" );
hb_vmSetLinkedMain( "MAIN" );
 HB_CALL_ON_STARTUP_END( _hb_hbmk_setdef_ )
---

Does it show anything to you?

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

Fixed:
  2010-03-13 03:18 UTC+0100 Viktor Szakats

Brgds,
Viktor

On 2010 Mar 12, at 15:21, Viktor Szakáts wrote:

> Hi,
> 
>>> hbmk2 behaves the exact same for mingw and mingw64, 
>>> yet it doesn't work for mingw64 and does for mingw.
>> 
>> This problem was exploited in different MINGW version.
>> Not in all ones.
>> Seems that now HBMK2 is tuned only for some chosen MinGW
>> versions.
> 
> There is nothing special done for mingw in hbmk2, 
> it uses the .c stub along the same lines as hbmk 
> script.
> 
> Command line is clean from tricks. The only 
> "special" thing done is '-mwindows' option.
> 
> Here is the link command:
>   x86_64-w64-mingw32-gcc.exe C:\Users\vszakats\AppData\Local\Temp\a.o 
> C:\Users\vszakats\AppData\Local\Temp\hbmk_oiiufu.o-mwindows 
> -Wl,--start-group -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage 
> -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd 
> -lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro 
> -lhbcplr -lhbpp -lhbcommon -lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 
> -lwinspool -lcomctl32 -lcomdlg32 -lshell32 -luuid -lole32 -loleaut32 -lmpr 
> -lwinmm -lmapi32 -limm32 -lmsimg32 -lwininet -lhbpcre -lhbzlib  
> -Wl,--end-group -oa.exe -LF:/devl/hb20/lib/win/mingw64
> 
>>> So either it's just a coincidence that mingw works, 
>>> and there is hbmk2 bug, or there is a difference 
>>> in either in Harbour mingw64 builds or mingw64 
>>> itself.
>> 
>> I noticed differences between different mi...@32
>> releases so it's nothing amazing that they may
>> exist also between 32 and 64 bit MinGW versions.
> 
> Yes, it seems there is something here to deal with.
> 
>>> .c stub rightly issues hb_forceLinkMainWin() in 
>>> both cases, which should be enough to pull WinMain().
>> 
>> It not a problem of linking WinMain() but giving the
>> highest priority to main().
>> 
>>> If I try 'hbmk2 a.prg -shared', it works, but 
>>> if I try 'hbmk2 a.prg -shared -gtwvt', it tells: 
>>> 'Can't locate the starting procedure: 'MAIN''
>> 
>> It means that using -gtwvt hbmk2 switch activates sth
>> what forces using MAIN() as startup entry. We only have
>> to locate what it is and fix it. For sure you cannot
>> pass hbmainstd as one of linked libraries because in such
>> case console application will be created.
> 
> The only difference is in .c stub content, here it is in 
> diff form:
> ---
> 
> HB_FUNC_EXTERN( MAIN );
> +HB_FUNC_EXTERN( HB_GT_WVT );
> +
> +HB_EXTERN_BEGIN
> +void hb_forceLinkMainWin( void );
> +HB_EXTERN_END
> 
> void _hb_lnk_ForceLink_hbmk2( void )
> {
>HB_FUNC_EXEC( MAIN );
> +   HB_FUNC_EXEC( HB_GT_WVT );
> +
> +   hb_forceLinkMainWin();
> }
> 
> #include "hbinit.h"
> 
> HB_CALL_ON_STARTUP_BEGIN( _hb_hbmk_setdef_ )
> +   hb_vmSetDefaultGT( "WVT" );
>hb_vmSetLinkedMain( "MAIN" );
> HB_CALL_ON_STARTUP_END( _hb_hbmk_setdef_ )
> ---
> 
> Does it show anything to you?
> 
> Brgds,
> Viktor
> 

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Przemysław Czerpak]

On Sat, 13 Mar 2010, Szak�ts Viktor wrote:
> Fixed:
>   2010-03-13 03:18 UTC+0100 Viktor Szakats

Thank you very much.
So it was stupid typo which exploited the same problem as in few 32bit
MinGW builds I tested. MAIN() in linked code enables automatically
console application.

best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

>> Finally I installed for tests GCC 4.5 (devel version)
>> and in C++ mode with -flto it gives also better results
>> then in C mode so it's potentially the fastest code.
>> I have to say that I vary like how the meta code is
>> implemented. Unlike other compilers GCC can be used
>> with LTO without any complicated settings and programmer
>> can easy control if he wants or not link time optimization
>> using one link time switch.
> 
> Sounds good, I will try 4.5.0 a bit later.

Tried. But.. -flto is not available in current mingw-w64 
and Equation Solution 4.5.0 builds :(

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Mindaugas Kavaliauskas]

Hi,



../../../sddfb.c: In function ‘fbDisconnect’:
../../../sddfb.c:181:4: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
../../../sddfb.c: In function ‘fbOpen’:
../../../sddfb.c:209:4: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
../../../sddfb.c:219:4: warning: dereferencing type-punned pointer will break 
strict-aliasing rules

This is also danger casting though it should work if void * is large enough
to hold FB handlers. Anyhow it's potential problem so it should be fixed.


I've added protection for this, see line 100, but I'm going to fix this 
(and other similar issues) in the nearest future.



Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Massimo Belgrano]

Different order of c compiler for xharbour  by xailer
http://xailer.info/esp/?p=179

Embarcadero is working to 64 bit borland c++
http://edn.embarcadero.com/article/39174


2010/3/9 Maurilio Longo :
> Hi,
>
> which is the harbour recommended C compiler for the windows platform?
>
> best regards.
>
> --
>  __
> |  |  | |__| Maurilio Longo
> |_|_|_|| farmaconsult s.r.l.
>
>
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



-- 
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

> Different order of c compiler for xharbour  by xailer
> http://xailer.info/esp/?p=179

It's not that much different, only that they seem to 
rank Pelles C higher than us.

Pelles C is good in features, easy to use, but it's 
full of serious bugs (and nobody's bug reports 
were answered since last years August, apparently 
because the author doesn't seem to be around since 
then), and the code generated is among the slowest. 
It's more of less equivalent to BCC in this regard.

So for users concerned about execution speed and 
reliability the position between MinGW and MSVC 
is very much overstated.

The rest of the rank is okay. I'd only leave 
LCC and DMC off of it, since they are pretty much 
(or completely) dead products.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] recommended C compiler for Win

[Viktor Szakáts]

> Different order of c compiler for xharbour  by xailer
> http://xailer.info/esp/?p=179

Few more points to make after reading the article in translator:

- They ranked Pelles C the first, but they forgot to 
  measure execution speed.
- In the article they worry about MSVC being abandoned as free 
  product, but in fact the same can happen with Pelles C in 
  one way or another. (ie. it's already abandoned, since it's 
  not updated)
- Harbour users and developers _do_ use mingw, so for us 
  (compared with xhb users) it's not alien.
- As I mentioned here a few times (and as it's documented 
  in INSTALL), MSVC 2008 compiler tools are now included in 
  Windows SDK 7, which means it's easy to use in a compact 
  package for x86 and x64 development.
  I doubt MS would pull it as free tool if they decided to 
  bundle it with SDK and given current trends in OS/compiler 
  business. (though of course nobody can guarantee it, just 
  like for any other non-open source compilers, including 
  Pelles C)

This leaves MinGW and MSVC the leading choices for Harbour. 

[ BTW, the article is from 2009 April, so at that time 
they couldn't predict SDK 7 and the apparent stall in 
Pelles C development. ]

Of course it's always good to have more options, that's 
why we also support watcom, icc, pocc and bcc as well. 
Anyhow for real work these are less suitable at the moment.

As for BCC64, if they make it available without much 
trouble (and it also works properly), we can add support 
for it easily in Harbour.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour