Michael Aaron Safyan wrote:
> I would like to hear your feedback regarding this proposal:
> http://michaelsafyan.fw.nu/publications/

Hi,
adding such features to C++ would be a good idea. Though I don't like a
header file detection extension that much, simply because IMHO there
shouldn't be the need for header files at all.

I would generally drop the header idea in C++.

Why not simply:

#import "MyLibrary"

Which simply does:

a) Link to the library
b) Get all information about the library, like exported classes
    and functions from the library itself and store them in an auto
    generated code file

So if you want to use a library you simply would have to add a single
line of code.

Andre


> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Dec 10, 5:07 pm, michaelsaf...@aim.com (Michael Aaron Safyan)
wrote:
> I would like to hear your feedback regarding this proposal:http://michaelsafyan.fw.nu/publications/

I like the exists() preprocessor function. That would make a great
addition to the language, in my opinion.

I also like the idea of specifying linkage libraries. The only problem
is that the actual linkage is also platform-defined.

I think that import/export handling would be handled, at least in some
part, by the specification of n2425, when it matures, although that is
(to date) C++-only.

I think that these are new approaches to problems that plan on being
solved in the future anyway, so it's worth considering these.
Declaring a library specification within a source file may be beyond
the scope of the C++ standard - maybe a standard extension unit should
be created to better specify the interactions of both static and
dynamic linked libraries.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andre Kaufmann wrote:
> Michael Aaron Safyan wrote:
>> I would like to hear your feedback regarding this proposal:
>> http://michaelsafyan.fw.nu/publications/
>
> Hi,
> adding such features to C++ would be a good idea. Though I don't like a
> header file detection extension that much, simply because IMHO there
> shouldn't be the need for header files at all.
>
> I would generally drop the header idea in C++.
>
> Why not simply:
>
> #import "MyLibrary"
>
> Which simply does:
>
> a) Link to the library
> b) Get all information about the library, like exported classes
>    and functions from the library itself and store them in an auto
>    generated code file
>
> So if you want to use a library you simply would have to add a single
> line of code.
>
> Andre

1.) Objective-C uses "#import", so this would break Objective-C and
Objective-C++.

2.) It would still be necessary to know whether "MyLibrary" exists
(unless this hypothetical import always succeeds), and it would still be
necessary to detect the declarations associated with the library.

3.) What you propose can be accomplished at runtime using "dlopen" or
"LoadLibrary". However, it is often necessary to know at compile-time
whether a library is available.

Thank you, though, for the feedback.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Michael Aaron Safyan wrote:
> [...]
> 1.) Objective-C uses "#import", so this would break Objective-C and
> Objective-C++.

Keeping both C and C++ in sync would restrict and delay the evolution of
C++ IMHO too much, too much discussions on both sides ;-).

> 2.) It would still be necessary to know whether "MyLibrary" exists
> (unless this hypothetical import always succeeds), and it would still be
> necessary to detect the declarations associated with the library.

A library should be 100% portable and therefore would export the same
functions on all platforms. What you unfortunately need to know is on
what platform you are compiling. So a macro WIN32 or UNIX should be
sufficient. Binding the platform on the existence on some libraries
wouldn't IMHO offer a great advantage over platform macros because:

a) Testing for the existence of different libraries needs time.
    Especially if you use your "exists" proposal in a header file,
    which is included multiple times

b) If a library e.g. pthread isn't found, it doesn't mean that you won't
    compile for multi core cpu's and it might happen that you are
    using an accidentally additionally existing "singlethread" library,
    because the pthread isn't found


> 3.) What you propose can be accomplished at runtime using "dlopen" or
> "LoadLibrary". However, it is often necessary to know at compile-time
> whether a library is available.

I like your proposals #2 and #3. I'm using a comparable proprietary
extension: #pragma comment(lib, "mylib.dll") often.

What I want is that the usage of libraries in C++ is as simple as in
e.g. .NET. You don't need a header file at compile time. All what's
necessary to simply add the library to your project.
No hassle with header files, export and import declarations simply:

#import "mylibrary.so" or #import "mylibrary.dll".
The compiler could automatically generate code from the embedded meta
information either added to the dll or available as an external file.


