[Swig-user] GSOC 2012 query

[Sajan Kedia]

Hi

I am looking at new C++11 standards which can be added in SWIG. which is given in the project idea page idea 1. I want to include multithreading support, generic programming support, uniform initialization and performance enhancements. For time performance enhancement, extern template can be used.

extern template class std::vector<MyClass>;

There can be improvement in object construction. like: 

class SomeType  {

    int number;

 

public:

    SomeType(int new_number) : number(new_number) {}

    SomeType() : number(42) {}

};

class SomeType  {

    int number;

 

private:

    void Construct(int new_number) { number = new_number; }

public:

    SomeType(int new_number) { Construct(new_number); }

    SomeType() { Construct(42); }

};

Please guide me what more aspects can be applied.

Thank you

Regards

Sajan Kedia

CSE, ITBHU, India

 

[Vadim Zeitlin]

On Mon, 19 Mar 2012 10:15:30 +0530 Sajan Kedia <sajan...@gmail.com> wrote:

SK> I am looking at new C++11 standards which can be added in SWIG. which is
SK> given in the project idea page idea 1.

Hello,

Great to hear this, improving SWIG support for C++11 is definitely very
important and will become only more so in the future.

Before discussing the details, notice that from practical point of view,
the first important thing would be to merge gsoc2009-matevz branch with the
trunk to at least make the already implemented C++11 support available to
SWIG users. I don't know if it's going to be part of the GSoC or if William
(or me?) can do it beforehand but you might need to do this yourself.

I also think that someone (again, possibly you) needs to examine how well
the features officially supported by the code in this branch work in
practice. E.g. looking at the first two of them:

- Move constructors: rvalue reference support is there but I don't see
anything about move constructors so maybe they're supported and just
a unit test for them is missing but maybe they're not and then it would
be quite important to add support for them.

- Const expressions: again, I see that "constexpr" keyword is supported,
but it's less clear if its semantics is implemented, e.g. if SWIG can
wrap an array of size returned by a constexpr function correctly.

There are probably more such questions about other stuff...

SK> I want to include multithreading support,

Not sure what do you mean exactly by this, i.e. how is it going to affect
SWIG.

SK> generic programming support,

This is a bit unclear as well, what exactly do you propose to do about
this?

SK> uniform initialization

According to

http://swig.svn.sourceforge.net/viewvc/swig/branches/gsoc2009-matevz/Doc/Manual/Cpp0x.html#Cpp0x_Uniform_initialization

this seems to be already supported, i.e. it's parsed correctly (but doesn't
affect the target language as it's not clear how it could).

SK> and performance enhancements. For time performance enhancement, extern
SK> template can be used.

Sorry, I don't understand which enhancements do you have in mind here
neither, could you please be more specific?

As for "extern template", it would be nice if it could free us from the
need to write "%template", this would certainly be a welcome improvement.

Regards,
VZ

[Vadim Zeitlin]

On Mon, 19 Mar 2012 20:19:20 +0530 Sajan Kedia <sajan...@gmail.com> wrote:

SK> Thank you for guiding me. I checked all the new features of c++11, there
SK> are many important features which are still missing in swig gsoc2009-matevz
SK> branch.

Hi again,

I don't think many of these features are really important from SWIG point
of view (all of them are for C++ programmers in general, of course) as most
of them don't modify at all what SWIG does or should do, i.e. have no
bearing on its output.

SK> I am listing them:
SK> 1. Explicit overrides and final

This one does affect SWIG as we need to recognize "override" and "final"
keywords but they don't need to be handled by SWIG, so it should be a
simple modification to the grammar. The priority of this task is rather
minimal as even now a "/Doverride=''" (define it as nothing) workaround
could be used.

SK> 2. Mutlithreading memory model

I don't see how is this one relevant to SWIG at all.

SK> 3. Control and query object alignment

Probably doesn't affect SWIG neither although perhaps we should recognize
(and ignore) "alignof" and "alignas" keywords as well.

SK> 4. Allow garbage collected implementations

This could in theory affect SWIG but we'd need an implementation providing
GC for C++ 11 and AFAIK none currently exists.

SK> 5. Tuple types
SK> 6. Hash Tables
SK> 7. Regular expressions

All of these new types should indeed be wrapped, i.e. typemaps provided
for them. This would probably make the bulk of the project.

SK> 8. extensible random number facility

I don't see how does this affect SWIG, although I could be missing
something here as I don't really know much about this part of the changes
to the library.

SK> 9. Plain old data(POD) type

This definitely doesn't affect SWIG at all (if you think it does, please
explain how).

SK> I am attaching a document with this mail, explaining all this features,

BTW, it was a bit difficult to see which part of this document came from
Wikipedia and which was added by you, it would have helped if you made it a
bit more explicit.

SK> please see and guide me.

