Category
Modifiers, C++Builder keyword extensions
Syntax
cdecl ;
_cdecl ;
__cdecl ;
Description
Use a cdecl, _cdecl, or __cdecl modifier to declare a variable or a function using the C-style naming conventions (case-sensitive, with a leading underscore appended). When you use cdecl, _cdecl, or __cdecl in front of a function, it affects how the parameters are passed (parameters are pushed right to left, and the caller cleans up the stack). The __cdecl modifier overrides the compiler directives and IDE options.
The cdecl, _cdecl, and __cdecl keywords are specific to C++Builder.
Wednesday, May 13, 2009
_fastcall, __fastcall
Category
Modifiers, C++Builder keyword extensions
Syntax
return-value _fastcall function-name(parm-list)
return-value __fastcall function-name(parm-list)
Description
Use the __fastcall modifier to declare functions that expect parameters to be passed in registers. The first three parameters are passed (from left to right) in EAX, EDX, and ECX, if they fit in the register. The registers are not used if the parameter is a floating-point or struct type.
All form class member functions must use the __fastcall convention.
The compiler treats this calling convention as a new language specifier, along the lines of _cdecl and _pascal
Functions declared using _cdecl or _pascal cannot also have the _fastcall modifiers because they use the stack to pass parameters. Likewise, the __fastcall modifier cannot be used together with _export
The compiler prefixes the __fastcall function name with an at-sign ("@"). This prefix applies to both unmangled C function names and to mangled C++ function names.
For Microsoft VC++ style __fastcall implementation, see __msfastcall and __msreturn.
NB:The __fastcall modifier is subject to name mangling.
Modifiers, C++Builder keyword extensions
Syntax
return-value _fastcall function-name(parm-list)
return-value __fastcall function-name(parm-list)
Description
Use the __fastcall modifier to declare functions that expect parameters to be passed in registers. The first three parameters are passed (from left to right) in EAX, EDX, and ECX, if they fit in the register. The registers are not used if the parameter is a floating-point or struct type.
All form class member functions must use the __fastcall convention.
The compiler treats this calling convention as a new language specifier, along the lines of _cdecl and _pascal
Functions declared using _cdecl or _pascal cannot also have the _fastcall modifiers because they use the stack to pass parameters. Likewise, the __fastcall modifier cannot be used together with _export
The compiler prefixes the __fastcall function name with an at-sign ("@"). This prefix applies to both unmangled C function names and to mangled C++ function names.
For Microsoft VC++ style __fastcall implementation, see __msfastcall and __msreturn.
NB:The __fastcall modifier is subject to name mangling.
TClientDataSet::AppendData and TClientDataSet::BeforeGetRecords
TClientDataSet::AppendData
Adds a newly fetched packet of records to those already stored in the client dataset.
void __fastcall AppendData(const System::OleVariant &Data, bool HitEOF);
Description
Use AppendData to add a newly fetched packet of records from the server application to the client dataset. Data indicates the packet of records to add. HitEOF indicates whether or not the application server encountered the end of the dataset when it fetched the records from the database server.
Most applications call GetNextPacket instead to fetch a packet of records and automatically add them to those already available. Use AppendData when fetching data packets directly from the application server rather than letting the client dataset fetch data.
TClientDataSet::BeforeGetRecords
Occurs before the client dataset fetches a data packet from the application server.
__property TRemoteEvent BeforeGetRecords = {read=FBeforeGetRecords, write=FBeforeGetRecords};
Description
Write a BeforeGetRecords event handler to send custom information to the client dataset’s provider. BeforeGetRecords is part of the mechanism by which a client dataset and a remote provider communicate information about data fetching. When working with a provider on a stateless application server, this mechanism allows the client dataset and the provider to communicate persistent state information.
When the client dataset fetches data from the application server, the following events occur:
1.The client dataset receives a BeforeGetRecords event, where it can encode custom information into an OleVariant that is passed to the application server as the OwnerData parameter.
2.The provider on the application server receives a BeforeGetRecords event, where it can respond to or change that information before the provider creates a data packet.
3.The provider generates the data packet.
4.The provider receives an AfterGetRecords event, where it can encode custom information into its OwnerData parameter or respond to information from the BeforeGetRecords event handler.
5.The client dataset receives an AfterGetRecords event, where it can respond to the custom information returned by the provider in its AfterGetRecords event handler
Adds a newly fetched packet of records to those already stored in the client dataset.
void __fastcall AppendData(const System::OleVariant &Data, bool HitEOF);
Description
Use AppendData to add a newly fetched packet of records from the server application to the client dataset. Data indicates the packet of records to add. HitEOF indicates whether or not the application server encountered the end of the dataset when it fetched the records from the database server.
Most applications call GetNextPacket instead to fetch a packet of records and automatically add them to those already available. Use AppendData when fetching data packets directly from the application server rather than letting the client dataset fetch data.
TClientDataSet::BeforeGetRecords
Occurs before the client dataset fetches a data packet from the application server.
__property TRemoteEvent BeforeGetRecords = {read=FBeforeGetRecords, write=FBeforeGetRecords};
Description
Write a BeforeGetRecords event handler to send custom information to the client dataset’s provider. BeforeGetRecords is part of the mechanism by which a client dataset and a remote provider communicate information about data fetching. When working with a provider on a stateless application server, this mechanism allows the client dataset and the provider to communicate persistent state information.
When the client dataset fetches data from the application server, the following events occur:
1.The client dataset receives a BeforeGetRecords event, where it can encode custom information into an OleVariant that is passed to the application server as the OwnerData parameter.
2.The provider on the application server receives a BeforeGetRecords event, where it can respond to or change that information before the provider creates a data packet.
3.The provider generates the data packet.
4.The provider receives an AfterGetRecords event, where it can encode custom information into its OwnerData parameter or respond to information from the BeforeGetRecords event handler.
5.The client dataset receives an AfterGetRecords event, where it can respond to the custom information returned by the provider in its AfterGetRecords event handler
 |
