 |
|
 |
#define ATT_LOWER_LIMIT_CH1 -60.0
- means what in vc++.net ATT is an edit control
selv
|
|
|
|
 |
|
 |
Firstly, you can have indexers of any depth, i.e. property[a][b] will convert a and b to parameters in put_ or get_
Secondly, did you know you can return by reference?
nous sommes les maitres
nous sommes les esclaves
nous sommes partout
nous sommes nul part
nous maitrisons les lettres noires
|
|
|
|
 |
|
 |
My question is how to declare an infinte array in language c?
That is like the form array[], which can take any number of data.
i have seen an example used in Laguage c i.e
int z
z=new array[]
|
|
|
|
 |
|
 |
C99 supports VLAs
nous sommes les maitres
nous sommes les esclaves
nous sommes partout
nous sommes nul part
nous maitrisons les lettres noires
|
|
|
|
 |
|
 |
it's not infinite array it should be dynamic array
As u r going to initialise that array during program execution.
It's syntax is
int z
z=new array[size];
where size is a variable whic accepts value during execution
|
|
|
|
 |
|
 |
I have seen this before and played with it for a while, however, you can use a C++ technique, which has the advantage of being portable. Use the Proxy class concept:
class MyClass
{
public:
class MyIntProxy
{
MyIntProxy(int nVal) : m_nValue(nVal)
{
}
int operator(const int & rVal)
{
m_nValue = rVal;
return m_nValue;
}
operator int()
{
return m_nValue;
}
private :
int m_nValue;
} m_Value;
};
So now I can use it as follows:
MyClass x;
x.m_Value = 10; // Calls assignment operator!
cout << x.m_Value; // Calls conversion operator!
The problem with this technique is that it requires more coding, and you need to provide Proxy classes for the data types you're going to use.
Anyways, thougth this might be of interest to you.
|
|
|
|
 |
|
 |
You can use MACROs to declare your properties' get/set methods so that you can use the same code in C++ Builder which also has get/set methods with different syntax. That will make it alittle bit more portable.
|
|
|
|
 |
|
 |
The major drawback of this technique is that you cannot access MyClass's vars and funcs from proxy class's operators.
Regards,
Dmitry
|
|
|
|
 |
|
 |
