Hello together!

I've found some time (and inspiration) to work on the C++ linking feature again.

Currently I'm trying to implement namespace support, but I've got some questions about implementation details.

My current idea is this:

MyClass=cppclass
(...)
end; namespace FirstPart.SecondPart;

Where FirstPart and SecondPart are identifiers.

1. What do you think about this syntax?

2. What about the order of namespace and external? Should it be "namespace (...); external (...);" or "external (...); namespace (...);"? Or shall both orders be accepted?

3. How can I parse a not reserved identifier? Checking "idtoken" for "_ID", using it with "token" and after usage calling "consume(_ID);"?

4. What about reserved identifiers being used in the namespace which might be valid in C++ (e.g. "location", "platform", "register", "object" or even "begin")?

5. What's the best way to save the namespace in the tobjectdef class? As a string containing 'FirstPart.SecondPart'? Or as C++ mangled string '9FirstPart10SecondPart'? Or something else (e.g. a list containing the parts)?

6. If I add a field to e.g. tobjectdef that's written to and loaded from ppu files, I need to increase the ppu version, right?

Regards,
Sven

PS: Please CC me, because I'm using Digest Mode and I don't want to mess up the thread view. :)

Sven Barth wrote

4. What about reserved identifiers being used in the namespace which might be valid in C++ (e.g. "location", "platform", "register", "object" or even "begin")?

'&' at the begining of identifer allows to use any identifier name like &location, &platform, etc.

Best regards,
Paul Ishenin.

In our previous episode, Paul Ishenin said:

That doesn't help, since still breaks existing code that might not even use C++ extensions. But I assume this is done in a separate mode (or modeswitch?)

Sorry? & needs to be placed in the pascal code. So I don't see what existing code can it break? I believe there is no existsing pascal code which can link with c++ classes.

Best regards,
Paul Ishenin.

In our previous episode, Paul Ishenin said:

Sorry, misread. Should have known better than C++ adding keywords.

Hi again!

Yes, you're right... I forgot about the '&'... ^^
Is this feature implemented in the depths of the parser or do I need to handle this manually?

Regards,
Sven

PS: Can it be that the server has troubles? I can access neither the Bugtracker nor the svn nor the wiki (but the mailing list sites ^^).

Hi again!

I'll answer some of my questions myself:

2. What about the order of namespace and external? Should it be "namespace (...); external (...);" or "external (...); namespace (...);"? Or shall both orders be accepted?

For now I've decided to use "namespace(...); external(...);"

3. How can I parse a not reserved identifier? Checking "idtoken" for "_ID", using it with "token" and after usage calling "consume(_ID);"?

Usage is with "pattern" (all letters uppercase) or "orgpattern" (original casing) instead of "token"... the rest works as expected.

4. What about reserved identifiers being used in the namespace which might be valid in C++ (e.g. "location", "platform", "register", "object" or even "begin")?

Answered by Paul Ishenin (thanks to the recently added escaping feature ^^)

5. What's the best way to save the namespace in the tobjectdef class? As a string containing 'FirstPart.SecondPart'? Or as C++ mangled string '9FirstPart10SecondPart'? Or something else (e.g. a list containing the parts)?

I've decided to save the mangled name in the objectdef. It's mangled directly when parsing it.

Once I can access the svn server and the bugtracker again, I'll post my patch including some tests. And then you can post your objections there, if any. :P

Regards,
Sven

Why do you need this at all? If you want to parse "namespace" word then just add it to the token list as
(str:'NAMESPACE' ;special:false;keyword:m_all;op:NOTOKEN)

Best regards,
Paul Ishenin.

That should be "m_none" instead of m_all, otherwise every program using "namespace" as identifier will fail to compile afterwards.

Jonas

I think it's better to store just the name space string, it looks more flexbile to me.

Jonas Maebe wrote

That should be "m_none" instead of m_all, otherwise every program using "namespace" as identifier will fail to compile afterwards.

Sorry. My fault - looked at m_none but copied m_all line instead :(

Best regards,
Paul Ishenin.

Hi again!

Once I say 'I did it that and that way', all are coming to answer me... Nice :)

It's not the "namespace" keyword... that is done the way you suggested (besides using m_none instead of m_all as Jonas mentioned).

I'm talking about the namespace value itself.

E.g. the C++ code

namespace Foo::Bar {
class FooBar {

}
}

becomes to

FooBar = cppclass

end; namespace Foo.Bar;

in Pascal.

Or should I use a stringconst instead of point delimited identifiers? Like it's done for external...

Florian Klaempfl wrote

I think it's better to store just the name space string, it looks more flexbile to me.

Hmm... ok... but would there be any problem with using another field in objectdef, that is not saved to ppu, to save the mangled name, so I don't need to mangle it every time a method of that class is mangled? (maybe wrapped with a getter function for "lazy mangling" :D)

Regards,
Sven

In our previous episode, Sven Barth said:

This looks a bit strange to me. Namespace is a block in C++, but more a directive in Pascal?

Hi again!

Yes, I know... but I think it's just not feasible to implement such blocks for types in Pascal (I think of it as "overkill" ^^)... So I took the easy way.
Also keep in mind please, that the cppclass construct is mostly (solely?) for interfacing with existing C++ code/libraries (like QT or the Irrlicht engine) directly and not for "just for fun I'll write a C++ class in Pascal today".

Regards,
Sven

PS: I've switched from Digest Mode to normal message delivery in fpc-devel now... so my answers to the list's mails should be more reliable :) This excludes this mail from Marco though, as it was sent before I changed the setting...

Don't UNITS in Pascal intended to separate NAMESPACES? But unfortunately this prevents nested namespaces.

Regards,
Anton Kavalenka

Anton Kavalenka wrote

Don't UNITS in Pascal intended to separate NAMESPACES? But unfortunately this prevents nested namespaces.

The discussion is not about adding support for C++-style namespaces to Pascal, but for how to specify the C++ namespace in which an (externally implemented) C++ class is defined (as this influences the name mangling).

Jonas

I understand :)

The most amazing thing will start later (during linking). In what order runtime initialization should be performed (first Pascal the C++ or vice versa)?
Obviously C++ object files has lots of references to C++ runtime so in best case we get exe file with 2 runtimes inside,
in worst case we get crash on initialization.

Regards,
Anton

Anton Kavalenka wrote in reply to that:

it even gets worse than that. Is this even possible? WHAT C++ compiler-mangling are you going to support?

Every C++ compiler has its own mangling scheme, which individual versions of it can change at will as well.

GNU C++ on linux/whatever system? => changed mangling between versions Borland/(open)Watcom/Digital Mars/Microsoft/... on Windows and some on other systems => same there.

there are some ABI's, but they do not contain name-mangling conventions.

ps: sorry to mess up your thread. I'm using digest.

kind regards,
Dimitri Smits

Dimitri Smits wrote

WHAT C++ compiler-mangling are you going to support?

The compiler currently only supports G++ 3.x and later.

Jonas