I'm not sure if this is related, but there is one issue that needs to be
addressed a link time for object files that are generated from C++ code.
In C++ it is permissible to include definitions (not just declarations) in
header files. This means more that one object file may contain a definition
fo
On 07/10/2013 12:18 PM, Martyn Plummer wrote:
Yes, on reflection it's an ABI problem on Linux (use of PIC code in
shared libraries means that any symbol can be interposed). Using
namespaces isn't really the answer because that's an API issue. I think
what you really need to do is control the vi
Yes, on reflection it's an ABI problem on Linux (use of PIC code in
shared libraries means that any symbol can be interposed). Using
namespaces isn't really the answer because that's an API issue. I think
what you really need to do is control the visibility of your classes and
functions so that e
I have now got two "solutions" to this. The rgl version currently on
CRAN does a simple rename to avoid the name clash. A later version,
still only on R-forge, puts most objects into a namespace called "rgl".
(The old code had two small namespaces "gui" and "lib"; they are gone now.)
I am no
On 13-10-02 4:37 PM, Ross Boylan wrote:
On Wed, 2013-10-02 at 16:15 -0400, Duncan Murdoch wrote:
On 02/10/2013 4:01 PM, Ross Boylan wrote:
On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
Up to entry #4 this all looks normal. If I go into that stack frame, I
see this:
(g
On 13-10-02 4:26 PM, Romain Francois wrote:
Le 02/10/13 22:15, Duncan Murdoch a écrit :
On 02/10/2013 4:01 PM, Ross Boylan wrote:
On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
Up to entry #4 this all looks normal. If I go into that stack
frame, I
see this:
(gdb) up
On Wed, 2013-10-02 at 16:15 -0400, Duncan Murdoch wrote:
> On 02/10/2013 4:01 PM, Ross Boylan wrote:
> > On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
> >
> > >> Up to entry #4 this all looks normal. If I go into that stack frame, I
> > >> see this:
> > >>
> > >>
> > >> (gdb
Le 02/10/13 22:15, Duncan Murdoch a écrit :
On 02/10/2013 4:01 PM, Ross Boylan wrote:
On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
>> Up to entry #4 this all looks normal. If I go into that stack
frame, I
>> see this:
>>
>>
>> (gdb) up
>> #4 Shape::~Shape (this=0x15f876
On 02/10/2013 4:01 PM, Ross Boylan wrote:
On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
>> Up to entry #4 this all looks normal. If I go into that stack frame, I
>> see this:
>>
>>
>> (gdb) up
>> #4 Shape::~Shape (this=0x15f8760, __in_chrg=) at
>> Shape.cpp:13
>> warning:
On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:
>> Up to entry #4 this all looks normal. If I go into that stack frame, I
>> see this:
>>
>>
>> (gdb) up
>> #4 Shape::~Shape (this=0x15f8760, __in_chrg=) at
>> Shape.cpp:13
>> warning: Source file is more recent than executable.
Duncan,
extern "C" just means that the function(s) below it have C calling
conventions, so that .Call, .External, ... can find them. Without this,
your function names would be c++ mangled to disambiguate different
overloads.
What is inside can use namespace without any issue. You'd have some
Thanks Dirk, Martyn and Romain. I'm planning to do a temporary
workaround release with the Shape class renamed to rglShape, but over
the longer term I'll put everything that's supposed to be local inside
an rgl namespace. First I need to learn how namespaces interact with
extern "C" declarati
On 2 October 2013 at 15:45, Martyn Plummer wrote:
| In C++, everything goes in the global namespace unless the programmer
| explicitly creates one. So when you dynamically load two dynamic shared
| libraries with a "Shape" object they clash.
|
| The solution here is to put
|
| namespace rgl {
|
In C++, everything goes in the global namespace unless the programmer
explicitly creates one. So when you dynamically load two dynamic shared
libraries with a "Shape" object they clash.
The solution here is to put
namespace rgl {
...
}
around your class definitions in the rglm package, and
us
Le 02/10/13 17:05, Duncan Murdoch a écrit :
A quick addition:
If I add
#define Shape rglShape
near the top of my Shape.hpp header file, the bug goes away. But I
can't believe that would be necessary. These are in separate packages,
don't they have separate namespaces in C++? How can I avoid
A quick addition:
If I add
#define Shape rglShape
near the top of my Shape.hpp header file, the bug goes away. But I
can't believe that would be necessary. These are in separate packages,
don't they have separate namespaces in C++? How can I avoid clashes
with types declared in other pack
I've had reports lately about segfaults in the rgl package. I've only
been able to reproduce these on Linux. I am not so familiar with C++
details, so I have a couple of questions way down below. But first some
background info.
One recipe to recreate the crash works with a new version 5.0-
17 matches
Mail list logo