Regarding #3 I don't quite understand why you need an additional library
name for declarelib. What's the purpose of the library name, since all
objects are compiled to a single library ?

Why not simply:

export class MyClass {};

instead of:

class declarelib("mylib") MyClass {}; ?

> [...]

Andre

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Dec 11, 11:09 am, akfmn...@t-online.de (Andre Kaufmann) wrote:
> Why not simply:
>
> export class MyClass {};
>
> instead of:
>
> class declarelib("mylib") MyClass {}; ?
>
> > [...]
>
> Andre

If you read N2425, you'll find that it goes even further, proposing:

private:

class LibraryInternalClass;

int someSpecialHiddenFunction (int);

protected:

class SomeClass;

The idea is that private symbols are not visible outside the linking
unit. Protected and public symbols are, but a protected symbol is
guaranteed to reference the declared object within a library - a
public symbol means that all references to that symbol eventually
resolve to the same symbol, regardless of which library the came from.
For the most part, UNIX dynamic symbols are public, and Windows ones
are protected. n2425 does not define any other semantics though, such
as specifying linked libraries.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andre Kaufmann wrote:
> Michael Aaron Safyan wrote:
>> [...]
>> 1.) Objective-C uses "#import", so this would break Objective-C and
>> Objective-C++.
>
> Keeping both C and C++ in sync would restrict and delay the evolution of
> C++ IMHO too much, too much discussions on both sides ;-).

The majority of the Apple code base is implemented in Objective-C, and
Objective-C++ is a big deal for development on OS X. Breaking
Objective-C and Objective-C++ in this way, where it could be easily
avoided (simply by selecting an alternative word), would -- I suspect --
greatly displease the people at Apple as well as all corporations which
have developed applications for the Mac.

>
>> 2.) It would still be necessary to know whether "MyLibrary" exists
>> (unless this hypothetical import always succeeds), and it would still
>> be necessary to detect the declarations associated with the library.
>
> A library should be 100% portable and therefore would export the same
> functions on all platforms. What you unfortunately need to know is on
> what platform you are compiling. So a macro WIN32 or UNIX should be
> sufficient. Binding the platform on the existence on some libraries
> wouldn't IMHO offer a great advantage over platform macros because:

1.) Libraries may vary from version to version. For example, "libxml"
may add functions in one version which are not available in previous
versions, or it may even remove "deprecated" functions from newer versions.

2.) Libraries may vary from installation to installation. For example,
the presence of "WxWidgets" depends largely on whether the user has
downloaded and installed "WxWidgets" and not upon the operating system.


The presence of libraries and header files depends on more than just the
computer's operating system. It is already possible to detect the target
machine's operating system with, albeit non-standard, predefined macros.
However, since libraries and headers depend on the local configuration,
this is not sufficient.


>
> a) Testing for the existence of different libraries needs time.
>    Especially if you use your "exists" proposal in a header file,
>    which is included multiple times

1.) This testing is already done with the GNU Autotools.

2.) This testing would take less time than with the GNU Autotools,
because there is a tendency to perform unnecessary tests in the event
that a header file may later become necessary.

3.) The preprocessor already performs this test in the implementation of
"#include" as part of its decision to either a.) include the file or b.)
emit an error message.

>
> b) If a library e.g. pthread isn't found, it doesn't mean that you won't
>    compile for multi core cpu's and it might happen that you are
>    using an accidentally additionally existing "singlethread" library,
>    because the pthread isn't found

I'm not sure what you mean. If "pthread.h" isn't found, it means nothing
more than that the pthread implementation is not available.

>
>
>> 3.) What you propose can be accomplished at runtime using "dlopen" or
>> "LoadLibrary". However, it is often necessary to know at compile-time
>> whether a library is available.
>
> I like your proposals #2 and #3. I'm using a comparable proprietary
> extension: #pragma comment(lib, "mylib.dll") often.
>

I'm glad that you like those extensions. Indeed, that various compilers
already implement "#pragma library" or "#pragma comment(lib" lends
support to the "reasonableness" of this extension.

