similar to: RTTI with smart pointers

Dear all, Maybe, I am doing something wrong, but using R-2.5.0 on my Intel-Mac, I have problems using function callNextMethod() in method initialize. I am loading the following code as file "testS4.R": setClass("baseClass", representation(myname = "character", mydir = "character", "VIRTUAL"),

Dear all, Currently, I am trying to create a test package "testS4" using S4 classes, which I am attaching. Running R CMD check gives the following error: coeurebooks-computer:/Volumes/CoreData/CRAN cs$ R CMD check testS4_0.1.1.tar.gz * checking for working latex ...sh: line 1: latex: command not found NO * using log directory '/Volumes/CoreData/CRAN/testS4.Rcheck' * using R

Dear all, Recently, there was a question to use the same method for more than one class: https://stat.ethz.ch/pipermail/r-devel/2007-March/044809.html I have a variation of this question: Is it possible to use the same function name, e.g. "myfunction" in both, an S4 baseClass and derivedClass. The method "myfunction" in derivedCalss should extend the functionality defined

Hi, I''m having trouble with some STI Classes in a test. When I create a new Class of an STI derived base class the type column is not set. If I do object = DerivedClass.create!(params) then object[:type] == nil for some reason. Any ideas why this is so? I assumed rails takes care of setting the type column in STI (that''s what I read). Nico

JavaScript doesn''t (yet) have a notion of classes. Prototype.js just adds a suitable convention for implementing them. It provides a way to create a new class by extending a base class using Object.extend, but it doesn''t handle method inheritance. There are ways of doing implementing this through traversing the chain of prototypes, but I''m not sure they are

Hi everyone, I have an idea that should allow reducing code duplication in Casting.h while making llvm::isa, llvm::cast, llvm::dyn_cast, etc more generic. Since we added unique pointers support for these template functions (see ab480f45cd23c08cb9aa3f427aad072df249135f) I propose to generalize their semantics to deal with any pointer-like type (i.e. dereferenceable and implicitly convertible to

why llvm contains IntrusiveRefCntPtr instead of using only std::shared_ptr? IntrusiveRefCntPtr widely used in llvm and clang source code. Due to better performance? for example in main func of clang frontend: int cc1_main(ArrayRef<const char *> Argv, const char *Argv0, void *MainAddr) { ensureSufficientStack(); std::unique_ptr<CompilerInstance> Clang(new CompilerInstance());

Am 29.08.19 um 12:07 schrieb Jonathan Wakely: > On Thu, 29 Aug 2019 at 10:15, Christian Schneider > <cschneider at radiodata.biz> wrote: >> >> Hello, >> I just discovered, that, when using enable_shared_from_this and >> inheriting it privately, this fails at runtime. >> I made a small example: >> >> #include <memory> >> #include

On Wed, Oct 19, 2016 at 6:24 PM, Benjamin Kramer via llvm-dev < llvm-dev at lists.llvm.org> wrote: > In terms of performance shared_ptr has a number of disadvantages. One > is that it always uses atomics even though most IntrusiveRefCntPtrs > are used in single-threaded contexts. Another is weak_ptr adding a lot > of complexity to the implementation, IntrusiveRefCntPtr

Hello, I just discovered, that, when using enable_shared_from_this and inheriting it privately, this fails at runtime. I made a small example: #include <memory> #include <boost/shared_ptr.hpp> #include <boost/make_shared.hpp> #include <boost/enable_shared_from_this.hpp> #ifndef prefix #define prefix std #endif class foo: prefix::enable_shared_from_this<foo> {

In the most basic case, I'd imagine something like this: auto C = std::make_shared<LLVMContext>(); struct ModuleAndSharedContextDeleter { std::shared_ptr<LLVMContext> C; operator()(Module *M) { delete M; } /* ctor to init C */}; std::unique_ptr<Module, ModuleAndSharedDeleter> M(new Module(C.get()), ModuleAndSharedContextDeleter(C)); (or invert this and traffic in structs

Hello everyone, I bring to discussion the necessity/design of a new type of smart pointer. r215176 and r217791 rise the problem, D5443 <http://reviews.llvm.org/D5443> is devoted to the solution. r215176 applies several temporary ugly fixes of memory leaks in TGParser.cpp which would be great to be refactored using smart pointers. D5443 <http://reviews.llvm.org/D5443> demonstrates

There seems to be some uncertainty about the use of smart pointers (previously OwningPtr, now std::unique_ptr and std::shared_ptr predominantly) in the LLVM project as a whole, so here's a thread to discuss/clarify/etc the project preferences/direction with regard to smart pointer usage. For some context, see discussions in LLVM r212403 and Clang r213307. The basic question here seems to be

On Thu, Jul 17, 2014 at 4:45 PM, Alp Toker <alp at nuanti.com> wrote: > > On 18/07/2014 02:21, David Blaikie wrote: >> >> Are people OK with/prefer the use of owning smart pointers in APIs? > > > I think smart pointers are great to use for storage, or as struct members > where there's actually a clear need for ownership. Just by virtue of getting > rid of

My experience with LLVM is limited, but I am trying to figure out how to add optimizations for automatic reference counting. The GC documentation mentions that patch-points could be useful, but it does not state how they would be useful. If this is a FAQ, please let me know... So this is my idea at this point: The context is a C++ like language with an aggregate type that is always reference

On Wed, Oct 19, 2016 at 9:31 PM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On Oct 19, 2016, at 11:14 AM, Bruce Hoult via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On Wed, Oct 19, 2016 at 6:24 PM, Benjamin Kramer via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> In terms of performance shared_ptr has a number of

It''s been a few days since I posted my last two emails (of which, no one replied to) so I''ve gone ahead and coded a working slider class as well as a ''resizeable'' class that allows a user to drag and resize the element. I also linked these two together as I want to have slider behavior that can resize the resizeable element. The end result is both the

On Thu, Nov 13, 2014 at 10:59 AM, Argyrios Kyrtzidis <akyrtzi at gmail.com> wrote: > Could we consider moving the things you listed to shared pointer semantics > ? It will be a simple and clear model; unless someone justifies that it > will be a performance concern to use shared pointers there I don’t think we > need a new and more complex to reason about smart pointer. >

Looks pretty reasonable to me - with test cases. (not sure if dereferenced_type should be defined for a type that's not dereferenceable, though?) On Tue, Jan 23, 2018 at 7:02 AM Dmitriy Borisenkov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi everyone, > > I have an idea that should allow reducing code duplication in Casting.h > while making llvm::isa, llvm::cast,

hi, when using the execution engine (no matter, if JIT or Interpreter) i get the following assertion as soon as i use boost::shared_ptr: /build/buildd/llvm-2.5/lib/Target/X86/X86CodeEmitter.cpp:522: void<unnamed>::Emitter::emitInstruction(const llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 && "JIT does not support inline asm!\n"' failed.