Re: [ft-devel] Indirection issue with 'ft_trace_levels'
On 05/09/2018 11:24, Werner LEMBERG wrote: After updating from git master this morning, I'm finding a compilation error in 'builds/windows/ftdebug.c' when I try to build with MSVC. [...] error C2372: 'ft_trace_levels' : redefinition; different types of indirection Thanks for the report; this should be fixed now in git. Please retry. Yes, that now seems to be building fine again Werner - thanks ! John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Indirection issue with 'ft_trace_levels'
On 04/09/2018 16:43, Alexei Podtelezhnikov wrote: ftbase.c wraps ftlcdfil.c and many others. You are not suppose to compile all C files. Are you using builds/windows/vc2010/freetype.vcxproj ? Oops... I'm actually using my own VC project file but you're right - I'd accidentally included a couple of files which already get built via ftbase.c BTW ... On 04/09/2018 14:49, Alexei Podtelezhnikov wrote: I do not think the special windows version is needed actually. It only tee's the output to Windows debugger, which can be done with "#ifdef WIN32" or something.I will try that. If I abandon 'builds/windows/ftdebug.c' and I replace it with 'src/base/ftdebug.c', that does solve the compiler error that I originally reported (C2372). Thanks, John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Indirection issue with 'ft_trace_levels'
On 04/09/2018 14:49, Alexei Podtelezhnikov wrote: After updating from git master this morning, I'm finding a compilation error in 'builds/windows/ftdebug.c' when I try to build with MSVC. I do not think the special windows version is needed actually. It only tee's the output to Windows debugger, which can be done with "#ifdef WIN32" or something.I will try that. Thanks Alexei. As a separate (unrelated) issue, MSVC now gives me these linker warnings which I don't remember seeing previously:- ftbase.obj : warning LNK4006: _FT_Library_SetLcdGeometry already defined in ftlcdfil.obj; second definition ignored ftbase.obj : warning LNK4006: _FT_Get_X11_Font_Format already defined in ftfntfmt.obj; second definition ignored ftbase.obj : warning LNK4006: _FT_Library_SetLcdFilter already defined in ftlcdfil.obj; second definition ignored ftbase.obj : warning LNK4006: _FT_Get_Font_Format already defined in ftfntfmt.obj; second definition ignored ftbase.obj : warning LNK4006: _ps_property_get already defined in ftpsprop.obj; second definition ignored ftbase.obj : warning LNK4006: _FT_Library_SetLcdFilterWeights already defined in ftlcdfil.obj; second definition ignored ftbase.obj : warning LNK4006: _ps_property_set already defined in ftpsprop.obj; second definition ignored ftbase.obj : warning LNK4006: _ft_lcd_padding already defined in ftlcdfil.obj; second definition ignored ftbase.obj : warning LNK4006: _FT_Palette_Set_Foreground_Color already defined in ftcolor.obj; second definition ignored ftbase.obj : warning LNK4006: _FT_Palette_Select already defined in ftcolor.obj; second definition ignored ftbase.obj : warning LNK4006: _FT_Palette_Data_Get already defined in ftcolor.obj; second definition ignored The warnings appear when linking either a Debug build or a Release build (so they're not connected to the issue with 'ftdebug.c') John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Indirection issue with 'ft_trace_levels'
After updating from git master this morning, I'm finding a compilation error in 'builds/windows/ftdebug.c' when I try to build with MSVC. It gives me an error at line 114:- /* array of trace levels, initialized to 0 */ int ft_trace_levels[trace_count]; // <--- compilation fails here !!! and the error is:- error C2372: 'ft_trace_levels' : redefinition; different types of indirection AFAICT ftdebug.c itself hasn't changed since I last built freetype2 - so has there maybe been a change to 'ft_trace_levels' somewhere which needs to get reflected here? If this doesn't ring any immediate bells with anyone I'll do a bit more digging... John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC
On 21/05/2018 09:33, Nikolaus Waxweiler wrote: Everything you got ;) Gosh, this is embarrassing... I just tried a CMake build for you and it's now working perfectly. It generates the VC project files with no errors at all !! Regarding the MSVC build though, I mentioned previously that I don't see any errors when building freetype itself. It's only later that the error occurs - when I try to use the (statically built) library in some other project. In that case (if I built without enabling Intrinsic Functions), the linker will then complain that it can't find '_BitScanReverse()' John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC
On 21/05/2018 08:20, Nikolaus Waxweiler wrote: I actually use the very latest MSVC to build freetype 2.9.1 for freetype-py and didn't have any problems. Can you post the error log? Hi Nikolaus - do you mean the error log from CMake or the error from MSVC ? John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC
On 19/05/2018 13:07, Alexei Podtelezhnikov wrote: FreeType vs2010 project makes both static and dynamic and turns on intrinsics. I do not know how to backport it to vs2005. How much need is there for it really? There won't be much need for VS2005 these days (in fact, even I only use it for 1 project). In theory though, CMake can generate MSVC project files for more recent versions of Visual Studio (which I guess would also have the 'Intrinsic' value set incorrectly). Having said that, I just tried building with CMake and VC14 (Visual Studio 2015) and I was surprised to find that the CMake build failed (apparently while generating the file:- 'CompilerIdC.vcxproj') I haven't looked into it in any depth so it could easily be a configuration issue at my end. Or is VS2010 the latest version that can build freetype2? John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC
On 18/05/2018 21:39, Nikolaus Waxweiler wrote: Do you have cmake installed? If so and you're bored, what happens when you use it to generate a project file? Hi Nikolaus, The project file generated by cmake has Intrinsic Functions set to "no" (so it'll also create the problem I reported). Having said that, I need to be clearer about the problem... freetype itself gets built as a static library - and as such, the fact that _BitScanReverse is missing doesn't show up (at that stage). It's only later (when I try to use freetype in some other project) that the linker suddenly complains. So the bottom line is that freetype's own projects (including the project you generate from cmake) all now need to set "yes" for the option to enable Intrinsic Functions. Hope that makes sense, John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC
On 18/05/2018 15:30, Alexei Podtelezhnikov wrote: Do you use our stock project file? Could there be an option to enable/disable intrinsics? Please investigate it. Oh wow... very well spotted ! I'm using my own VC project file where instrinsic functions were disabled. Enabling that option allows me to build without errors - even from the earlier git version (i.e. before Werner added the test for VS2013). So with intrinsic functions enabled, that test isn't needed (though the underscored __inline is still needed, of course...) I don't use your stock projects but it looks like the one for VC2010 has intrinsics enabled. AFAICT though, the others are simply using the default setting which I'd assume is (most likely) disabled. Thanks again, John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC
On 18/05/2018 14:00, Alexei Podtelezhnikov wrote: Actually since VS2005 https://en.wikipedia.org/wiki/Find_first_set and references therein. Hmmm, the plot thickens... I'm using VS2005 which doesn't find it - although 'intrin.h' defines it like this:- __MACHINEIW64(unsigned char _BitScanReverse(unsigned long* Index, unsigned long Mask)) So I wonder if it was initially only available for 64-bit compilation, then later got ported to 32-bit?? Also, it's MSDN entry doesn't specify that any link lib is needed so I've been assuming it gets implemented as a macro (?) John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC
Seems to be building fine again now, thanks... On 18/05/2018 09:58, Werner LEMBERG wrote: I see a question about `BitScanReverse' on stackoverflow asked in December 2011... https://stackoverflow.com/questions/8626891/bitscanforward64-issue-in-visual-studio-11-developer-preview On the other hand, it doesn't really matter :-) Ah, okay - I was only going by the fact that its MSDN entry is dated early in 2013 so I assumed it (maybe?) got introduced towards the end of VS2012. Thanks for all your help with this, John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC
On 17/05/2018 18:41, Werner LEMBERG wrote: However, MSVC-8 seems happy with this underscored variant, if that helps... static __inline FT_Int32 Fixed in git, thanks. Thanks Werner - another heads-up though... Fixing that issue has simply highlighted another problem five lines later, namely:- _BitScanReverse ( %where, x ); Bear in mind that Visual Studio didn't introduce _BitScanReverse until VS2013 (MSDN says VS2010 but I think that's wrong). Either way, the above change has made freetype2 unbuildable now with anything earlier :-( John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC
On 17/05/2018 06:10, John Emmas wrote: I seem to have several other libraries which use inline (i.e. the non-underscored version) and they're all building correctly. So could it be that freetype2 has re-defined it somehow? Or maybe it #includes a file somewhere that re-defines the meaning of inline ?? Some extra information's come to light (from this MSDN article...) https://msdn.microsoft.com/en-us/library/bw1hbe6y.aspx Quote: " The *inline* keyword is available only in C++. The |__inline| and |__forceinline| keywords are available in both C and C++ " I think that explains it !! John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC
On 16/05/2018 19:38, Alexei Podtelezhnikov wrote: However, MSVC-8 seems happy with this underscored variant, if that helps... static __inline FT_Int32 Do you happen to know what _MSC_VER introduced __inline? I'm afraid I don't but I realised something interesting this morning. I seem to have several other libraries which use inline (i.e. the non-underscored version) and they're all building correctly. So could it be that freetype2 has re-defined it somehow? Or maybe it #includes a file somewhere that re-defines the meaning of inline ?? John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC
Arkady Shapkin's commit #84eebf4802 (from May 12th) has broken a compilation that I need to do with MSVC-8. It's because of introducing this change at line 365 of 'freetype/internal/ftcalc.h':- static inline FT_Int32 However, MSVC-8 seems happy with this underscored variant, if that helps... static __inline FT_Int32 Just a heads-up, John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Pango error due to #including FT_ERRORS_H
On 20/01/2016 20:04, Werner LEMBERG wrote: Fixed in git. Thanks for both the report and the analysis. Thanks Werner - pango is building normally again, this morning! ;) John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Pango error due to #including FT_ERRORS_H
On 20 Jan 2016, at 14:26, John Emmas wrote: > On 20 Jan 2016, at 14:12, Werner LEMBERG wrote: > >> >> Try switching off the `precompiled header files' option. >> > > Thanks for the quick reply Werner. > > I'll check - but i'm 99% certain that I never use precompiled headers... :-( > Yeah - precompiled headers are turned off for both pango and freetype2. Hopefully some other MSVC user can confirm if they see the same problem. John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Pango error due to #including FT_ERRORS_H
I posted this to the pango mailing list a few minutes ago but it just occurred to me that this list might be better... I updated freetype2 a few days ago (i.e. I pulled the latest source code from git) and I've just realised that pango fails to build now (with MSVC). The problem is at these lines, round about line 540 of 'pango/pangoft2.c':- static const ft_error_description ft_errors[] = #include FT_ERRORS_H #undef FT_ERRORDEF #undef FT_ERROR_START_LIST #undef FT_ERROR_END_LIST ft_error_description *found = /* <-- ERROR HERE !!! */ bsearch (, ft_errors, G_N_ELEMENTS (ft_errors), sizeof (ft_errors[0]), ft_error_compare); MSVC gives me:- 'error C2275: 'ft_error_description' : illegal use of this type as an expression'. To be honest, I suspect that the actual error might be a few lines earlier - i.e. static const ft_error_description ft_errors[] = #include FT_ERRORS_H My best guess is that something got changed somewhere in 'freetype/fterrors.h'. It does look like something got done (about a week ago) to remove underscores from some macro names but I'm not sure why that would cause this problem. Can anyone hazard a guess at what might be wrong? Thanks, John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Pango error due to #including FT_ERRORS_H
On 20 Jan 2016, at 14:12, Werner LEMBERG wrote: > >> My best guess is that something got changed somewhere in >> 'freetype/fterrors.h'. It does look like something got done (about >> a week ago) to remove underscores from some macro names but I'm not >> sure why that would cause this problem. Can anyone hazard a guess >> at what might be wrong? Thanks, > > Try switching off the `precompiled header files' option. > Thanks for the quick reply Werner. I'll check - but i'm 99% certain that I never use precompiled headers... :-( John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Announcing FreeType version 2.6
On 09/06/2015 05:42, Werner LEMBERG wrote: FreeType 2.6 has been released. It is available from http://savannah.nongnu.org/download/freetype/ or http://sourceforge.net/projects/freetype/files/ I don't suppose it'll be available from git just yet - but this prompted me to take a look at the various git branches. AFAICT nobody's created a stable branch in git since version 2.1. Is that a deliberate decision or am I synced to the wrong repo maybe?? I'm currently synced to:- git://git.sv.nongnu.org/freetype/freetype2.git I can also see a branch there called STABLE. How does that work?? Does it always reflect the most recent stable branch somehow? John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Release numbering
I only noticed this morning that a new release got made at the end of December (ver 2.5.5). How does the numbering scheme work with Freetype? Is 2.5.5 a 'Release' or does Freetype use a similar scheme to other open-source libraries - where even numbers correspond to releases and odd numbers to ongoing (development) versions? Just curious to find out Thanks, John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Release numbering
On 17/01/2015 13:30, Alexey Podtelezhnikov wrote: We don't release unstable versions. Thanks Alexey - so will there (eventually) be a branch in git which corresponds to Release v2.5.x? Or does the branch called STABLE automatically reflect whatever happens to be the latest stable release? John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Build errors with MSVC
On 23/10/2014 07:47, Werner LEMBERG wrote: Another suggestion is to simply have eight constants: CFF_CONFIG_OPTION_DARKENING_PARAMETER_X1 500 CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y1 400 CFF_CONFIG_OPTION_DARKENING_PARAMETER_X2 1000 CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y2 275 CFF_CONFIG_OPTION_DARKENING_PARAMETER_X3 1667 CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y3 275 CFF_CONFIG_OPTION_DARKENING_PARAMETER_X4 2333 CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y4 0 John, does this work if you pass those values to SET_DARKENING_PARAMETERS_0? Here's a patch. Thanks Werner, By a stroke of bad luck I'm tied up with a family function today but I'll try this as soon as possible (latest, tomorrow). John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Build errors with MSVC
On 23/10/2014 19:02, Werner LEMBERG wrote: I can confirm that the patch works on MSVC 2010, Win7, building Release x64. Thanks for confirmation, I've applied the patch to the git repository. I just managed to apply the patch here too and I'm happy to confirm that it builds fine with VS2005 (VC8). Thanks for everyone's help with this! John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Build errors with MSVC
Hi guys, I updated freetype from git master (this morning) and I'm getting these errors when compiling cff.c (technically, when compiling cffobjs.c):- src/cff/cffobjs.c(1095) : warning C4003: not enough actual parameters for macro 'SET_DARKENING_PARAMETERS_0' src/cff/cffobjs.c(1095) : error C2059: syntax error : '' src/cff/cffobjs.c(1095) : error C2059: syntax error : ';' src/cff/cffobjs.c(1095) : error C2059: syntax error : ';' src/cff/cffobjs.c(1095) : error C2059: syntax error : ';' src/cff/cffobjs.c(1095) : error C2059: syntax error : ';' src/cff/cffobjs.c(1095) : error C2059: syntax error : ';' src/cff/cffobjs.c(1095) : error C2059: syntax error : ';' src/cff/cffobjs.c(1095) : error C2059: syntax error : ';' As you can see, the errors are all at line 1095 of 'src/cff/cffobjs.c'. Lines 1094 and 1095 look like this:- SET_DARKENING_PARAMETERS( driver, CFF_CONFIG_OPTION_DARKENING_PARAMETERS ); Prior to this morning's update, that same section previously looked like this AFAICT:- driver-darken_params[0] = 500; driver-darken_params[1] = 400; driver-darken_params[2] = 1000; driver-darken_params[3] = 275; driver-darken_params[4] = 1667; driver-darken_params[5] = 275; driver-darken_params[6] = 2333; driver-darken_params[7] =0; So my guess is that some kind of problem's crept in when converting all that lot to a macro. My first thought was that maybe 'ftoption.h' wasn't getting #included, so I deliberately #included it but that didn't make any difference. I then changed lines 1094 and 1095 to look like this (note that it now uses 'SET_DARKENING_PARAMETERS_0'):- SET_DARKENING_PARAMETERS_0 ( driver, 500, 400, 1000, 275, 1667, 275, 2333, 0 ); The above seems to compile successfully. So I then tried this:- SET_DARKENING_PARAMETERS_0 ( driver, CFF_CONFIG_OPTION_DARKENING_PARAMETERS ); but that gets me back to the same set of errors that I had in the first place. So I'm guessing that MSVC is objecting to something about 'CFF_CONFIG_OPTION_DARKENING_PARAMETERS'. Are there any other tests I could do that might help track this down? John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Build errors with MSVC
On 22/10/2014 17:31, Dave Arnold wrote: Might it be this bug: https://connect.microsoft.com/VisualStudio/feedback/details/718976/msvc-pr? Yeah, I think you're right Dave. I posted the same question on CodeGuru and it seems that the bug is still present, right up to VC11 - although it seems to be fixed in VC12 (i.e. VS2013). Is there anything we can do about this? It seems as if Visual Studio is one of the supported compilers for libfreetype. John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] MSVC build woes !
On 12/06/2013 22:34, Werner LEMBERG wrote: Please test the current git for the next iteration... Werner Great stuff, Werner - no warnings at all !! Thanks for all your perseverance, John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] MSVC build woes !
On 12/06/2013 10:10, Werner LEMBERG wrote: I've again disabled MSVC warning C4127 in the git repository; especially after looking at https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines I now believe that the original solution of disabling this warning completely is the right thing. Theoretically, there shouldn't be any warnings now in an MSVC build. Thanks for all your hard work Werner and for everybody's input on this. I only spotted one problem In 'ftserv.h' you've implemented the pragma like this:- #if defined( _MSC_VER ) /* Visual C++ (and Intel C++) */ /* We disable the warning `conditional expression is */ /* constant' in order to compile cleanly with the maximum */ /* level of warnings. */ #pragma warning( push ) #pragma warning( disable : 4127 ) #endif /* _MSC_VER */ // [ ... ] rest of header file #if defined( _MSC_VER ) #pragma warning( pop ) #endif But of course that doesn't work - because the 'pop' will re-enable the warning as soon as that header file finishes processing. By the time the compiler wends its way back to the original source file, warning 4127 is enabled again. The way you did it in 'ftdebug.h' works fine though. John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] MSVC build woes !
Hi guys, I noticed that these lines have recently been removed from 'ftdebug.h' #if defined( _MSC_VER ) /* Visual C++ (and Intel C++) */ /* We disable the warning `conditional expression is constant' here */ /* in order to compile cleanly with the maximum level of warnings. */ #pragma warning( disable : 4127 ) l#endif /* _MSC_VER */ I think the comment probably meant minimum level of warnings but no matter Previously (about 5 weeks ago) those lines were at about line 251. Unfortunately, removing them now produces hundreds of unnecessary warnings when building with MSVC. If it isn't possible to restore them I can suggest an alternative solution but my guess is that they've just gotten removed accidentally. Any chance of putting them back? John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] MSVC build woes !
On 11/06/2013 11:56, Werner LEMBERG wrote:
Please send me all the warnings. The removal is of temporary nature
only: I'm going to re-add this pragma as soon as I know what it
exactly suppresses (I don't have MSVC).
Hi Werner, I understand. Here's a good example to get you started. I
can find you the other instances, if necessary...
The warnings are typically caused by FT_ASSERT and take the following form:-
: warning C4127: conditional expression is constant
FT_ASSERT is defined in 'ftdebug.h' and looks like this:-
#define FT_ASSERT( condition
) \
do\
{ \
if ( !( condition )
) \
FT_Panic( assertion failed on line %d of file
%s\n, \
__LINE__, __FILE__
); \
} while ( 0 )
It usually gets called something like this:-
FT_ASSERT( some_var == some_other_var );
and wherever it gets called, I get warning 4127. MSVC is warning that
there's no point putting this in a do/while loop, since nothing ever
changes. Rather than re-instate the pragma, a better solution would be
to remove 'do' and 'while'. At first glance, it doesn't look like
there'd be any adverse effects. If you agree that removing 'do' and
'while' is the way forward, I'll find you the other occurrences. Regards,
John
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] MSVC build woes !
On 11/06/2013 15:14, Robin Watts wrote:
There is a VERY good reason for the while being there. I will try to
explain:
Imagine that you have the following code:
if (x == 0)
FT_ASSERT(some_condition);
else
return 42;
return 23;
Without the while loop, the code would expand to:
if (x == 0)
if (!some_condition)
FT_Panic( ... );
else
return 42;
return 23;
(indentation changed for clarity)
i.e. the behaviour of the code is changed for x == 0;
Thanks for the explanation Robin,
That being the case, this solution works for MSVC:-
#define FT_ASSERT( condition ) \
{\
if ( !( condition ) )
\
FT_Panic( assertion failed on line %d of file
%s\n, \
__LINE__, __FILE__ );
\
}
In fact, a similar strategy is already being used in the definition of
'FT_THROW' so I guess it should work for other compilers too.
John
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