> What I want is that the usage of libraries in C++ is as simple as in
> e.g. .NET. You don't need a header file at compile time. All what's
> necessary to simply add the library to your project.
> No hassle with header files, export and import declarations simply:
>
> #import "mylibrary.so" or #import "mylibrary.dll".
> The compiler could automatically generate code from the embedded meta
> information either added to the dll or available as an external file.

With what you propose, the compiler would still have to extract the
exported symbol declarations from the library, resulting in the
equivalent of a header file. I don't see the point in discarding header
files, only to regenerate them.

I proposed that the platform-specific prefixes and suffixes be omitted
in the libraryimport syntax in order to avoid unreasonably many
different import statements for the various library file extensions.
With your example, it would be necessary to use more than one import
statement for a library, based on the platform's library naming conventions.

> Regarding #3 I don't quite understand why you need an additional library
> name for declarelib. What's the purpose of the library name, since all
> objects are compiled to a single library ?
>
> Why not simply:
>
> export class MyClass {};
>
> instead of:
>
> class declarelib("mylib") MyClass {}; ?
>

The "declarelib" keyword modifies the linkage of a symbol based on the
library in which it is or will be located. Thus it can act as both an
import and export modifier, not just an export modifier (e.g. on Windows
with Microsoft Visual C++, it would act like both
"__declspec(dllimport)" and "__declspec(dllexport)", depending on the
parameter to declarelib).


>> [...]
>
> Andre
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Sean Hunt wrote:
> On Dec 11, 11:09 am, akfmn...@t-online.de (Andre Kaufmann) wrote:
>> Why not simply:
>>
>> export class MyClass {};
>>
>> instead of:
>>
>> class declarelib("mylib") MyClass {}; ?
>>
>>> [...]
>> Andre
>
> If you read N2425, you'll find that it goes even further, proposing:

Here it is:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2425.html

Good call, Sean. I didn't see this before. Thank you for pointing it out.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Michael Aaron Safyan wrote:
> Andre Kaufmann wrote:
>> Michael Aaron Safyan wrote:
>>> [...]
>>> 1.) Objective-C uses "#import", so this would break Objective-C and
>>> Objective-C++.
>>
>> Keeping both C and C++ in sync would restrict and delay the evolution
>> of C++ IMHO too much, too much discussions on both sides ;-).
>
> The majority of the Apple code base is implemented in Objective-C, and
> Objective-C++ is a big deal for development on OS X. Breaking
> Objective-C and Objective-C++ in this way, where it could be easily
> avoided (simply by selecting an alternative word), would -- I suspect --
> greatly displease the people at Apple as well as all corporations which
> have developed applications for the Mac.

I didn't speak of breaking but of keeping in sync. If you introduce
another keyword in C++ and wait till it's specified in C also you will
wait a long time.

>>
> [...]
> 1.) Libraries may vary from version to version. For example, "libxml"
> may add functions in one version which are not available in previous
> versions, or it may even remove "deprecated" functions from newer versions.

Yes. Then it won't run, since it can't bind dynamically to the dll on
runtime. That's a general problem.

> 2.) Libraries may vary from installation to installation. For example,
> the presence of "WxWidgets" depends largely on whether the user has
> downloaded and installed "WxWidgets" and not upon the operating system.
>
>
> The presence of libraries and header files depends on more than just the
> computer's operating system. It is already possible to detect the target
> machine's operating system with, albeit non-standard, predefined macros.
> However, since libraries and headers depend on the local configuration,
> this is not sufficient.

May be, but by detecting

if exist <windows.h>

you don't know which platform of Windows you want to compile to either.
Win98, Win2000, Win2003, Windows CE, Win32, Win64 ?
You additionally would need macros too.


>>
>> a) Testing for the existence of different libraries needs time.
>>    Especially if you use your "exists" proposal in a header file,
>>    which is included multiple times
>
> 1.) This testing is already done with the GNU Autotools.

Yes, as a kind of preprocessing.

> 2.) This testing would take less time than with the GNU Autotools,
> because there is a tendency to perform unnecessary tests in the event
> that a header file may later become necessary.

But would take more time as macros if the header file is used multiple
times. Here we have the basic problem of C++, get rid of that nasty
header files. They aren't worth it and I'm tired of dealing with
precompiled header files.