Hello!
This code is very very intresting, the main idea is known, but I am not familiar with the safe thread
problem.
I would like to ask some questions, which might sound basic but I really need to know their answers.
(1) Why is it needed to protect m_lValue1?
(2) What is the connection between m_lValue1 and m_lValueInternalValue1 ?
(3) Why all vars defined (any where) inside the struct must be NULLS?
(4) Is it true that GetValue1 and PutValue1 equal to m_lValue1? (as they are it's function expression, no?)
Thank you all,
Asaf Karass , 14, ISRAEL.
|
|
|
|
 |
|
 |
(1) Why is it needed to protect m_lValue1?
Response: If a C++ class / structure is to be accessed by multiple threads, it's members need to be protected because one thread could be reading the value while another is updating it.
Accessing classes from multiple threads is something that is specific to a particular application based on it's requirements and the programmer's skills.
(2) What is the connection between m_lValue1 and m_lValueInternalValue1 ?
[Response] m_lValue1 is a virtual property (i.e. it does not have any memory representation) and is replaced by the Get / Put functions.
m_lValueInternalValue1 is a new member that is defined to hold the actual value that the above Get / Put functions manipulate.
(3) Why all vars defined (any where) inside the struct must be NULLS?
Typically it is a good idea to initialize member variables to some value, not necessarily NULL.
(4) Is it true that GetValue1 and PutValue1 equal to m_lValue1? (as they are it's function expression, no?)
Yes.
|
|
|
|
 |
|
 |
Dear Jeremiah,
Lest there be any misunderstanding, let me explain that I think this is a useful technique you have outlined, particularly for the purpose you proposed, i.e. of maintaining legacy code.
Nevertheless, it is part and parcel of C++ that some programmers will not hestitate to use techniques of last resort as part of the primary everyday toolkit. They are the ones to whom I directed my comment (i.e. not "do not use this" but "do not use this if possible"). I also understand that these sorts of properties will become more integrated in the everyday life in upcoming versions of VC++. To good or ill we shall see.
A good rule of thumb, I think, is that structs exposing data members should be PODs. The problem is what can one do when in retrospect one (or more usually the previous programmer one put the blame on :-> ) has made a bad design decision.
The better programming option is to bite the bullet, for example, to hide the data members, provide inline functions. The advantage in this case is that the transition is sharp, all the client code will break and will have to be fixed. This is in contrast to code
changes causing silent breaks in client or dependent code which really cannot be safely propagated. (Which is
why I understand but do not sympathisize with MS's reluctance to embrace some aspects of ISO std compliance).
Of course, if more than say ten angry programmers who outweigh one depend on these structs then it may be practically impossible to do anything other than what you suggest.
Another alternative is to encapsulate the whole struct, i.e. provide struct level locking/ protection reference counting or the like.
One just has to evaluate all the pros and cons. Programming is about compromises and sensible decisions rather than alas perfection. The technique you outline will no doubt provide an additional option to us poor beleaguered VC++ users
|
|
|
|
 |
|
 |
Thanks for clarifying what you intented in your original note. I appreciate your views better now after reading this message.
Yes, it is important to point out what you have said here and I will ensure that in future articles, I will explicitly list any caveats, design alternatives etc. You feedback is taken in a positive light and it will help me in my future writings.
Thank you,
Jeremia
|
|
|
|
 |
|
 |
A good rule of thumb, I think, is that structs exposing data members should be PODs.
MMmmm, by POD I assume you mean piece of data
Phil Harding
|
|
|
|
 |
|
 |
I think this style of programming should be deprecated in C++.
Programming languages in the Pascal (Algo?) tradition and hence probably VB to some extent do not distinguish syntactically between function calls which do not take parameters and accessing variables. It thus is a natural extension to treat all accesses to object variables and parameterless object methods as if they were the former. The extensions of C++ in VC++ and C++ Builder (patterned after Delphi) are based on the same premiss.
I suspect it is a great mistake. C always insists on parathesizing function calls. In C++, the move is in the opposite direction to Pascal. Most programming "guru"s and style guides, for very good reasons, recommend that as a rule object data should not be exposed to the outside world, i.e. encapsulation, except for PODs and the like. These exceptions include structs which do not have virtual functions, do not participate in inheritance trees, are not polymorphic and, most importantly, where the public state of the object is immutably and completely described in all the data members (i.e. all data is "public" and there is no private state). Examples would thus include CRect and CPoint but not CString (because of reference counting).
In C++, even when direct and efficient access to data members is desired, the recommendation is to wrap this in inline functions. In other words, the difference between Object Pascal is that functions can be treated as variables whereas in C++ variables are be handled as functions.
The addition of this new language feature in C++ only encourages the wanton exposure of the innards of an object to the detriment of reuse and good design. Alas, neither of these latter qualities is always in evidence even among the programmers working in the company which makes the compiler...
Caveat
|
|
|
|
 |
|
 |
I agree with you totally on this, in that if you have the opportunity to write code from scratch then this method is sub optimal and should be avoided. However, the number of times a typical programmer is forced to deal with poorly written lagacy code makes this "emergency" technique very valuable indeed.
If only every programmer would read and follow the advice of such books as Code Complete etc. (including, as you say, those who published that book!
|
|
|
|
 |
|
 |
I think Chris Maunder has very succintly expressed what I myself would like to point out. All the same, I am adding a few views of my own.
I begin the article with the words "A lot of legacy C++ code exists..." and nowhere in the article do I propose using this technique as good programming practice.
All the same, you need to be aware of the 'Maintenance Phase' mentioned in any Software Engineering text and a pratical approach works better during this phase.
Knowing what is available and using it intelligently is more valuable in today's software development world. How many C++ and Object Oriented believer's have critisized COM / DCOM but look at how immensely successful it has been in solving real world business problems
|
|
|
|
 |
|
 |
I read ur article.
Since we added a new member
private:
long m_lInternalValue1;
for
long m_lValue1;
do we need to add new member like "long m_lInternalValue1;"
for each "long m_lValue1; "
if so that will increase the sise of the structure
|
|
|
|
 |
|
 |
Yes, you will need to add a private member for each member variable that you want to expose as a Virtual property.
You are correct in mentioning that this will increase the size of the structure but as long as the relevant modules are recompiled, this should not be an issue.
Remember that I have mentioned that this is very useful for legacy code where well known data encapsulation principles have not been followed
|
|
|
|
 |
|
 |
There is a simple way to implement the properties without
adding new (non-standard) features to compiler:
Just make a template class Property with two
overloaded operators:
T& operator=(const T&); // for assignment
operator T()(); // for read semantics
Then declare the property in your class:
class MyClass{
...
Property MyProp(GetProp, SetProp); // Get/SetProp() are
// access functions
};
I can't understand why Microsoft decided to extend the C++
standatd for this
|
|
|
|
 |
|
 |
Even though you do not follow correct template syntax in your example, I could immediately appreciate your technique. It is so simple yet so powerful.
I think the reason MS decided to use _declspec() to implement this is because the template support within MS compilers was a bit weak earlier on. Also, until recently, most C++ programmers were not very familiar with templates.
The MS technique can be used even by entry level C++ programmers (who are more likely to be used for maintenance of legacy code).
Thanks for your suggestion
|
|
|
|
 |
|
 |
I am not sure what I was thinking when I said that this technique will increase the size of the structure. It was late at night and I was about ready to go to sleep when I posted that message.
Anyway, effectively what is happening is that the actual structure members are being made virtual and corresponding members of the same type are added as private members.
Hence the structure size will be the same because the virtual members do not add tot he structure size. This explanation should make things more clear
|
|
|
|
 |
|
 |
The size of the structure does not increase because m_lValue1 is a veritual member. Each such member that is declared virtual will have a corresponding internal member of the same type. So the size of the structure remains the same.
Jeremiah S. Talkar
|
|
|
|
 |
|
 |
i want some projects by mfc iam study mcs,and need for it
|
|
|
|
 |
 | Nice  |  | Sandeep Bhatia | 11:14 12 Jan '00 |
|
|
 |
 | Cool  |  | George Poulose | 16:51 11 Jan '00 |
|
|
 |