Have you looked at the existing standard library typemaps? You'd need to
understand them to do (5), (6) and (7). If you plan to do this, which
target languages would you support?

SK> After these all changes gsoc2009-matevz branch will be updated to
SK> trunk.

IMO it would be much more prudent to merge it first and then split a new
gsoc2012-xxx branch.

Regards,
VZ

[William S Fulton]

On 19/03/12 11:41, Vadim Zeitlin wrote:
> On Mon, 19 Mar 2012 10:15:30 +0530 Sajan Kedia<sajan...@gmail.com> wrote:
>
> SK> I am looking at new C++11 standards which can be added in SWIG. which is
> SK> given in the project idea page idea 1.
>
> Hello,
>
> Great to hear this, improving SWIG support for C++11 is definitely very
> important and will become only more so in the future.
>
> Before discussing the details, notice that from practical point of view,
> the first important thing would be to merge gsoc2009-matevz branch with the
> trunk to at least make the already implemented C++11 support available to
> SWIG users. I don't know if it's going to be part of the GSoC or if William
> (or me?) can do it beforehand but you might need to do this yourself.
>

My plan is to merge this branch into trunk after swig-2.0.5 is released
and any future C++11 code can branch off gsoc2009-matevz or trunk if the
merge is done in time.

> I also think that someone (again, possibly you) needs to examine how well
> the features officially supported by the code in this branch work in
> practice. E.g. looking at the first two of them:
>
> - Move constructors: rvalue reference support is there but I don't see
> anything about move constructors so maybe they're supported and just
> a unit test for them is missing but maybe they're not and then it would
> be quite important to add support for them.
>

I've started adding rvalue reference support to gsoc2009-matevz and I
don't see this as a gsoc project.

> - Const expressions: again, I see that "constexpr" keyword is supported,
> but it's less clear if its semantics is implemented, e.g. if SWIG can
> wrap an array of size returned by a constexpr function correctly.
>
> There are probably more such questions about other stuff...
>
>
> SK> I want to include multithreading support,
>
> Not sure what do you mean exactly by this, i.e. how is it going to affect
> SWIG.
>
> SK> generic programming support,
>
> This is a bit unclear as well, what exactly do you propose to do about
> this?
>
> SK> uniform initialization
>
> According to
>
> http://swig.svn.sourceforge.net/viewvc/swig/branches/gsoc2009-matevz/Doc/Manual/Cpp0x.html#Cpp0x_Uniform_initialization
>
> this seems to be already supported, i.e. it's parsed correctly (but doesn't
> affect the target language as it's not clear how it could).
>
> SK> and performance enhancements. For time performance enhancement, extern
> SK> template can be used.
>
> Sorry, I don't understand which enhancements do you have in mind here
> neither, could you please be more specific?
>
> As for "extern template", it would be nice if it could free us from the
> need to write "%template", this would certainly be a welcome improvement.
>

Support for the new keywords would be useful. But I don't think there is
much to be done there. There is plenty of work in the STL containers though.

I don't know about "extern template". It wouldn't provide a nice
language name for the template instantiation. However, solving the need
for a %template is a problem to be solved by itself, but I don't think
that is doable in SOC.

William

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Swig-user mailing list
Swig...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/swig-user

[Sajan Kedia]

Hi William

As per your reply idea 1 "New c++11 support" this can be done by you and not available for GSOC. So please help me that which is the critical project with high preference to SWIG, i want to contribute to that project, which can be done during summers in GSOC. Because idea2 on idea page is also similar, the work there is to finish up "gsoc2008-maciekd" branch. So may be this will also be not a part of SOC. so please give me some project ideas.

Waiting for your reply

Thanks & Regards

Sajan 

[Vadim Zeitlin]

On Tue, 20 Mar 2012 06:47:41 +0530 Sajan Kedia <sajan...@gmail.com> wrote:

SK> As per your reply idea 1 "New c++11 support" this can be done by you and
SK> not available for GSOC.

The "writing typemaps" for the new classes in the standard library still
remains. At least for the tuples this would be pretty useful to have, I
think. I'm not sure if it's enough for an entire GSoC project though, I
admit that I had underestimated the current state of gsoc2009-matevz
branch.

Regards,
VZ

[Clemens]

Hi,

I use %nodefaultctor in a namespaced class. Unfortunately the default CTOR will be generated anyway.

My code looks like:

%nodefaultctor ns::A;

namespace ns

{

class A{...};

}

What could be the reason ?

Thanks

Clemens

[Clemens]

>I use %nodefaultctor in a namespaced class. Unfortunately the default CTOR
>will be generated anyway.

I found out that an already existing CTOR will be generated anyway even in
class derived from an abstract class and can not be avoided by %nodefaultctor.
%ignore works fine.

Thanks
Clemens