|
|
Axter wrote: should avoid using leading underscores in your code, because it makes it non-portable.
Please read the language standard specification, ISO/IEC 14882:2003.
The well known non-portable one is '$'.
Axter wrote: a trialing underscore
Huh? 
Maxwell Chen
|
|
|
|
|
Is that where all the leading underscores are coming from????
I've been wondering why I've been seeing them more and more lately.
For the record: regarding ANSI specifications, ANSI.org and places like that. I'll be damned if i'm going to pay $291 so I can download a 2MB file of instructions telling me how I'm supposed to name my variables.
If I feel like using m_blahblah...or mixedUpperLower...or lower local and Upper global or whatever then tough.
I've been listening to this grand promise of making code portable for over 20 years now and I've lost count of how many times I've been told we're all doing it wrong.
At least 5 times I've changed to suit some imaginary standard and guess what? As soon as the next new compiler comes out we're told we aren't doing it right and we spend countless hours converting our supposed "portable" code anyway.
If you want to run along with ISO/IEC whatever, more power to you. Have fun and why not? There's nothing wrong with guidelines and doing things consistently (more to make everything readable than anything).
I'll make you a bet that within the next 5 years you'll be programming in a completely different environment, there's a new way and leading underscores are suddenly wrong. I have history on my side.
|
|
|
|
|
Phil C wrote: Is that where all the leading underscores are coming from????
I've been wondering why I've been seeing them more and more lately.
Nothing but just my habbit.
But you may write a letter to Microsoft to ask them: Why _tcstol(...) has that underscore.
You are not obligated to fix in certain naming way as:
m_MyValue;
_MyValue;
mMyValue;
MyValueMember;
ThisIsTheMemberVariableNamedMyValue;
thisismygoddamnmembervariable;
You rule the code. Feel free to name in your own way!
Phil C wrote: I'll be damned if i'm going to pay $291 so I can download a 2MB file of instructions telling me how I'm supposed to name my variables.
Those specifications are not only telling you how to name the variables.
As in this case, ISO/IEC 14882 just enumerates what letters we can use to name identifiers.
Phil C wrote: I've been listening to this grand promise of making code portable for over 20 years now and I've lost count of how many times I've been told we're all doing it wrong.
Yeah. Eight years ago when I was entering the programming field, I was told that C/C++ are the only portable.
The fact?! Not at all.
Phil C wrote: to run along with ISO/IEC
Personally, I don't like reading ISO or ANSI specs. They are written in alien language instead of human understandable English. I only look up in the spec when there is any doubt.
The same idea why you bought a dictionary. Your buying a dictionary not to learn how to write the letters [A ~ Z and a ~ z] but you need to look up the words which you don't know the meanings.
Maxwell Chen
|
|
|
|
|
Maxwell Chen wrote: Nothing but just my habbit.
But you may write a letter to Microsoft to ask them: Why _tcstol(...) has that underscore.
Microsoft is allowed to use leading underscore, because they're considered the implementation.
Leading underscores are reserved for the implementation, which is a cobination of the compiler and the OS.
So Microsoft is allowed to use the leading underscore, but IAW the standard, your own code should not.
One thing Microsoft is doing wrong, is using a leading underscore name followed by a lowercase name that can intrude all namespaces.
Since _tcstol is a macro, it can enter all namespaces.
If Microsoft use _Tcstol instead, then the name is allowed to intrude into all namespaces.
This is not a new standard, and it's been around since the first official C++ standard (1998).
Top ten member of C++ Expert Exchange.
http://www.experts-exchange.com/Cplusplus
|
|
|
|
|
Axter wrote: Microsoft is allowed to use leading underscore, because they're considered the implementation.
Leading underscores are reserved for the implementation, which is a cobination of the compiler and the OS.
So Microsoft is allowed to use the leading underscore, but IAW the standard, your own code should not.
One thing Microsoft is doing wrong, is using a leading underscore name followed by a lowercase name that can intrude all namespaces.
Since _tcstol is a macro, it can enter all namespaces.
If Microsoft use _Tcstol instead, then the name is allowed to intrude into all namespaces.
Section 17.4.3.1.2 in ISO/IEC 14882:2003
1. Certain sets of names and function signatures are always reserved to the implementation:
-- Each name that contains a double underscore (__) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use.
-- Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.
Maxwell Chen
|
|
|
|
|
Maxwell Chen wrote: Section 17.4.3.1.2 in ISO/IEC 14882:2003
1. Certain sets of names and function signatures are always reserved to the implementation:
-- Each name that contains a double underscore (__) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use.
-- Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.
I'm not sure why you posted the standard.
But I'll explain what the standard is stating, incase you think it contridicts my comment.
The first paragraph is stating that the implementation can use names that are prefxied with double underscore or underscore followed by an uppercase letter for ANY use.
Any use includes using them for MACROS.
#define _T(x) L ## x
That means these types of variables will enter ALL namespaces.
So if you have a local variable called _T, it will not compile if using a header with above macro.
The second paragraph is stating that the implementation can put any name that begins with an underscore inside the global namespace.
FILE * _wfdopen(int, const wchar_t *);
The above function is in the MS header files, and it enters the global namespace, but not local namespace.
So you can create a local variable named _wfdopen, and it will not conflict with the global namespace function.
So IAW C++ standard, it's safe to use a local variable with a leading underscore followed by a lowercase letter.
*** HOWEVER *** some implementations like MS use names with lowercase letters for macros, which means they intrude into all namespaces.
#define _tfdopen _wfdopen
#define _tfsopen _wfsopen
#define _tfopen _wfopen
So my general advise, is to avoid using names that begin with an underscore completely.
And if you feel you have to use an underscore, use a trailing underscore instead.
Example:
int MyFoo_; //Instead of _MyFoo
Top ten member of C++ Expert Exchange.
http://www.experts-exchange.com/Cplusplus
-- modified at 11:59 Sunday 7th May, 2006
|
|
|
|
|
Axter wrote: I'm not sure why you posted the standard.
But I'll explain what the standard is stating, incase you think it contridicts my comment.
Nothing! Just append the statement in the Standard as the reference to what you have said earlier.
And you explained very well! 
Maxwell Chen
|
|
|
|
|
Phil C wrote: At least 5 times I've changed to suit some imaginary standard and guess what?
This has been part of the official C++ standard for over 7 years.
Have you been changing it 5 times before the official standard, or after?
Phil C wrote: I'll be damned if i'm going to pay $291 so I can download a 2MB file of instructions telling me how I'm supposed to name my variables.
The original version of the standard doesn't cost that much.
Phil C wrote: I've been listening to this grand promise of making code portable for over 20 years now and I've lost count of how many times I've been told we're all doing it wrong.
The Official C++ standard has not change much since the original standard which is dated 1998.
If you want to avoid changing your code, I recommend you get the standard, so you do it right the first time.
Of course, you're free not to change it, and leave it as-is.
However, I find a lot of developers who complain about having to change their code when a new compiler comes out, are developers who are not following the standard to begin with.
Example:
Before VC++ 7.0 came out, a lot of C++ programmers where using non-standard header (like iostream.h) which never were part of the official C++ standard.
When those developers moved their code from VC++ 6.0 to VC++ 7.0, they suddenly found their code couldn't compile to the new compiler.
Developers can either keep to the standard, and avoid having to change their code, or they can ignore the standard, and enjoy having to revisit their code every time they move their code to a new compiler, or new version of the same compiler.
Top ten member of C++ Expert Exchange.
http://www.experts-exchange.com/Cplusplus
-- modified at 7:21 Sunday 7th May, 2006
|
|
|
|
|
Axter wrote: use a trialing underscore instead
Hi Axter,
Stephen and I are still interested in what a trialing underscore you mentioned is... 
Maxwell Chen
|
|
|
|
|
Maxwell Chen wrote: Stephen and I are still interested in what a trialing underscore you mentioned is...
Example:
int MyFoo_; //Instead of _MyFoo
Trailing underscore, meaning put it at the end, instead of the beginning.
Top ten member of C++ Expert Exchange.
http://www.experts-exchange.com/Cplusplus
|
|
|
|
|
Axter wrote: Trailing underscore, meaning put it at the end, instead of the beginning.
I see. Thank you very much! I was confused with the word "trialing".
Yes, I have seen that form also.
Maxwell Chen
|
|
|
|
|
plz tell me the fuction to find the ip address of my own system and i m working in console application using winsock header file.thank you
|
|
|
|
|
|
Hi,
to get localhost name:
GetComputerNameEx
to get IP from name:
addrinfo host;
LPADDRINFO res;
host.ai_flags = AI_CANONNAME;
host.ai_protocol = IPPROTO_TCP;
host.ai_family = PF_INET;
host.ai_socktype = SOCK_STREAM;
getaddrinfo( sMachineName, NULL, &host, &res );
-----------
Mila
|
|
|
|
|
Debug/Dialer.exe : fatal error LNK1120: 4 unresolved externals
|
|
|
|
|
Can you be more specific
Do you see MSDN
|
|
|
|
|
Can you provide more information ? How can we help you with so limited information.
Did you link to all necessary libraries ?
|
|
|
|
|
hi,
i guess this is a simple probelem where u forgot to link with your .lib file.
in the linker error you can get the function names which are not resolve.
and include the .lib file in your project > settings > link > Object/Library modules.
enter your .lib file name here. and rebuild all
-
^-^
@|@
- redCat
|
|
|
|
|
maybe your error is(I guess)
you declare one function in header file but you havent this file in your code
like this:
this is one example
class CAnswer : public CDialog
...
...
public:
int test();
....
};
then you call this function in your file
void CAnswer::OnBnClickedButton2()
{
test();
you need to delete this function(test) or you need to write test(function)
}
Answer error LNK2019: unresolved external symbol "public: int __thiscall CAnswer::test(void)" (?test@CAnswer@@QAEHXZ) referenced in function "public: void __thiscall CAnswer::OnBnClickedButton2(void)" (?OnBnClickedButton2@CAnswer@@QAEXXZ)
Answer fatal error LNK1120: 1 unresolved externals
or maybe this function is in your code like this
int test()
{
return 0;
}
again you get this error
-----------------------------------------------
or you need to import lib file to your project
|
|
|
|
|
Can we convert dll to source code? if yes, how?? Please give me info on the same. Thanks in advance.
|
|
|
|
|
For unmanaged dlls,I dont think it is that easy. I am not aware of..
But You can use Lutz Roeder's .Net reflector for managed dlls.
rgds...mil10.
|
|
|
|
|
acemahesh@yahoo.co.in wrote: Can we convert dll to source code?
no.
actually, yes - but that 'source' is going to be in machine language.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Atleast tell me How we can convert dll to machine code?
|
|
|
|
|
Hi
So fare i know you have to set both
// View Size
SetWindowExt(x1,y1);
// device size
SetViewportExt(x2,y2);
my printing works well using:
...
// Map Mode
pDC->SetMapMode(MM_ISOTROPIC);
// View size
pDC->SetWindowExt(xres-20,yres-50);
// Device Size
pDC->SetViewportExt(pInfo->m_rectDraw.right,(int)(pInfo->m_rectDraw.bottom));
Draw(pDC,&page);
...
hope this could help you
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