> [...]
> I'm not sure what you mean. If "pthread.h" isn't found, it means nothing
> more than that the pthread implementation is not available.

Or that you've set an include path wrong. Or even more worse you've
added another search path, which makes the compiler to see different
libraries first.

> [...]
> The "declarelib" keyword modifies the linkage of a symbol based on the
> library in which it is or will be located. Thus it can act as both an
> import and export modifier, not just an export modifier (e.g. on Windows
> with Microsoft Visual C++, it would act like both
> "__declspec(dllimport)" and "__declspec(dllexport)", depending on the
> parameter to declarelib).

Well perhaps the linker could figure it out automatically, if the
symbols is implemented locally and must be exported or imported.

 > [...]

Andre

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andre Kaufmann wrote:
> Michael Aaron Safyan wrote:
>> Andre Kaufmann wrote:
>>> Michael Aaron Safyan wrote:
>>>> [...]
[snipped]
>> 1.) Libraries may vary from version to version. For example, "libxml"
>> may add functions in one version which are not available in previous
>> versions, or it may even remove "deprecated" functions from newer
>> versions.
>
> Yes. Then it won't run, since it can't bind dynamically to the dll on
> runtime. That's a general problem.
>

If features are divided across header files, then a header file check
would allow for the usage of available symbols, only, thus avoiding this
problem.

>> 2.) Libraries may vary from installation to installation. For example,
>> the presence of "WxWidgets" depends largely on whether the user has
>> downloaded and installed "WxWidgets" and not upon the operating system.
>>
>>
>> The presence of libraries and header files depends on more than just
>> the computer's operating system. It is already possible to detect the
>> target machine's operating system with, albeit non-standard,
>> predefined macros. However, since libraries and headers depend on the
>> local configuration, this is not sufficient.
>
> May be, but by detecting
>
> if exist <windows.h>
>
> you don't know which platform of Windows you want to compile to either.
> Win98, Win2000, Win2003, Windows CE, Win32, Win64 ?
> You additionally would need macros too.

True, but the <windows.h> file could provide its own macros, rather than
relying on the preprocessor to generate the correct predefined macros.


A better example can be found on UNIX: the header <unistd.h> defines
various macros which specify the version of the UNIX standard; however,
accessing those macros requires the inclusion of <unistd.h>, and it is
good to know that such inclusion is safe to do.

>
>
>>>
>>> a) Testing for the existence of different libraries needs time.
>>>    Especially if you use your "exists" proposal in a header file,
>>>    which is included multiple times
>>
>> 1.) This testing is already done with the GNU Autotools.
>
> Yes, as a kind of preprocessing.

To clarify, the preprocessing done by the GNU Autotools involves:

1.) Creating a dummy source file which includes the header in question.
2.) Attempting to compile that source file into an executable.
3.) Checking whether the compilation succeeded.

This incurs a great deal of overhead.

>
>> 2.) This testing would take less time than with the GNU Autotools,
>> because there is a tendency to perform unnecessary tests in the event
>> that a header file may later become necessary.
>
> But would take more time as macros if the header file is used multiple
> times. Here we have the basic problem of C++, get rid of that nasty
> header files. They aren't worth it and I'm tired of dealing with
> precompiled header files.

Most header files use preprocessor guards, ensuring that the contents
are read only once. Additionally, nothing precludes the preprocessor
from caching the result of an "exists(...)" invocation.

>
>> [...]
>> I'm not sure what you mean. If "pthread.h" isn't found, it means
>> nothing more than that the pthread implementation is not available.
>
> Or that you've set an include path wrong. Or even more worse you've
> added another search path, which makes the compiler to see different
> libraries first.

Setting an include path incorrectly would cause the entire build to
fail, anyway, so it is a non-issue. Putting other files in the search
path, first, will not prevent the compiler from finding "pthread.h",
although it can make it see a different version of "pthread.h".

