Opaque pointer: Difference between revisions
(45 intermediate revisions by 35 users not shown) | |||
Line 1: | Line 1: | ||
{{Short description|Opaque data type which stores a memory address}} |
|||
In [[computer programming]], an '''opaque pointer''' is a special case of an [[opaque data type]], a [[datatype]] declared to be a [[pointer (computer science)|pointer]] to a [[record (computer science)|record]] or [[data structure]] of some unspecified type. |
|||
In [[computer programming]], an '''opaque pointer''' is a special case of an [[opaque data type]], a [[data type]] declared to be a [[pointer (computer science)|pointer]] to a [[record (computer science)|record]] or [[data structure]] of some unspecified type. |
|||
Opaque pointers are present in several [[programming language]]s including [[Ada (programming language)|Ada]], [[C (programming language)|C]], [[C++]] and [[Modula-2]]. |
Opaque pointers are present in several [[programming language]]s including [[Ada (programming language)|Ada]], [[C (programming language)|C]], [[C++]], [[D (programming language)|D]] and [[Modula-2]]. |
||
If the language is [[strong typing|strongly typed]], [[Computer program|program]]s and [[subroutine|procedures]] that have no other information about an opaque pointer type ''T'' can still declare [[variable (programming)|variable]]s, [[Array data structure|arrays]], and record fields of type ''T'', assign values of that type, and compare those values for equality. However, they will not be able to [[reference (computer science)|de-reference]] such a pointer, and can only change the object's content by calling some procedure that has the missing information. |
If the language is [[strong typing|strongly typed]], [[Computer program|program]]s and [[subroutine|procedures]] that have no other information about an opaque pointer type ''T'' can still declare [[variable (programming)|variable]]s, [[Array data structure|arrays]], and record fields of type ''T'', assign values of that type, and compare those values for equality. However, they will not be able to [[reference (computer science)|de-reference]] such a pointer, and can only change the object's content by calling some procedure that has the missing information. |
||
Line 9: | Line 10: | ||
| title = Programming Tools — Opaque Pointers |
| title = Programming Tools — Opaque Pointers |
||
| publisher = QNX Software Systems |
| publisher = QNX Software Systems |
||
| url = http:// |
| url = http://community.qnx.com/sf/docman/do/downloadDocument/projects.toolchain/docman.root.articles/doc1150 |
||
| |
| access-date = 2019-01-16 |
||
}}</ref> This is important for providing [[binary code compatibility]] through different versions of a [[shared library]], for example. |
}}</ref> This is important for providing [[binary code compatibility]] through different versions of a [[shared library]], for example. |
||
This technique is described in [[Design Patterns]] as the [[Bridge pattern]]. It is sometimes referred to as "'''[[Handle (computing)|handle]] classes'''",<ref name="eckel20000">{{cite book |
This technique is described in ''[[Design Patterns]]'' as the [[Bridge pattern]]. It is sometimes referred to as "'''[[Handle (computing)|handle]] classes'''",<ref name="eckel20000">{{cite book |author = Bruce Eckel |author-link = Bruce Eckel |year = 2000 |
||
|title = Thinking in C++, Volume 1: Introduction to Standard C++ |
|||
| author = [[Bruce Eckel]] |
|||
|url = https://archive.org/details/thinkinginc00ecke |
|||
| year = 2000 |
|||
|chapter = Chapter 5: Hiding the Implementation |
|||
| title = Thinking in C++, Volume 1: Introduction to Standard C++ |
|||
| |
|chapter-url = http://web.mit.edu/merolish/ticpp/Chapter05.html |
||
|edition = 2nd |
|||
| chapter = Chapter 5: Hiding the Implementation |
|||
|publisher = Prentice Hall |
|||
| chapterurl = http://www.codeguru.com/cpp/tic/tic0067.shtml |
|||
| |
|isbn = 0-13-979809-9 |
||
|url-access = registration |
|||
| publisher = Prentice Hall |
|||
}}</ref> the "'''Pimpl idiom'''" (for "pointer to implementation idiom"),<ref>{{cite journal |
|||
| isbn = 0-13-979809-9 |
|||
}}</ref> the "'''Pimpl idiom'''" (for "pointer to implementation idiom"),<ref>{{cite journal |
|||
| author = Vladimir Batov |
| author = Vladimir Batov |
||
| title = Making Pimpl Easy |
| title = Making Pimpl Easy |
||
Line 29: | Line 29: | ||
| journal = [[Dr. Dobb's Journal]] |
| journal = [[Dr. Dobb's Journal]] |
||
| url = http://ddj.com/cpp/205918714 |
| url = http://ddj.com/cpp/205918714 |
||
| |
| access-date = 2008-05-07 |
||
}}</ref> "'''Compiler firewall idiom'''"<ref>Herb Sutter. ''[http://www.gotw.ca/publications/mill05.htm The Joy of Pimpls (or, More About the Compiler-Firewall Idiom)]''</ref> or "'''Cheshire Cat'''", especially among the C++ community.<ref name="eckel20000"/> |
}}</ref> "'''Compiler firewall idiom'''",<ref>Herb Sutter. ''[http://www.gotw.ca/publications/mill05.htm The Joy of Pimpls (or, More About the Compiler-Firewall Idiom)]''</ref> "'''d-pointer"''' or "'''Cheshire Cat'''", especially among the C++ community.<ref name="eckel20000"/> |
||
<!-- The latter term is attributed to [[John Carolan]], one of the early pioneers in C++. The implementation disappears (the cat), except a pointer to it (the smile) --> |
<!-- The latter term is attributed to [[John Carolan]], one of the early pioneers in C++. The implementation disappears (the cat), except a pointer to it (the smile) --> |
||
== Examples == |
== Examples == |
||
=== Ada === |
=== Ada === |
||
< |
<syntaxhighlight lang="ada"> |
||
package Library_Interface is |
package Library_Interface is |
||
Line 46: | Line 47: | ||
type Handle is access Hidden_Implementation; |
type Handle is access Hidden_Implementation; |
||
end Library_Interface; |
end Library_Interface; |
||
</syntaxhighlight> |
|||
</source> |
|||
The type <code>Handle</code> is an opaque pointer to the real implementation, that is not defined in the specification. Note that the type is not only private (to forbid the clients from accessing the type directly, and only through the operations), but also limited (to avoid the copy of the data structure, and thus preventing dangling references). |
The type <code>Handle</code> is an opaque pointer to the real implementation, that is not defined in the specification. Note that the type is not only private (to forbid the clients from accessing the type directly, and only through the operations), but also limited (to avoid the copy of the data structure, and thus preventing dangling references). |
||
< |
<syntaxhighlight lang="ada"> |
||
package body Library_Interface is |
package body Library_Interface is |
||
Line 58: | Line 59: | ||
end Library_Interface; |
end Library_Interface; |
||
</syntaxhighlight> |
|||
</source> |
|||
These types are sometimes called "'''Taft types'''"—named after [[Tucker Taft]], the main designer of Ada 95—because they were introduced in the so-called Taft Amendment to Ada 83.<ref>{{cite newsgroup |
These types are sometimes called "'''Taft types'''"—named after [[Tucker Taft]], the main designer of Ada 95—because they were introduced in the so-called Taft Amendment to Ada 83.<ref>{{cite newsgroup |
||
| title = Re: What's its name again? |
| title = Re: What's its name again? |
||
Line 65: | Line 66: | ||
| newsgroup = comp.lang.ada |
| newsgroup = comp.lang.ada |
||
| url = http://groups.google.es/group/comp.lang.ada/msg/a886bf7922727acf |
| url = http://groups.google.es/group/comp.lang.ada/msg/a886bf7922727acf |
||
| |
| access-date = 2007-10-11 |
||
}}</ref> |
}}</ref> |
||
=== C === |
=== C === |
||
< |
<syntaxhighlight lang="c"> |
||
/* obj.h */ |
/* obj.h */ |
||
Line 81: | Line 82: | ||
size_t obj_size(void); |
size_t obj_size(void); |
||
void obj_setid(struct obj *, int); |
|||
int obj_getid(struct obj |
int obj_getid(struct obj *); |
||
</syntaxhighlight> |
|||
</source> |
|||
< |
<syntaxhighlight lang="c"> |
||
/* obj.c */ |
/* obj.c */ |
||
Line 100: | Line 101: | ||
*/ |
*/ |
||
size_t |
size_t obj_size(void) { |
||
obj_size(void) |
|||
{ |
|||
return sizeof(struct obj); |
return sizeof(struct obj); |
||
} |
} |
||
void obj_setid(struct obj *o, int i) { |
|||
int |
|||
obj_setid(struct obj *o, int i) |
|||
{ |
|||
if (o == NULL) return -1; |
|||
o->id = i; |
o->id = i; |
||
return 0; |
|||
} |
} |
||
int obj_getid(struct obj *o) { |
|||
int |
|||
return o->id; |
|||
obj_getid(struct obj *o, int *i) |
|||
{ |
|||
if (o == NULL || i == NULL) return -1; |
|||
*i = o->id; |
|||
return 0; |
|||
} |
} |
||
</syntaxhighlight> |
|||
</source> |
|||
This example demonstrates a way to achieve the [[information hiding]] ([[encapsulation (computer science)|encapsulation]]) aspect of [[ |
This example demonstrates a way to achieve the [[information hiding]] ([[encapsulation (computer science)|encapsulation]]) aspect of [[object-oriented programming]] using the C language. If someone wanted to change the definition of <code>struct obj</code>, it would be unnecessary to recompile any other modules in the program that use the <code>obj.h</code> header file unless the [[API]] was also changed. Note that it may be desirable for the functions to check that the passed pointer is not <code>NULL</code>, but such checks have been omitted above for brevity. |
||
=== C++ === |
=== C++ === |
||
< |
<syntaxhighlight lang="cpp"> |
||
/* PublicClass.h */ |
|||
//header file: |
|||
class Handle { |
|||
public: |
|||
Handle(); // Constructor |
|||
Handle(const Handle&); // Copy constructor |
|||
Handle(Handle&&); // Move constructor |
|||
Handle& operator=(const Handle&); // Copy assignment operator |
|||
~Handle(); // Destructor |
|||
// Other operations... |
|||
#include <memory> |
|||
private: |
|||
struct CheshireCat; // Not defined here |
|||
class PublicClass { |
|||
CheshireCat* smile; // Handle |
|||
public: |
|||
PublicClass(); // Constructor |
|||
PublicClass(const PublicClass&); // Copy constructor |
|||
PublicClass(PublicClass&&); // Move constructor |
|||
PublicClass& operator=(const PublicClass&); // Copy assignment operator |
|||
PublicClass& operator=(PublicClass&&); // Move assignment operator |
|||
~PublicClass(); // Destructor |
|||
// Other operations... |
|||
private: |
|||
struct CheshireCat; // Not defined here |
|||
std::unique_ptr<CheshireCat> d_ptr_; // Opaque pointer |
|||
}; |
}; |
||
</syntaxhighlight> |
|||
</source> |
|||
<source lang="cpp"> |
|||
<syntaxhighlight lang="cpp"> |
|||
//CPP file: |
|||
#include "handle.h" |
|||
/* PublicClass.cpp */ |
|||
#include "PublicClass.h" |
|||
struct |
struct PublicClass::CheshireCat { |
||
int a; |
|||
int b; |
|||
}; |
}; |
||
PublicClass::PublicClass() |
|||
Handle::Handle() |
|||
: |
: d_ptr_(std::make_unique<CheshireCat>()) { |
||
// Do nothing. |
|||
} |
} |
||
PublicClass::PublicClass(const PublicClass& other) |
|||
: |
: d_ptr_(std::make_unique<CheshireCat>(*other.d_ptr_)) { |
||
// Do nothing. |
|||
} |
} |
||
PublicClass::PublicClass(PublicClass&& other) = default; |
|||
: smile(0) |
|||
{ |
|||
std::swap(smile, other.smile); |
|||
} |
|||
PublicClass& PublicClass::operator=(const PublicClass &other) { |
|||
*d_ptr_ = *other.d_ptr_; |
|||
return *this; |
|||
} |
} |
||
PublicClass& PublicClass::operator=(PublicClass&&) = default; |
|||
Handle::~Handle() { |
|||
delete smile; |
|||
PublicClass::~PublicClass() = default; |
|||
} |
|||
</source> |
|||
</syntaxhighlight> |
|||
One type of opaque pointer commonly used in C++ class declarations is the d-pointer. The d-pointer is the only private data member of the class and points to an instance of a struct. Named by [[Arnt Gulbrandsen]] of [[Trolltech]], this method allows class declarations to omit private data members, except for the d-pointer itself.<ref>''[http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++#Using_a_d-Pointer Using a d-Pointer]'' — Why and how KDE implements opaque pointers</ref> The result: (a) more of the class implementation is hidden from view; (b) adding new data members to the private struct does not affect binary compatibility; (c) the header file containing the class declaration only needs to #include those other files needed for the class interface, rather than for its implementation. One side benefit is that compilations are faster because the header file changes less often. The d-pointer is heavily used in the [[Qt (toolkit)|Qt]] and [[KDE]] libraries. |
|||
The d-pointer pattern is one of the implementations of the {{em| opaque pointer}}. It is commonly used in C++ classes due to its advantages (noted below). A d-pointer is a private data member of the class that points to an instance of a structure. This method allows class declarations to omit private data members, except for the d-pointer itself.<ref>''[https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#Using_a_d-Pointer Using a d-Pointer]'' — Why and how KDE implements opaque pointers</ref> As a result, |
|||
=== C# === |
|||
* more of the class implementation is hidden |
|||
See [[Private class data pattern]] |
|||
* adding new data members to the private structure does not affect [[binary compatibility]] |
|||
* the header file containing the class declaration only needs to include those files needed for the class interface, rather than for its implementation. |
|||
One side benefit is that compilations are faster because the header file changes less often. Note, possible disadvantage of d-pointer pattern is indirect member access through pointer (e.g., pointer to object in dynamic storage), which is sometimes slower than access to a plain, non-pointer member. The d-pointer is heavily used in the [[Qt (toolkit)|Qt]]<ref>{{Cite web|url=https://wiki.qt.io/D-Pointer|title=D-Pointer|website=Qt wiki|access-date=23 Dec 2016}}</ref> and [[KDE]] libraries. |
|||
== See also == |
== See also == |
||
Line 186: | Line 184: | ||
== References == |
== References == |
||
{{ |
{{Reflist}} |
||
== External links == |
== External links == |
||
{{Wikibooks|Ada Programming|Tips#Full declaration of a type can be deferred to the unit's body|Taft types}} |
{{Wikibooks|Ada Programming|Tips#Full declaration of a type can be deferred to the unit's body|Taft types}} |
||
{{Wikibooks|C++ Programming|Idioms#Pointer_To_Implementation_(pImpl)| the Pointer To Implementation (pImpl) idiom}} |
|||
* [http://c2.com/cgi/wiki?PimplIdiom The Pimpl idiom] |
* [http://c2.com/cgi/wiki?PimplIdiom The Pimpl idiom] |
||
* [http://www.gotw.ca/gotw/024.htm Compilation Firewalls] |
* [http://www.gotw.ca/gotw/024.htm Compilation Firewalls] or [https://herbsutter.com/gotw/_100/ Compilation Firewalls] |
||
* [http://www.gotw.ca/gotw/028.htm The Fast Pimpl Idiom] |
* [http://www.gotw.ca/gotw/028.htm The Fast Pimpl Idiom] |
||
* [ |
* [https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#Using_a_d-Pointer D-Pointers] — KDE TechBase |
||
* When you "XOR the pointer with a random number"[http://blogs.msdn.com/michael_howard/archive/2006/01/30/520200.aspx][http://udrepper.livejournal.com/13393.html], the result is a "really opaque" pointer [http://www.iecc.com/gclist/GC-faq.html#GC,%20C,%20and%20C++]. |
* When you "XOR the pointer with a random number"[http://blogs.msdn.com/michael_howard/archive/2006/01/30/520200.aspx][http://udrepper.livejournal.com/13393.html], the result is a "really opaque" pointer [http://www.iecc.com/gclist/GC-faq.html#GC,%20C,%20and%20C++]. |
||
* [http://www.ddj.com/cpp/205918714 Making Pimpl Easy], Vladimir Batov |
* [http://www.ddj.com/cpp/205918714 Making Pimpl Easy], Vladimir Batov |
||
Line 200: | Line 199: | ||
[[Category:Data types]] |
[[Category:Data types]] |
||
[[Category:C_(programming_language)]] |
|||
[[Category:C++]] |
[[Category:C++]] |
||
[[Category:Articles with example C++ code]] |
[[Category:Articles with example C++ code]] |
||
[[Category:Computer programming]] |
Latest revision as of 07:36, 5 April 2023
In computer programming, an opaque pointer is a special case of an opaque data type, a data type declared to be a pointer to a record or data structure of some unspecified type.
Opaque pointers are present in several programming languages including Ada, C, C++, D and Modula-2.
If the language is strongly typed, programs and procedures that have no other information about an opaque pointer type T can still declare variables, arrays, and record fields of type T, assign values of that type, and compare those values for equality. However, they will not be able to de-reference such a pointer, and can only change the object's content by calling some procedure that has the missing information.
Opaque pointers are a way to hide the implementation details of an interface from ordinary clients, so that the implementation may be changed without the need to recompile the modules using it. This benefits the programmer as well since a simple interface can be created, and most details can be hidden in another file.[1] This is important for providing binary code compatibility through different versions of a shared library, for example.
This technique is described in Design Patterns as the Bridge pattern. It is sometimes referred to as "handle classes",[2] the "Pimpl idiom" (for "pointer to implementation idiom"),[3] "Compiler firewall idiom",[4] "d-pointer" or "Cheshire Cat", especially among the C++ community.[2]
Examples
[edit]Ada
[edit]package Library_Interface is
type Handle is limited private;
-- Operations...
private
type Hidden_Implementation; -- Defined in the package body
type Handle is access Hidden_Implementation;
end Library_Interface;
The type Handle
is an opaque pointer to the real implementation, that is not defined in the specification. Note that the type is not only private (to forbid the clients from accessing the type directly, and only through the operations), but also limited (to avoid the copy of the data structure, and thus preventing dangling references).
package body Library_Interface is
type Hidden_Implementation is record
... -- The actual implementation can be anything
end record;
-- Definition of the operations...
end Library_Interface;
These types are sometimes called "Taft types"—named after Tucker Taft, the main designer of Ada 95—because they were introduced in the so-called Taft Amendment to Ada 83.[5]
C
[edit]/* obj.h */
struct obj;
/*
* The compiler considers struct obj an incomplete type. Incomplete types
* can be used in declarations.
*/
size_t obj_size(void);
void obj_setid(struct obj *, int);
int obj_getid(struct obj *);
/* obj.c */
#include "obj.h"
struct obj {
int id;
};
/*
* The caller will handle allocation.
* Provide the required information only
*/
size_t obj_size(void) {
return sizeof(struct obj);
}
void obj_setid(struct obj *o, int i) {
o->id = i;
}
int obj_getid(struct obj *o) {
return o->id;
}
This example demonstrates a way to achieve the information hiding (encapsulation) aspect of object-oriented programming using the C language. If someone wanted to change the definition of struct obj
, it would be unnecessary to recompile any other modules in the program that use the obj.h
header file unless the API was also changed. Note that it may be desirable for the functions to check that the passed pointer is not NULL
, but such checks have been omitted above for brevity.
C++
[edit]/* PublicClass.h */
#include <memory>
class PublicClass {
public:
PublicClass(); // Constructor
PublicClass(const PublicClass&); // Copy constructor
PublicClass(PublicClass&&); // Move constructor
PublicClass& operator=(const PublicClass&); // Copy assignment operator
PublicClass& operator=(PublicClass&&); // Move assignment operator
~PublicClass(); // Destructor
// Other operations...
private:
struct CheshireCat; // Not defined here
std::unique_ptr<CheshireCat> d_ptr_; // Opaque pointer
};
/* PublicClass.cpp */
#include "PublicClass.h"
struct PublicClass::CheshireCat {
int a;
int b;
};
PublicClass::PublicClass()
: d_ptr_(std::make_unique<CheshireCat>()) {
// Do nothing.
}
PublicClass::PublicClass(const PublicClass& other)
: d_ptr_(std::make_unique<CheshireCat>(*other.d_ptr_)) {
// Do nothing.
}
PublicClass::PublicClass(PublicClass&& other) = default;
PublicClass& PublicClass::operator=(const PublicClass &other) {
*d_ptr_ = *other.d_ptr_;
return *this;
}
PublicClass& PublicClass::operator=(PublicClass&&) = default;
PublicClass::~PublicClass() = default;
The d-pointer pattern is one of the implementations of the opaque pointer. It is commonly used in C++ classes due to its advantages (noted below). A d-pointer is a private data member of the class that points to an instance of a structure. This method allows class declarations to omit private data members, except for the d-pointer itself.[6] As a result,
- more of the class implementation is hidden
- adding new data members to the private structure does not affect binary compatibility
- the header file containing the class declaration only needs to include those files needed for the class interface, rather than for its implementation.
One side benefit is that compilations are faster because the header file changes less often. Note, possible disadvantage of d-pointer pattern is indirect member access through pointer (e.g., pointer to object in dynamic storage), which is sometimes slower than access to a plain, non-pointer member. The d-pointer is heavily used in the Qt[7] and KDE libraries.
See also
[edit]References
[edit]- ^ Chris McKillop. "Programming Tools — Opaque Pointers". QNX Software Systems. Retrieved 2019-01-16.
- ^ a b Bruce Eckel (2000). "Chapter 5: Hiding the Implementation". Thinking in C++, Volume 1: Introduction to Standard C++ (2nd ed.). Prentice Hall. ISBN 0-13-979809-9.
- ^ Vladimir Batov (2008-01-25). "Making Pimpl Easy". Dr. Dobb's Journal. Retrieved 2008-05-07.
- ^ Herb Sutter. The Joy of Pimpls (or, More About the Compiler-Firewall Idiom)
- ^ Robert A. Duff (2002-07-29). "Re: What's its name again?". Newsgroup: comp.lang.ada. Retrieved 2007-10-11.
- ^ Using a d-Pointer — Why and how KDE implements opaque pointers
- ^ "D-Pointer". Qt wiki. Retrieved 23 Dec 2016.
External links
[edit]- The Pimpl idiom
- Compilation Firewalls or Compilation Firewalls
- The Fast Pimpl Idiom
- D-Pointers — KDE TechBase
- When you "XOR the pointer with a random number"[1][2], the result is a "really opaque" pointer [3].
- Making Pimpl Easy, Vladimir Batov