"Michel Fortin" <michel.fortin@michelf.com> wrote in message news:j7h5gp$2d7n$1@digitalmars.com...
>
> I think what D needs to handle that is some pragma to manually specify the mangled name of a given function. Why would you need macros?
>

I've got a patch to do this, in the pragma_mangle branch of my fork.  One day I'll get around to fixing it up and making a pull request.

On 2011-10-17 13:41:14 +0000, Jacob Carlborg <doob@me.com> said:

> On 2011-10-17 14:01, Michel Fortin wrote:
>> On 2011-10-17 10:21:45 +0000, Sean Kelly <sean@invisibleduck.org> said:
>> 
>>> There's also the occasional issue of something that doesn't translate
>>> into D. As one slightly weird example, some of the the Posix routines
>>> in OSX have alternates with odd suffixes like "$2003" that are the
>>> versions which should be called on newer versions of the OS. I'm still
>>> not sure of the best way to handle this, since D doesn't have macros.
>> 
>> I think what D needs to handle that is some pragma to manually specify
>> the mangled name of a given function. Why would you need macros?
> 
> Perhaps the macro is used to determine if "foo" or "foo$2003" is supposed to be called, based on some condition.

Indeed. The condition is which OS release you're targeting. That can be accomplished today through static ifs. Although it'd be a little more verbose since you'd have to repeat the function prototype.

If we had a way to do conditional attributes in D it'd be awesome for this use case. It could work this way for instance:

	static if (MAC_OS_X_VERSION_MIN_REQUIRED == 10.5)
		@deprecated_in_os_x_10_5 = deprecated;
	else
		@deprecated_in_os_x_10_5 = /* nothing */;

	@deprecated_in_os_x_10_5
	void some_function_deprecated_in_os_x_10_5();	
Or this way for the special mangled names:

	static if (MAC_OS_X_VERSION_MIN_REQUIRED == 10.5)		@darwin_alias(name) = pragma(symbol_name, name ~ "$UNIX2003");
	else
		@darwin_alias(name) = pragma(symbol_name, name);

	@darwin_alias("fwrite")
	size_t fwrite(const void * /*__restrict*/, size_t, size_t, FILE * /*__restrict*/);

Internally, when the compiler sees @darwin_alias("fwrite") it just replaces it with the attributes @darwin_alias was supposed to be. Note that I'm *not* proposing a macro system: this would work at the semantic level as a special kind of attribute.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Well then my vote goes for "let's do it". Simple bindings can be started right away, probably by copying from dsource bindings and doing any modifications necessary.

For non-trivial C headers we can discuss them here methinks.

I like it!  :)

+1 Let's do it!

Am 17.10.2011 12:21, schrieb Sean Kelly:
> On Oct 16, 2011, at 7:02 PM, Walter Bright wrote:
>>
>> The CAPI Manifesto
>> ------------------
>>
>> CAPI is a collection of C header files to publicly available C libraries
>> and their translations to D. The idea is that if, in C, to interface to a library
>> one would write:
>>
>>    #include "foo.h"
>>
>> then the corresponding D code would look like:
>>
>>    import foo;
>
> If the C header file has a name that is a D keyword, an underscore will be appended to the D module name.  If a C type name matches a C function name (stat), the type name will have a "_t" appended.
>
> There's also the occasional issue of something that doesn't translate into D.  As one slightly weird example, some of the the Posix routines in OSX have alternates with odd suffixes like "$2003" that are the versions which should be called on newer versions of the OS.  I'm still not sure of the best way to handle this, since D doesn't have macros.
>

What about function-like macros, e.g. the Linux/POSIX cmsg stuff (CMSG_FIRSTHDR(), CMSG_NXTHDR(), CMSG_LEN() etc) needed to use functions like recvmsg() and sendmsg()?

Will there be a direct D translation of the functionality or will they be omitted completely?

Cheers,
- Daniel