>
>> [...]
>> The "declarelib" keyword modifies the linkage of a symbol based on the
>> library in which it is or will be located. Thus it can act as both an
>> import and export modifier, not just an export modifier (e.g. on
>> Windows with Microsoft Visual C++, it would act like both
>> "__declspec(dllimport)" and "__declspec(dllexport)", depending on the
>> parameter to declarelib).
>
> Well perhaps the linker could figure it out automatically, if the
> symbols is implemented locally and must be exported or imported.
>
>  > [...]
>
> Andre
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andre Kaufmann wrote:
> Michael Aaron Safyan wrote:
>> Andre Kaufmann wrote:
>>> Michael Aaron Safyan wrote:
>>>> [...]
>>>> 1.) Objective-C uses "#import", so this would break Objective-C and
>>>> Objective-C++.
>>>
>>> Keeping both C and C++ in sync would restrict and delay the evolution
>>> of C++ IMHO too much, too much discussions on both sides ;-).
>>
>> The majority of the Apple code base is implemented in Objective-C, and
>> Objective-C++ is a big deal for development on OS X. Breaking
>> Objective-C and Objective-C++ in this way, where it could be easily
>> avoided (simply by selecting an alternative word), would -- I suspect
>> -- greatly displease the people at Apple as well as all corporations
>> which have developed applications for the Mac.
>
> I didn't speak of breaking but of keeping in sync. If you introduce
> another keyword in C++ and wait till it's specified in C also you will
> wait a long time.
>
>>>
>> [...]
>> 1.) Libraries may vary from version to version. For example, "libxml"
>> may add functions in one version which are not available in previous
>> versions, or it may even remove "deprecated" functions from newer
>> versions.
>
> Yes. Then it won't run, since it can't bind dynamically to the dll on
> runtime. That's a general problem.
>
>> 2.) Libraries may vary from installation to installation. For example,
>> the presence of "WxWidgets" depends largely on whether the user has
>> downloaded and installed "WxWidgets" and not upon the operating system.
>>
>>
>> The presence of libraries and header files depends on more than just
>> the computer's operating system. It is already possible to detect the
>> target machine's operating system with, albeit non-standard,
>> predefined macros. However, since libraries and headers depend on the
>> local configuration, this is not sufficient.
>
> May be, but by detecting
>
> if exist <windows.h>
>
> you don't know which platform of Windows you want to compile to either.
> Win98, Win2000, Win2003, Windows CE, Win32, Win64 ?
> You additionally would need macros too.
>
>
>>>
>>> a) Testing for the existence of different libraries needs time.
>>>    Especially if you use your "exists" proposal in a header file,
>>>    which is included multiple times
>>
>> 1.) This testing is already done with the GNU Autotools.
>
> Yes, as a kind of preprocessing.
>
>> 2.) This testing would take less time than with the GNU Autotools,
>> because there is a tendency to perform unnecessary tests in the event
>> that a header file may later become necessary.
>
> But would take more time as macros if the header file is used multiple
> times. Here we have the basic problem of C++, get rid of that nasty
> header files. They aren't worth it and I'm tired of dealing with
> precompiled header files.
>

