On Sat, Jun 15, 2013 at 1:03 AM, Carsten Haitzler <[email protected]> wrote:
> On Fri, 14 Jun 2013 13:01:23 -0300 Felipe Magno de Almeida
> <[email protected]> said:
>
>> On Fri, Jun 14, 2013 at 12:52 PM, Carsten Haitzler
>> <[email protected]>wrote:
Hi Carsten,
[snip]
>> With macros I can't define local variables or structs, and with C++ I'm
>> also restricted
>
> well you can define local vars in macros.. but those method macros don't do
> that. eo uses varargs. so:
>
> eo_do(obj, efl_color_set(10, 20, 30, 40));
>
> ACTUALLY is
> eo_do(obj, EFL_COLOR_SET, 10, 20, 30, 40);
>
> the macro just makes the stream of args look function-like thus making it more
> convenient and pretty...
I don't think you understand what I mean. What i mean is that when you define
a macro efl_color_set, even in C I can't do this simple thing:
void foo()
{
int efl_color_set;
}
or even
struct foo
{
int efl_color_set;
};
Which means that this macro is not at all like a function, because macros
don't obey scopes as functions do. I know, in C the scopes are quite limited
because of the lack of proper namespaces (there's only two free scopes,
the global one, and the structs one). But functions only clash with the global
scope, and macros clash with *all scopes*. So they are not the same at all
in C, and are even more nightmarish in C++. Just see the problems that
are common place from min/max and most Win32API (CreateFile et al)
from windows.h
> it ALSO happens to so some magic to force typechecking
> of args too (and since its a macro.. argument count as well).
Yes, I've read the code, and I found it quite interesting the typechecking.
The only thing I'm worried about is defining lower-case keywords,because
that's what they are since they prohibit all uses of the same identifier
in *any context*, is what I believe to be problematic. Upper-cases are
a de facto namespace for macros already in C and C++, and I hope that
E uses that or finds a way to avoid lower-case macros in another way.
Because I think it will be problematic for C code, and for C++ it will give
problems for sure because C++ uses *a lot* of code in headers because
of inline functinos and templates, which raises a lot the chance of clashing
with keywords.
>> to member-functions, classes, free-functions, basically identifiers in any
>> context which would
>> clash with efl_color_set, efl_font_set, efl_text_set, etc. And, also all
>> other
>> function names used in eo but for classes defined by third-party code to
>> which I may
>> want to interoperate now or in the future.
>
> that's why we namespace them. this is nothing new in c. yes - it affects c++.
> efl is able to be used from c+ but that comes with the cost of avoiding the
> namespace - just like everyone in c would have to do. there is no way around
> this. all the enums, macros, functions and structs - same story.
See above why enums, functions and structs are not the same as macros
at all.
[snip]
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler) [email protected]
Regards,
--
Felipe Magno de Almeida
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
