Re: Problem with G_INLINE_FUNC using microsoft compiler

[clement begue <clement begue thalesgroup com>]

Hi,
You are right, we use exactly the same compiler, so, I think the sources
I downloaded may be broken.
How do you download the sources from the cvs server directly, not using
the snapshots? I searched a bit about soing such thing and I couldn't find
any real help about it. The Bonsai or either the viewcvs interface does
not offer to download all the files at once (or again, I didn't open my
eyes), so, I really wonder how I am supposed to do.
If you could tell me how to download directly from CVS, it would be
great, we could be talking about the same files...
So, is it good to download the snapshots or not? What should we do
to be sure to be working on the right sources?

Regards,
Clément

Hans Breuer a écrit :

On 22.03.2005 15:45, clement begue wrote:
>
> Hans Breuer a écrit :
[...]
>>It should work out of the box (and does for me compiled against recent
>>GLib cvs). Though there was some change needed, related and may exactly
>>what's breaking your build. Try replacing in geometry.c
>>
To be more precise: I'm probably using the *same* version of the M$
compiler and it works for me.

D:\graph\dia2\bin>cl
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

>>#define G_IMPLEMENT_INLINES
>>
>>with:
>>
>>#undef G_INLINE_FUNC
>>#define G_INLINE_FUNC extern
>>
>
>
> It is still written this way in properties.c, as I saw it defined there, I
> thought it was the same everywhere...
Sorry: parser error.

> I didn't use the last Glib, so, there may be different definitions in the
> last version, correcting this issue so that you don't need anymore to define
> this, I'll try to see if it gets better with a newer version.
>
The second form was there quite a long time withot causing any problems.
So changing to a newer GLib shouldn't be necessary.

> I also had some errors from interface.c,
> lines 704 :       if (strncmp(tool_data[i].icon_data, "GdkP", 4) == 0) {
> -> added [0] after .icon_data (had error of different indirection levels, the
> address given this way should be the same than without [0], but the compiler
> understands it fine
> and same at line 707 :  p = gdk_pixbuf_new_from_inline(-1,
> tool_data[i].icon_data[0], FALSE, NULL);
>
Maybe the concrete snapshot you are using is much more boken than I thought.
My version from cvs does not have this, but while I got it there where
some strange broken stuff in it, like:

http://cvs.gnome.org/viewcvs/dia/lib/autoroute.c?r1=1.8&r2=1.9

> Is the microsoft compiler annoying on such things? I don't remeber that gcc
> would forgive this kind of errors.
>
Huh? Either it is an error, so it should *not* be forgiven. Or it is not,
so both compilers should compile it.
The recently most annoying thing with gcc versus msvc is that gcc assumes
C99 rules while msvc is only C89. The special error which often slips
through is declaring variables anywhere in the code, and not at the
start of a block - as required by C89.

But I also should mention glib/msvc_recommended_pragmas.h which gets 'force
included' into Dia, The GIMP, Gtk+ etc. and in fact enforces better
programming style than the standard gcc does. It intentionally turns some
warnings into errors to catch as much bugs as possible during compile time.

        Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert
_______________________________________________
Dia-list mailing list
Dia-list gnome org
http://mail.gnome.org/mailman/listinfo/dia-list
FAQ at http://www.gnome.org/projects/dia/faq.html
Main page at http://www.gnome.org/projects/dia