On 10/17/2011 1:24 PM, Daniel Gibson wrote:
> What about function-like macros, e.g. the Linux/POSIX cmsg stuff
> (CMSG_FIRSTHDR(), CMSG_NXTHDR(), CMSG_LEN() etc) needed to use functions like
> recvmsg() and sendmsg()?
>
> Will there be a direct D translation of the functionality or will they be
> omitted completely?

Consider:

   #define FOO(x)  bar((x) + 1)

Do this:

   int FOO()(int x) { return bar(x) + 1; }

Note that it's a function template with no template parameters. This will enable it to be "header only" and not require linking to some library to resolve FOO().

"Regan Heath" <regan@netmail.co.nz> wrote in message news:op.v3h9w20554xghj@puck.auriga.bhead.co.uk...
>I like it!  :)

vote++

On 17/10/11 10:33 PM, Walter Bright wrote:
> On 10/17/2011 1:24 PM, Daniel Gibson wrote:
>> What about function-like macros, e.g. the Linux/POSIX cmsg stuff
>> (CMSG_FIRSTHDR(), CMSG_NXTHDR(), CMSG_LEN() etc) needed to use
>> functions like
>> recvmsg() and sendmsg()?
>>
>> Will there be a direct D translation of the functionality or will they be
>> omitted completely?
>
> Consider:
>
> #define FOO(x) bar((x) + 1)
>
> Do this:
>
> int FOO()(int x) { return bar(x) + 1; }
>
> Note that it's a function template with no template parameters. This
> will enable it to be "header only" and not require linking to some
> library to resolve FOO().

int FOO()(int x) { return bar(x + 1); }

would probably work better :-)

+1 for CAPI btw.

With D being binary compatible with C, i don't know why we worry on such things.
Wasn't being able to access C libraries the point? If it wasn't, what is the worthwhile point for this constraint?
Wouldn't (sorry for the poor horse) separate compilers solve the most problems (if not all) we face on these issues?
C never changes and every compiler vendor have an implementation.

--
import anyapi; // anyapi would be a D module or a C header (anyapi.h...) in directory paths.
--

Structs are pod in both languages.
Matching of the standard types is something we can take care of with documentation (RTFM)
and with compiler errors generated (when we call functions from the other language).

Sorry once again if this should sound stupid or impossible to implement (if so, someone please enlighten me), it probably is because everytime we open this discussion i feel i am the only one seeing the big picture, the potential of D.

On Mon, 17 Oct 2011 05:02:52 +0300, Walter Bright <newshound2@digitalmars.com> wrote:

> Brad and I were talking about some D code that needed openssl support, when we ran into the same old problem:
>
> No D files corresponding to the openssl C .h files.
>
> It's not that these are a big problem to create, it's just that they are not done, and it tends to turn off people from using D. D is binary API compatible with C, but only with a corresponding D import file. This, out of the box, makes D *harder* to use than C.
>
> Lots of people roll their own, but that work is hard to find and haphazard.
>
> This problem keeps coming up again and again.
>
> So I propose creating, on github.com/D-Programming-Language, a new repository called CAPI.
>
> The CAPI Manifesto
> ------------------
>
> CAPI is a collection of C header files to publicly available C libraries
> and their translations to D. The idea is that if, in C, to interface to a library
> one would write:
>
>     #include "foo.h"
>
> then the corresponding D code would look like:
>
>     import foo;
>
> Each C .h file would have a corresponding .d file. Each C directory would
> have a corresponding D directory, for example:
>
>     #include "bar/foo.h"   // C
>
>     import bar.foo; // D
>
> The top level directory of each library will have two subdirectories:
>
>     C/
>     D/
>
> and there will be a one-to-one correspondence of files and directory structure
> between them.
>
> The D import files will be a rote translation of the corresponding C .h file.
> No attempt will be made to fix, improve, or extend the C api. No attempt will
> be made to duplicate the C documentation, or replace it in any way. There
> will be no unittests. Every effort will be made to avoid needing any D specific
> binary files.
>
> When an updated version of the C header files becomes available, those will
> get checked into the C subdirectory tree, and then the corresponding D files
> will get updated.
>
> Version tags used must match the version tags used by the C API files.
>
> The license used for the D versions should match the C ones, as they are a
> derived work.