| Kenya Affordable Safaris |
TClientDataSet::AfterGetRecords
TClientDataSet::AfterGetRecords
Occurs after the client dataset fetches a data packet from the application server.
__property TRemoteEvent AfterGetRecords = {read=FAfterGetRecords, write=FAfterGetRecords};
Description
Write an AfterGetRecords event handler to respond to custom information returned to the client dataset from a provider’s AfterGetRecords event handler. AfterGetRecords is part of the mechanism by which a client dataset and a remote provider communicate information about data fetching. When working with a provider on a stateless application server, this mechanism allows the client dataset and the provider to communicate persistent state information.
When the client dataset fetches data from the application server, the following events occur:
1.The client dataset receives a BeforeGetRecords event, where it can encode custom information into an OleVariant that is passed to the application server as the OwnerData parameter.
2.The provider on the application server receives a BeforeGetRecords event, where it can respond to or change that information before the provider creates a data packet.
3.The provider generates an OnGetData event where it can edit the data before creating a data packet, and then generates the data packet.
4.The provider receives an AfterGetRecords event, where it can encode custom information into its OwnerData parameter or respond to information from the BeforeGetRecords event handler.
5.The client dataset receives an AfterGetRecords event, where it can respond to the custom information returned by the provider in its AfterGetRecords event handler.
Occurs after the client dataset fetches a data packet from the application server.
__property TRemoteEvent AfterGetRecords = {read=FAfterGetRecords, write=FAfterGetRecords};
Description
Write an AfterGetRecords event handler to respond to custom information returned to the client dataset from a provider’s AfterGetRecords event handler. AfterGetRecords is part of the mechanism by which a client dataset and a remote provider communicate information about data fetching. When working with a provider on a stateless application server, this mechanism allows the client dataset and the provider to communicate persistent state information.
When the client dataset fetches data from the application server, the following events occur:
1.The client dataset receives a BeforeGetRecords event, where it can encode custom information into an OleVariant that is passed to the application server as the OwnerData parameter.
2.The provider on the application server receives a BeforeGetRecords event, where it can respond to or change that information before the provider creates a data packet.
3.The provider generates an OnGetData event where it can edit the data before creating a data packet, and then generates the data packet.
4.The provider receives an AfterGetRecords event, where it can encode custom information into its OwnerData parameter or respond to information from the BeforeGetRecords event handler.
5.The client dataset receives an AfterGetRecords event, where it can respond to the custom information returned by the provider in its AfterGetRecords event handler.
TClientDataSet::GetNextPacket
TClientDataSet::GetNextPacket
Retrieves the next block of records from the application server.
int __fastcall GetNextPacket(void);
Description
Call GetNextPacket to retrieve the next sequential block of records from the application server. To specify the maximum number of records to return in a packet, set the PacketRecords property before calling GetNextPacket. A packet is appended to those records already stored in the Data property.
GetNextPacket returns the number of records added to Data. If the return value is 0, the client application has already received all available records from the application server.
Warning:If the client dataset uses a stateless application server, you must use a BeforeGetRecords event handler to ensure that the data packet returns the correct set of records.
TClientDataSet
TClientDataSet implements a database-independent dataset.
Unit
dbclient
Description
TClientDataSet encapsulates a database-independent, distributed dataset. A client dataset can be used as a
-Fully-functional, standalone, flat-file dataset for single-tiered database applications. When used in this manner, an application uses the client dataset to read from and write to a user’s hard disk directly, without accessing a database engine.
-Client dataset in the client application portion of a multi-tiered database application.
NB:The two functions described above are not mutually exclusive. A multi-tiered application can be designed to support the option of working with data off-line, using the “briefcase” model. On site, the application uses TClientDataSet to communicate with the application server’s data provider. When a user works off site, the client dataset writes a snapshot of the data to the hard disk. The application works with this snapshot off site, with the client dataset acting as a flat-file dataset in a single-tiered application.
The client dataset can communicate with a data provider directly by calling the provider component’s methods. When used in a client application as part of a multi-tiered application, the client dataset passes all calls to the provider through the remote data module’s IAppServer interface.
Retrieves the next block of records from the application server.
int __fastcall GetNextPacket(void);
Description
Call GetNextPacket to retrieve the next sequential block of records from the application server. To specify the maximum number of records to return in a packet, set the PacketRecords property before calling GetNextPacket. A packet is appended to those records already stored in the Data property.
GetNextPacket returns the number of records added to Data. If the return value is 0, the client application has already received all available records from the application server.
Warning:If the client dataset uses a stateless application server, you must use a BeforeGetRecords event handler to ensure that the data packet returns the correct set of records.
TClientDataSet
TClientDataSet implements a database-independent dataset.
Unit
dbclient
Description
TClientDataSet encapsulates a database-independent, distributed dataset. A client dataset can be used as a
-Fully-functional, standalone, flat-file dataset for single-tiered database applications. When used in this manner, an application uses the client dataset to read from and write to a user’s hard disk directly, without accessing a database engine.
-Client dataset in the client application portion of a multi-tiered database application.
NB:The two functions described above are not mutually exclusive. A multi-tiered application can be designed to support the option of working with data off-line, using the “briefcase” model. On site, the application uses TClientDataSet to communicate with the application server’s data provider. When a user works off site, the client dataset writes a snapshot of the data to the hard disk. The application works with this snapshot off site, with the client dataset acting as a flat-file dataset in a single-tiered application.
The client dataset can communicate with a data provider directly by calling the provider component’s methods. When used in a client application as part of a multi-tiered application, the client dataset passes all calls to the provider through the remote data module’s IAppServer interface.
__thread, multithread variables
Category
C++Builder keyword extensions
Description
The keyword __thread is used in multithread programs to preserve a unique copy of global and static class variables. Each program thread maintains a private copy of a __thread variable for each thread.
The syntax is Type __thread variable__name. For example
int __thread x;
declares an integer type variable that will be global but private to each thread in the program in which the statement occurs.
Using thread-local variables
The thread function and any of the routines it calls have their own local variables, just like any other C++ routines. These routines also can access any global variables. In fact, global variables provide a powerful mechanism for communicating between threads.
Sometimes, however, you may want to use variables that are global to all the routines running in your thread, but not shared with other instances of the same thread class. You can do this by declaring thread-local variables. Make a variable thread-local by adding the __thread modifier to the variable declaration. For example,
int __thread x;
declares an integer type variable that is private to each thread in the application, but global within each thread.
The __thread modifier can only be used for global (file-scope) and static variables. Pointer and Function variables can’t be thread variables. Types that use copy-on-write semantics, such as AnsiStrings don’t work as thread variables either. A program element that requires runtime initialization or runtime finalization cannot be declared to be a __thread type.
The following declarations require runtime initialization and are therefore illegal.
int f( );
int __thread x = f( ); // illegal
Instantiation of a class with a user-defined constructor or destructor requires runtime initialization and is therefore illegal:
class X {
X( );
~X( );
};
X __thread myclass; // illegal
C++Builder keyword extensions
Description
The keyword __thread is used in multithread programs to preserve a unique copy of global and static class variables. Each program thread maintains a private copy of a __thread variable for each thread.
The syntax is Type __thread variable__name. For example
int __thread x;
declares an integer type variable that will be global but private to each thread in the program in which the statement occurs.
Using thread-local variables
The thread function and any of the routines it calls have their own local variables, just like any other C++ routines. These routines also can access any global variables. In fact, global variables provide a powerful mechanism for communicating between threads.
Sometimes, however, you may want to use variables that are global to all the routines running in your thread, but not shared with other instances of the same thread class. You can do this by declaring thread-local variables. Make a variable thread-local by adding the __thread modifier to the variable declaration. For example,
int __thread x;
declares an integer type variable that is private to each thread in the application, but global within each thread.
The __thread modifier can only be used for global (file-scope) and static variables. Pointer and Function variables can’t be thread variables. Types that use copy-on-write semantics, such as AnsiStrings don’t work as thread variables either. A program element that requires runtime initialization or runtime finalization cannot be declared to be a __thread type.
The following declarations require runtime initialization and are therefore illegal.
int f( );
int __thread x = f( ); // illegal
Instantiation of a class with a user-defined constructor or destructor requires runtime initialization and is therefore illegal:
class X {
X( );
~X( );
};
X __thread myclass; // illegal
Creating and using a client dataset
TClientDataSet is a dataset component designed to work without the connectivity support of the Borland Database Engine (BDE) or ActiveX Data Objects (ADO). Instead, it uses MIDAS.DLL, which is much smaller and simpler to install and configure. You don’t use database or ADO connection components with client datasets, because there is no database connection.
Client datasets provide all the data access, editing, navigation, data constraint, and filtering support introduced by TDataSet. However, the application that uses a client dataset must provide the mechanism by which the client dataset reads data and writes updates. Client datasets provide for this in one of the following ways:
Reading from and writing to a flat file accessed directly from a client dataset component. This is the mechanism used by flat-file database applications.
-Reading from another dataset. Client datasets provide a variety of mechanisms for copying data from other datasets. These are described in Copying data from another dataset.
-Using an IAppServer interface to obtain data from and post updates to a remote application server. This is the mechanism used by clients in a multi-tiered database application.
These mechanisms can be combined into a single application that employs the “briefcase model”. Users take a snapshot of data, saving it to a flat-file so that they can work on it off-line. Later, the client application applies the changes from the local copy of data to the application server. The application server resolves them with the actual database, and returns errors to the client dataset for handling
TClientDataSet
TClientDataSet implements a database-independent dataset.
Unit
dbclient
Description
TClientDataSet encapsulates a database-independent, distributed dataset. A client dataset can be used as a
-Fully-functional, standalone, flat-file dataset for single-tiered database applications. When used in this manner, an application uses the client dataset to read from and write to a user’s hard disk directly, without accessing a database engine.
-Client dataset in the client application portion of a multi-tiered database application.
NB:The two functions described above are not mutually exclusive. A multi-tiered application can be designed to support the option of working with data off-line, using the “briefcase” model. On site, the application uses TClientDataSet to communicate with the application server’s data provider. When a user works off site, the client dataset writes a snapshot of the data to the hard disk. The application works with this snapshot off site, with the client dataset acting as a flat-file dataset in a single-tiered application.
The client dataset can communicate with a data provider directly by calling the provider component’s methods. When used in a client application as part of a multi-tiered application, the client dataset passes all calls to the provider through the remote data module’s IAppServer interface.
Client datasets provide all the data access, editing, navigation, data constraint, and filtering support introduced by TDataSet. However, the application that uses a client dataset must provide the mechanism by which the client dataset reads data and writes updates. Client datasets provide for this in one of the following ways:
Reading from and writing to a flat file accessed directly from a client dataset component. This is the mechanism used by flat-file database applications.
-Reading from another dataset. Client datasets provide a variety of mechanisms for copying data from other datasets. These are described in Copying data from another dataset.
-Using an IAppServer interface to obtain data from and post updates to a remote application server. This is the mechanism used by clients in a multi-tiered database application.
These mechanisms can be combined into a single application that employs the “briefcase model”. Users take a snapshot of data, saving it to a flat-file so that they can work on it off-line. Later, the client application applies the changes from the local copy of data to the application server. The application server resolves them with the actual database, and returns errors to the client dataset for handling
TClientDataSet
TClientDataSet implements a database-independent dataset.
Unit
dbclient
Description
TClientDataSet encapsulates a database-independent, distributed dataset. A client dataset can be used as a
-Fully-functional, standalone, flat-file dataset for single-tiered database applications. When used in this manner, an application uses the client dataset to read from and write to a user’s hard disk directly, without accessing a database engine.
-Client dataset in the client application portion of a multi-tiered database application.
NB:The two functions described above are not mutually exclusive. A multi-tiered application can be designed to support the option of working with data off-line, using the “briefcase” model. On site, the application uses TClientDataSet to communicate with the application server’s data provider. When a user works off site, the client dataset writes a snapshot of the data to the hard disk. The application works with this snapshot off site, with the client dataset acting as a flat-file dataset in a single-tiered application.
The client dataset can communicate with a data provider directly by calling the provider component’s methods. When used in a client application as part of a multi-tiered application, the client dataset passes all calls to the provider through the remote data module’s IAppServer interface.
Subscribe to:
Posts (Atom)