Well they will not go away entirely (not least because of the need to
maintain legacy code, but the modules proposal that has been put off for
a TR (we did not have the resources to deal with it as part of the
current revision of C++) will largely remove the need to use them for
application level programmers.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Sean Hunt wrote:
> On Dec 11, 11:09 am, akfmn...@t-online.de (Andre Kaufmann) wrote:
> [...]
> If you read N2425, you'll find that it goes even further, proposing:

Thank you for the hint, Sean.
But I'm still missing specifications for dynamic binary linkage. That
shouldn't be perhaps part of the C++ standard, but another one
specifying dynamic binary linkage compatibility between C and C++ compilers.

So that you take a library written with compiler A and simply write

#import "LibraryA.so"
#import "LibraryA.dll"

and the compiler B compiles and links the code either dynamically or
perhaps even statically, without the need of header files etc.

It might be a problem for exporting C++ objects, but at least the name
mangling for flat functions could be standardized. If the compiler
additionally stores meta information for used structures and variables
you could simply use the library with every C and C++ compiler.

It's perhaps not a big problem in the Open Source world, but for closed
source libraries.

But anyways, I wouldn't have to deal with exported and imported
declarations in my header files, because the compiler knows which
symbols shall be imported, by extracting the information from the
library itself - or alternatively from a separate file, to prevent the
libraries to get bloated.

And I couldn't accidentally use an old header file with a newer library
or vice versa.

> [...]

Andre

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andre Kaufmann wrote:
> Sean Hunt wrote:
>> On Dec 11, 11:09 am, akfmn...@t-online.de (Andre Kaufmann) wrote:
>> [...]
>> If you read N2425, you'll find that it goes even further, proposing:
>
> Thank you for the hint, Sean.
> But I'm still missing specifications for dynamic binary linkage. That
> shouldn't be perhaps part of the C++ standard, but another one
> specifying dynamic binary linkage compatibility between C and C++
> compilers.
>
> So that you take a library written with compiler A and simply write
>
> #import "LibraryA.so"
> #import "LibraryA.dll"
>
> and the compiler B compiles and links the code either dynamically or
> perhaps even statically, without the need of header files etc.
>
> It might be a problem for exporting C++ objects, but at least the name
> mangling for flat functions could be standardized. If the compiler
> additionally stores meta information for used structures and variables
> you could simply use the library with every C and C++ compiler.
>
> It's perhaps not a big problem in the Open Source world, but for closed
> source libraries.
>
No, it is not that simple. You cannot even do it for C TU's compiled
with different compilers unless there is an ABI for the platform you are
using.

It isn't just name-mangling that matters but other linkage details as
well as the size and organisation (little-endian, big-endian etc) of the
built-in types. And then we come to issues about how to support both
virtual functions and virtual bases. And so it goes on ...

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Francis Glassborow wrote:
> Andre Kaufmann wrote:
> [...]
> Well they will not go away entirely (not least because of the need to
> maintain legacy code, but the modules proposal that has been put off for
> a TR (we did not have the resources to deal with it as part of the
> current revision of C++) will largely remove the need to use them for
> application level programmers.

Thank you for the hint. Yes I know that proposal. IMHO one of the most
valuable features to be added to C++. Besides parallel programming it's
my top feature, I want to be added to C++.
It's just a pity, that it's not in the upcoming standard.

(Shouldn't mean that the committee hasn't done a good work - it has)

Andre

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Michael Aaron Safyan wrote:
> Andre Kaufmann wrote:
> [...]
> True, but the <windows.h> file could provide its own macros, rather than
> relying on the preprocessor to generate the correct predefined macros.

But how will windows.h know for what platform I want to compile for ?
E.g. I want to compile code under WindowsXP, which shall also run on
Win2K. I have to set the platform specifics macros correctly.

> [...]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Francis Glassborow wrote:
> Andre Kaufmann wrote:
>> Sean Hunt wrote:
>>> On Dec 11, 11:09 am, akfmn...@t-online.de (Andre Kaufmann) wrote:
>>> [...]

 > [...]
>> It's perhaps not a big problem in the Open Source world, but for
>> closed source libraries.
>>
> No, it is not that simple. You cannot even do it for C TU's compiled
> with different compilers unless there is an ABI for the platform you are
> using.

Yes, I know very well why it's not that simple. But all what you need is

- Calling convention
- Binary layout


> It isn't just name-mangling that matters but other linkage details as
> well as the size and organisation (little-endian, big-endian etc) of the

Little-endian / Big-endian is not an issue if you stay on a single
platform. On another platform it's not an issue too. Only if you mix
both platforms and exchange data, which wasn't my intention.

> built-in types. And then we come to issues about how to support both
> virtual functions and virtual bases. And so it goes on ...

As I wrote, at least flat functions could be exported in a standardized
way. I've written for a large project a base declaration in XML, which
generates all structures and exported functions for 10 compilers in
different languages for currently 2 platforms.

It all works like a breeze, I had only restrict myself to a common basis:

- stdcall calling convention
- binary layout: 1 byte alignment

I've exported objects too on an interface basis.

> [...]

The compiler only needs to know, how to generate code. If there would be
a standard for meta information of exported functions and perhaps POD
structures, at least most languages could use and exchange dynamic link
libraries >without< any problems.


It it that simple -> we do only need a standard and perhaps some
restrictions, what can be exported in a standardized way.

Andre

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]