DOCSLIB.ORG

Quantitative Template for Subtyping Primary Progressive Aphasia

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Quantitative Template for Subtyping Primary Progressive Aphasia ORIGINAL CONTRIBUTION Quantitative Template for Subtyping Primary Progressive Aphasia Marsel Mesulam, MD; Christina Wieneke, BA; Emily Rogalski, PhD; Derin Cobia, PhD; Cynthia Thompson, PhD; Sandra Weintraub, PhD Background: The syndrome of primary progressive Fourth Edition) classified all 16 patients in concor- aphasia (PPA) is diagnosed when a gradual failure of word dance with a clinical diagnosis that had been made be- usage or comprehension emerges as the principal fea- fore the administration of quantitative tests. All 3 PPA ture of a neurodegenerative disease. subtypes had distinctly asymmetrical atrophy of the left perisylvian language network. Each subtype also had dis- Objective: To provide a quantitative algorithm for clas- tinctive peak atrophy sites: PPA-G in the inferior frontal sifying PPA into agrammatic (PPA-G), semantic (PPA-S), gyrus (Broca area), PPA-S in the anterior temporal lobe, and logopenic (PPA-L) variants, each of which is known and PPA-L in Brodmann area 37. to have a different probability of association with Alzhei- mer disease vs frontotemporal lobar degeneration. Conclusions: Once an accurate root diagnosis of PPA is made, subtyping can be quantitatively guided using a Design: Prospective study. 2-dimensional template based on orthogonal tasks of Setting: University medical center. grammatical competence and word comprehension. Al- though the choice of tasks and the precise cutoff levels Patients: Sixteen consecutively enrolled patients with may need to be adjusted to fit linguistic and educational PPA who underwent neuropsychological testing and mag- backgrounds, these 16 patients demonstrate the feasi- netic resonance imaging recruited nationally in the United bility of using a simple algorithm for clinicoanatomical States as part of a longitudinal study. classification in PPA. Prospective studies will show whether this subtyping can improve clinical prediction Results: A 2-dimensional template that reflects perfor- of the underlying neuropathologic condition. mance on tests of syntax (Northwestern Anagram Test) and lexical semantics (Peabody Picture Vocabulary Test— Arch Neurol. 2009;66(12):1545-1551 HE CLASSIFICATION OF PRI- is particularly important for early-onset de- mary progressive aphasia mentias, in which the concordance be- (PPA) into subtypes has tween clinical predictions and postmor- acquired new relevance in tem confirmation can be quite low. light of postmortem series Although numerous studies1,3-5 have de- Tand in vivo amyloid imaging showing that scribed clinical and neuropsychological individual variants have different likeli- characteristics of PPA subtypes, few have hoods of being caused by Alzheimer dis- included an unselected prospective co- ease (AD) vs frontotemporal lobar de- hort investigated using a unified battery generation (FTLD). The most frequent of easily administered tests specifically cho- associations have been reported between sen to probe the defining features of the the agrammatic variant (PPA-G) and FTLD subtypes. with tauopathy (FTLD-T), the semantic This study describes an empirically es- variant (PPA-S) and FTLD with ubiquitin/ tablished 2-dimensional quantitative tem- TAR-DNA binding protein 43 proteinopa- plate derived from performance on tests of thy (FTLD-TDP), and the logopenic vari- syntax and lexical semantics that success- ant (PPA-L) and AD.1-3 fully classified 16 consecutively investi- In the absence of definitive in vivo bio- gated patients with PPA. The biological va- markers for these diseases, the reliable clas- lidity of the resultant classification was Author Affiliations: Cognitive sification of PPA assumes considerable rel- supported by the presence of distinctive ana- Neurology and Alzheimer’s evance for increasing the accuracy with tomical patterns of peak cortical atrophy in Disease Center, Northwestern which the nature of the underlying patho- each variant. Whether this classification also University, Chicago, Illinois. logic abnormality can be predicted. This corresponds to differential neuropatho- (REPRINTED) ARCH NEUROL / VOL 66 (NO. 12), DEC 2009 WWW.ARCHNEUROL.COM 1545 ©2009 American Medical Association. All rights reserved. Downloaded From: https://jamanetwork.com/ on 10/04/2021 Table 1. Characteristics of the 16 Study Patientsa WAB % Correct Patient No./ Aphasia Word-Word % Correct % Correct % Correct % BDAE WAB Sex/Age at Symptom Quotient Association PPVT-4 NAT BNT Fluency Repetition Testing, y Education, y Handednessb Duration, y (100) (16) (36) (10) (60) (7) (100) Agrammatic PPA Variant 1/M/62 20 ϩ80 5.0 82.3 100.0 100.0 50 98.3 42.9 80 2/M/59 12 ϩ95 3.0 79.9 100.0 94.4 40 81.7 57.1 78 3/F/61 18 ϩ100 5.0 75.3 100.0 100.0 50 88.3 42.9 88 4/F/56 14 ϩ100 2.0 65.4 100.0 83.3 10 81.7 14.3 42 Semantic PPA Variant 5/F/53 16 ϩ100 3.0 65.9 50.0 22.2 60 6.7 100.0 74 6/M/63 18 ϩ100 5.5 88.2 93.8 47.2 100 23.3 100.0 97 7/F/54 12 ϩ100 3.0 83.2 75.0 27.8 100 10.0 100.0 91 8/F/64 16 ϩ100 7.5 80.6 62.5 38.9 100 8.3 100.0 88 9/F/56 18 ϩ100 2.5 75.5 75.0 38.9 100 5.0 100.0 85 Logopenic PPA Variant 10/M/69 15 ϩ100 2.5 92.0 100.0 97.2 90 98.3 71.4 90 11/M/63 18 ϩ100 2.5 97.1 100.0 100.0 100 96.7 100.0 89 12/M/58 16 ϩ100 2.0 86.9 100.0 97.2 90 90.0 100.0 90 13/F/65 13 ϩ100 5.0 78.6 100.0 83.3 70 83.3 71.4 88 14/F/75 16 ϩ100 2.5 97.2 100.0 97.2 100 88.3 100.0 90 15/M/64 18 ϩ90 2.0 93.2 100.0 100.0 70 98.3 85.7 89 16/M/48 16 ϩ80 6.0 83.2 100.0 100.0 100 98.3 71.4 90 Abbreviations: BDAE, Boston Diagnostic Aphasia Examination; BNT, Boston Naming Test; NAT, Northwestern Anagram Test; PPA, primary progressive aphasia; PPVT-4, Peabody Picture Vocabulary Test—Fourth Edition; WAB, Western Aphasia Battery. a Numbers in parentheses indicate the highest possible raw scores. b A“ϩ” score in the Edinburgh inventory indicates the degree of right-handedness. logic processes remains to be determined by prospective SINGLE-WORD COMPREHENSION studies. Word comprehension (lexical semantics) is commonly tested by asking the patient to match a word to a picture. The auditory METHODS word comprehension subtest of the WAB was too easy. We, there- fore, opted to use the PPVT-412 and selected a subset of 36 mod- Recruitment occurred in the context of a National Institutes erately difficult items (items 157-192). Each item requires the of Health–funded project that brought patients from through- patient to match a word representing an object, action, or at- out the United States to Northwestern University for a 3-day tribute to 1 of 4 picture choices. Because performance on the intensive research program. All of the patients who fulfilled the PPVT-4 could potentially be confounded by problems of pic- criteria for PPA, who could complete the 5 key diagnostic tests, ture recognition, its face validity as a measure of word compre- and who had a magnetic resonance image suitable for quanti- hension was further established by comparing scores with those tative morphometric analysis were included. Only images ob- on a word-word association task in which patients decided which tained within a few days of neuropsychological testing were used. of 2 pairs contained semantically matching words (eg, horse- The root diagnosis of PPA was made on the basis of a progres- saddle vs horse-slippers). Only patients with PPA-S with the low- sive language disturbance (ie, aphasia) that is initially the most est PPVT-4 scores showed less than 100% performance on the salient feature of the clinical picture (ie, primary) and that is caused word-word association task (Table 1). However, the impair- by neurodegeneration (ie, is progressive).6-8 The presence of an ment on this task was milder than that on the PPVT-4. In the aphasia was established by aphasia quotients derived from admin- future, a more difficult form of the word-word association task istration of the Western Aphasia Battery (WAB).9 All of the pa- could be substituted for the PPVT-4 to eliminate potential in- tients were right-handed, as determined using the Edinburgh in- terference from picture-recognition deficits. ventory10; 8 were men and 8 were women (Table 1). Duration of disease at the time of testing varied from 2.0 to 7.5 years. The progressive nature of the deficits and the fact that the language SYNTAX IN THE CONSTRUCTION disorder was the chief problem during the initial few years of the OF SENTENCES disease were documented by the history obtained from the patient, from medical records, and from at least 1 additional informant who Syntax, a major component of grammar, regulates the proper or- lived in the same household.11 All of the patients had received a dering of words into sentences. Its assessment is challenging. The descriptive diagnosis of PPA-G, PPA-L, or PPA-S based on an ini- WAB, for example, has no subtest for assessing syntax. In tradi- tial office evaluation (Table 2), and before administration of the tional aphasiology, fluency and phrase length have been used as quantitative tests, by clinicians with extensive experience with this surrogates for grammatical competence. However, it becomes dif- disease (M.M. and S.W.). Five language tests provided the basis ficult to decide whether apparent agrammatism in a dysfluent pa- for the quantitative classification: the Peabody Picture Vocabu- tient represents an economy of expression, consequences of dys- lary Test—Fourth Edition (PPVT-4), the Northwestern Anagram arthria, or a true insensitivity to rules of syntax.
Load more

Recommended publications
  • J1939 Data Mapping Explained
    J1939 Data Mapping Explained Part No. BW2031 Revision: 1.05 May 18, 2018 Pyramid Solutions, Inc. 30200 Telegraph Road, Suite 440 Bingham Farms, MI 48025 www.pyramidsolutions.com | P: 248.549.1200 | F: 248.549.1400 © Pyramid Solutions 1 PUB-BW4031-001 Table of Contents Overview ......................................................................................................................... 2 J1939 Message Terminology ............................................................................................ 2 J1939 PGN Message Definitions ....................................................................................... 3 PGN and Parameter Documentation Examples ........................................................................ 3 J1939 Specification Example ........................................................................................................ 3 Parameter Table Example ............................................................................................................ 5 Determining the BridgeWay Data Table Layout ................................................................ 6 Data Table Layout for Modbus RTU and Modbus TCP (Big Endian) ........................................... 6 Data Table Layout for EtherNet/IP (Little Endian) .................................................................... 7 Configuring the BridgeWay I/O Mapping ......................................................................... 8 Configuration Attributes ........................................................................................................
    [Show full text]
  • Advanced Software Engineering with C++ Templates Lecture 4: Separate Compilation and Templates III
    Advanced Software Engineering with C++ Templates Lecture 4: Separate Compilation and Templates III Thomas Gschwind <thgatzurichdotibmdotcom> Agenda . Separate Compilation • Introduction (C++ versus Java) • Variables • Routines (Functions & Operators) • Types (Structures, Classes) • Makefiles . Templates III • Design and Implementation (C++ versus Java versus C#) • “Dynamic” Static Algorithm Selection • Binders Th. Gschwind. Fortgeschrittene Programmierung in C++. 2 Separate Compilation . Why? • Having only one source file is unrealistic • Break the code up into its logical structure • Reduction of compile time - Only changed parts need to be recompiled . How? • Use multiple source files • Need to know what information about functions and variables “used” from other files Th. Gschwind. Fortgeschrittene Programmierung in C++. 3 Separate Compilation in Java . Each Java file is compiled into a class file . If a Java class invokes a method of another class, the compiler consults that other class file to • Determine whether the class provides the requested method • Determine whether a class file implements a given interface • etc. • Hence, the .class file contains the entire interface . That’s why in Java, the compiler needs the class path . Finally, all class files are loaded by the Java Virtual Machine (and “linked”) . Java source code can be relatively well reconstructed from .class file (see Java Decompiler: jd, jad) Th. Gschwind. Fortgeschrittene Programmierung in C++. 4 Some Java Trivia . Let us write Hello World in Java . In order to simplify the reconfiguration (e.g., translation) • Put all the constants into one Java file • Put the complex application code into another public class Const { public static final String msg="Hello World!"; } public class Cool { public static void main(String[] args) { System.out.println(Const.msg); } } Th.
    [Show full text]
  • P2356R0 Date 2021-04-09 Reply-To Matus Chochlik [email protected] Audience SG7 Overview Details
    Overview Details Implementing Factory builder on top of P2320 Document Number P2356R0 Date 2021-04-09 Reply-to Matus Chochlik [email protected] Audience SG7 Overview Details The goal (Semi-)automate the implementation of the Factory design pattern Overview Details What is meant by \Factory" here? • Class that constructs instances of a \Product" type. • From some external representation: • XML, • JSON, • YAML, • a GUI, • a scripting language, • a relational database, • ... Overview Details Factory builder • Framework combining the following parts • Meta-data • obtained from reflection. • Traits • units of code that handle various stages of construction, • specific to a particular external representation, • provided by user. Overview Details Factory builder • Used meta-data • type name strings, • list of meta-objects reflecting constructors, • list of meta-objects reflecting constructor parameters, • parameter type, • parameter name, • ... Overview Details Factory builder • Units handling the stages of construction • selecting the \best" constructor, • invoking the selected constructor, • conversion of parameter values from the external representation, • may recursively use factories for composite parameter types. Overview Details Used reflection features • ^T • [: :]1 • meta::name_of • meta::type_of • meta::members_of • meta::is_constructor • meta::is_default_constructor • meta::is_move_constructor • meta::is_copy_constructor • meta::parameters_of • size(Range) • range iterators 1to get back the reflected type Overview Details Reflection review • The good2 • How extensive and powerful the API is • The bad • Didn't find much3 • The ugly • Some of the syntax4 2great actually! 3some details follow 4but then this is a matter of personal preference Overview Details What is missing • The ability to easily unpack meta-objects from a range into a template, without un-reflecting them. • I used the following workaround + make_index_sequence: template <typename Iterator > consteval auto advance(Iterator it, size_t n) { while (n-- > 0) { ++ it; } return it; } • Details follow.
    [Show full text]
  • Metaclasses: Generative C++
    Metaclasses: Generative C++ Document Number: P0707 R3 Date: 2018-02-11 Reply-to: Herb Sutter ([email protected]) Audience: SG7, EWG Contents 1 Overview .............................................................................................................................................................2 2 Language: Metaclasses .......................................................................................................................................7 3 Library: Example metaclasses .......................................................................................................................... 18 4 Applying metaclasses: Qt moc and C++/WinRT .............................................................................................. 35 5 Alternatives for sourcedefinition transform syntax .................................................................................... 41 6 Alternatives for applying the transform .......................................................................................................... 43 7 FAQs ................................................................................................................................................................. 46 8 Revision history ............................................................................................................................................... 51 Major changes in R3: Switched to function-style declaration syntax per SG7 direction in Albuquerque (old: $class M new: constexpr void M(meta::type target,
    [Show full text]
  • Generic Programming
    Generic Programming July 21, 1998 A Dagstuhl Seminar on the topic of Generic Programming was held April 27– May 1, 1998, with forty seven participants from ten countries. During the meeting there were thirty seven lectures, a panel session, and several problem sessions. The outcomes of the meeting include • A collection of abstracts of the lectures, made publicly available via this booklet and a web site at http://www-ca.informatik.uni-tuebingen.de/dagstuhl/gpdag.html. • Plans for a proceedings volume of papers submitted after the seminar that present (possibly extended) discussions of the topics covered in the lectures, problem sessions, and the panel session. • A list of generic programming projects and open problems, which will be maintained publicly on the World Wide Web at http://www-ca.informatik.uni-tuebingen.de/people/musser/gp/pop/index.html http://www.cs.rpi.edu/˜musser/gp/pop/index.html. 1 Contents 1 Motivation 3 2 Standards Panel 4 3 Lectures 4 3.1 Foundations and Methodology Comparisons ........ 4 Fundamentals of Generic Programming.................. 4 Jim Dehnert and Alex Stepanov Automatic Program Specialization by Partial Evaluation........ 4 Robert Gl¨uck Evaluating Generic Programming in Practice............... 6 Mehdi Jazayeri Polytypic Programming........................... 6 Johan Jeuring Recasting Algorithms As Objects: AnAlternativetoIterators . 7 Murali Sitaraman Using Genericity to Improve OO Designs................. 8 Karsten Weihe Inheritance, Genericity, and Class Hierarchies.............. 8 Wolf Zimmermann 3.2 Programming Methodology ................... 9 Hierarchical Iterators and Algorithms................... 9 Matt Austern Generic Programming in C++: Matrix Case Study........... 9 Krzysztof Czarnecki Generative Programming: Beyond Generic Programming........ 10 Ulrich Eisenecker Generic Programming Using Adaptive and Aspect-Oriented Programming .
    [Show full text]
  • RICH: Automatically Protecting Against Integer-Based Vulnerabilities
    RICH: Automatically Protecting Against Integer-Based Vulnerabilities David Brumley, Tzi-cker Chiueh, Robert Johnson [email protected], [email protected], [email protected] Huijia Lin, Dawn Song [email protected], [email protected] Abstract against integer-based attacks. Integer bugs appear because programmers do not antici- We present the design and implementation of RICH pate the semantics of C operations. The C99 standard [16] (Run-time Integer CHecking), a tool for efficiently detecting defines about a dozen rules governinghow integer types can integer-based attacks against C programs at run time. C be cast or promoted. The standard allows several common integer bugs, a popular avenue of attack and frequent pro- cases, such as many types of down-casting, to be compiler- gramming error [1–15], occur when a variable value goes implementation specific. In addition, the written rules are out of the range of the machine word used to materialize it, not accompanied by an unambiguous set of formal rules, e.g. when assigning a large 32-bit int to a 16-bit short. making it difficult for a programmer to verify that he un- We show that safe and unsafe integer operations in C can derstands C99 correctly. Integer bugs are not exclusive to be captured by well-known sub-typing theory. The RICH C. Similar languages such as C++, and even type-safe lan- compiler extension compiles C programs to object code that guages such as Java and OCaml, do not raise exceptions on monitors its own execution to detect integer-based attacks.
    [Show full text]
  • Cpt S 122 – Data Structures Custom Templatized Data Structures In
    Cpt S 122 – Data Structures Custom Templatized Data Structures in C++ Nirmalya Roy School of Electrical Engineering and Computer Science Washington State University Topics Introduction Self Referential Classes Dynamic Memory Allocation and Data Structures Linked List insert, delete, isEmpty, printList Stacks push, pop Queues enqueue, dequeue Trees insertNode, inOrder, preOrder, postOrder Introduction Fixed-size data structures such as one-dimensional arrays and two- dimensional arrays. Dynamic data structures that grow and shrink during execution. Linked lists are collections of data items logically “lined up in a row” insertions and removals are made anywhere in a linked list. Stacks are important in compilers and operating systems: Insertions and removals are made only at one end of a stack—its top. Queues represent waiting lines; insertions are made at the back (also referred to as the tail) of a queue removals are made from the front (also referred to as the head) of a queue. Binary trees facilitate high-speed searching and sorting of data, efficient elimination of duplicate data items, representation of file-system directories compilation of expressions into machine language. Introduction (cont.) Classes, class templates, inheritance and composition is used to create and package these data structures for reusability and maintainability. Standard Template Library (STL) The STL is a major portion of the C++ Standard Library. The STL provides containers, iterators for traversing those containers algorithms for processing the containers’ elements. The STL packages data structures into templatized classes. The STL code is carefully written to be portable, efficient and extensible. Self-Referential Classes A self-referential class contains a pointer member that points to a class object of the same class type.
    [Show full text]
  • ETSI TS 102 222 V7.0.0 (2006-08) Technical Specification
    ETSI TS 102 222 V7.0.0 (2006-08) Technical Specification Integrated Circuit Cards (ICC); Administrative commands for telecommunications applications (Release 7) Release 7 2 ETSI TS 102 222 V7.0.0 (2006-08) Reference RTS/SCP-T00368 Keywords GSM, smart card, UMTS ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http://portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media.
    [Show full text]
  • 13 Templates-Generics.Pdf
    CS 242 2012 Generic programming in OO Languages Reading Text: Sections 9.4.1 and 9.4.3 J Koskinen, Metaprogramming in C++, Sections 2 – 5 Gilad Bracha, Generics in the Java Programming Language Questions • If subtyping and inheritance are so great, why do we need type parameterization in object- oriented languages? • The great polymorphism debate – Subtype polymorphism • Apply f(Object x) to any y : C <: Object – Parametric polymorphism • Apply generic <T> f(T x) to any y : C Do these serve similar or different purposes? Outline • C++ Templates – Polymorphism vs Overloading – C++ Template specialization – Example: Standard Template Library (STL) – C++ Template metaprogramming • Java Generics – Subtyping versus generics – Static type checking for generics – Implementation of Java generics Polymorphism vs Overloading • Parametric polymorphism – Single algorithm may be given many types – Type variable may be replaced by any type – f :: tt => f :: IntInt, f :: BoolBool, ... • Overloading – A single symbol may refer to more than one algorithm – Each algorithm may have different type – Choice of algorithm determined by type context – Types of symbol may be arbitrarily different – + has types int*intint, real*realreal, ... Polymorphism: Haskell vs C++ • Haskell polymorphic function – Declarations (generally) require no type information – Type inference uses type variables – Type inference substitutes for variables as needed to instantiate polymorphic code • C++ function template – Programmer declares argument, result types of fctns – Programmers
    [Show full text]
  • C DEFINES and C++ TEMPLATES Professor Ken Birman
    Professor Ken Birman C DEFINES AND C++ TEMPLATES CS4414 Lecture 10 CORNELL CS4414 - FALL 2020. 1 COMPILE TIME “COMPUTING” In lecture 9 we learned about const, constexpr and saw that C++ really depends heavily on these Ken’s solution to homework 2 runs about 10% faster with extensive use of these annotations Constexpr underlies the “auto” keyword and can sometimes eliminate entire functions by precomputing their results at compile time. Parallel C++ code would look ugly without normal code structuring. Const and constexpr allow the compiler to see “beyond” that and recognize parallelizable code paths. CORNELL CS4414 - FALL 2020. 2 … BUT HOW FAR CAN WE TAKE THIS IDEA? Today we will look at the concept of programming the compiler using the templating layer of C++ We will see that it is a powerful tool! There are also programmable aspects of Linux, and of the modern hardware we use. By controlling the whole system, we gain speed and predictability while writing elegant, clean code. CORNELL CS4414 - FALL 2020. 3 IDEA MAP FOR TODAY History of generics: #define in C Templates are easy to create, if you stick to basics The big benefit compared to Java is that a template We have seen a number of parameterized is a compile-time construct, whereas in Java a generic types in C++, like std::vector and std::map is a run-time construct. The template language is Turing-complete, but computes These are examples of “templates”. only on types, not data from the program (even when They are like generics in Java constants are provided).
    [Show full text]
  • The Gaudi Reflection Tool Crash Course
    SDLT Single File Template 1 4. Sept. 2001 Version/Issue: 2/1 European Laboratory for Particle Physics Laboratoire Européen pour la Physique des Particules CH-1211 Genève 23 - Suisse The Gaudi Reflection Tool Crash Course Document Version: 1 Document Date: 4. Sept. 2001 Document Status: Draft Document Author: Stefan Roiser Abstract 1 Introduction The Gaudi Reflection Tool is a model for the metarepresentation of C++ classes. This model has to be filled with the corresponding information to each class that shall be represented through this model. Ideally the writing of this information and filling of the model will be done during the creation of the real classes. Once the model is filled with information a pointer to the real class will be enough to enter this model and retrieve information about the real class. If there are any relations to other classes, and the information about these corresponding classes is also part of the metamodel one can jump to these classes and also retrieve information about them. So an introspection of C++ classes from an external point of view can be realised quite easily. 2 The Meta Model The struture of the Gaudi Reflection Model is divided into four parts. These four parts are represented by four C++-classes. The corepart is the class called MetaClass. Within this class everything relevant to the real object will be stored. This information includes the name, a description, the author, the list of methods, members and constructors of this class etc. This class is also the entrypoint to the MetaModel. Using the MetaClass function forName and the Template page 1 SDLT Single File Template 2 The Meta Model Version/Issue: 2/1 string of the type of the real class as an argument, a pointer to the corresponding instance of MetaClass will be returned.
    [Show full text]
  • Static Reflection
    N3996- Static reflection Document number: N3996 Date: 2014-05-26 Project: Programming Language C++, SG7, Reflection Reply-to: Mat´uˇsChochl´ık([email protected]) Static reflection How to read this document The first two sections are devoted to the introduction to reflection and reflective programming, they contain some motivational examples and some experiences with usage of a library-based reflection utility. These can be skipped if you are knowledgeable about reflection. Section3 contains the rationale for the design decisions. The most important part is the technical specification in section4, the impact on the standard is discussed in section5, the issues that need to be resolved are listed in section7, and section6 mentions some implementation hints. Contents 1. Introduction4 2. Motivation and Scope6 2.1. Usefullness of reflection............................6 2.2. Motivational examples.............................7 2.2.1. Factory generator............................7 3. Design Decisions 11 3.1. Desired features................................. 11 3.2. Layered approach and extensibility...................... 11 3.2.1. Basic metaobjects........................... 12 3.2.2. Mirror.................................. 12 3.2.3. Puddle.................................. 12 3.2.4. Rubber................................. 13 3.2.5. Lagoon................................. 13 3.3. Class generators................................ 14 3.4. Compile-time vs. Run-time reflection..................... 16 4. Technical Specifications 16 4.1. Metaobject Concepts.............................
    [Show full text]