|
I have read several sources on when to use the extern keyword and when not to, but I still have some confusion.
Could someone explain the proper use of extern when it comes to variables and function:
extern void MyFunction(void);<br />
extern int MyVariable;
Thanks.
|
|
|
|
|
masnu wrote: Could someone explain the proper use of extern when it comes to variables and function:
extern void MyFunction(void);
extern int MyVariable;
In both cases, it specifies external linkage (i.e., is visible from files other than the one in which it's defined).
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
you use extern when you want to tell the compiler the type of a variable or function which is defined in another file.
if you have a variable called blah, of type int, at global scope (not static, or local to a function) in foo.c and you want to use it in bar.c, you would put "extern int blah;" somewhere in bar.c, or in a file that bar.c includes. that way, when the compiler is working on bar.c, it knows the type of the variable 'blah'.
the linker will come around later and make sure all references to 'blah' are looking at the same thing.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Hello. I'm getting some linker errors involving jpeg/png/tiff libraries after converting my project from VS6 to 2005.
------ Build started: Project: MyProject, Configuration: Debug Win32 ------
Linking...
Creating library .\Debug/MyProject.lib and object .\Debug/MyProject.exp
libpng.lib(pngrutil.obj) : error LNK2001: unresolved external symbol __iob
geotiff.lib(cpl_serv.obj) : error LNK2001: unresolved external symbol __iob
libjpeg.lib(jerror.obj) : error LNK2001: unresolved external symbol __iob
libtiff.lib(tif_win32.obj) : error LNK2001: unresolved external symbol __iob
libpng.lib(pngwutil.obj) : error LNK2019: unresolved external symbol __iob referenced in function _png_write_sPLT
libpng.lib(pngerror.obj) : error LNK2001: unresolved external symbol __iob
.\Debug/MyProject.exe : fatal error LNK1120: 1 unresolved externals
-------------------
Any thoughts on why I would be getting these? And how to fix them?
Thanks for any help.
|
|
|
|
|
CodeGoose wrote: Any thoughts on why I would be getting these?
By not linking with the CRT DLL perhaps. 
Do you have the latest SDK installed correctly?
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
|
I do have the latest sdk installed.
I am, however, using the same dll's that I was using under VS6. So maybe I will try recompiling those under 2005 and see how that goes.
Might be back with more questions if that doesn't go well 
|
|
|
|
|
Hi All,
As you might know, there are tons of articles accross CodeGuru, CodeProjects, and many other programming info sites about owner-draw components. Some of them describes how to do owner-draw in detail. Many of them provides a re-usable class so that people can download and use.
I like to publish a book that describes how people can do the owner-draw components themselves, explain the solution to the general owner-draw operations.
My questions are:
1. Is there any book with related subjects that has already been published?
2. If there is no such book, is it too late to write such a book that uses Win32 API, MFC, WTL? Or are Win32 API, MFC, WTL considered out of date technologies that there is no market for books that describe the use of these technology any more?
I appreciate if any one can give me some good answers on above questions.
Thanks
|
|
|
|
|
|
Topic in microsoft.public.windowsxp.security_admin
WMI settings for remote access on XP
From: Jerry Bryant [MS] - view profile
Date: Fri, Jan 25 2002 4:09 pm
1. the user needs to either be an admin on the XP machine or have remote
enabled privilege set on the XP machine
2. Win2k needs the SP because XP requires at least Packetlevel
authentication and the SP fixes a bug in Win2k to correctly allow
Packetlevel connections
3. if the XP machine is in a workgroup, you won't be able to remote in
anyways as all incoming connections to the XP machine will be reduced to the
guest account (this is by-design of the OS), if in a domain, it should work
given the previous 2 statements are fulfilled.
How to enable remote privileges on the XP machine:
1. Right Click "My Computer", choose "Manage"
2. Open "Services And Applications", right click over "WMI Control" and
choose "properties"
3. Click on the "Security" Tab, highlight the namespace you want to give
security to (most likely root\cimv2) and click the Security button
4. add the user, and check "Remote Enable"
also check out this: http://support.microsoft.com/kb/q282949/
if you are using XP home in Step #3 behavior cannot be
changed. If you are using XP Pro in a workgroup you can change the behavior
via the local group policy:
Computer\Windows Settings\Security Settings\Local Polices\Security Options:
Network Access: Sharing and security model for local accounts:
In unjoined WinXP Pro the ForceGuest behavior is on by default. This
will cause all inbound connections to be anonymous (null)
connections. Try disabling the ForceGuest behavior by setting the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ForceGuest
value to 0 and reboot.
The "firewall" option on the LAN connection must be disabled.
Regards
Microsoft MVP in Visual C++
http://blog.joycode.com/jiangsheng
|
|
|
|
|
I'm using the MFC collection data types in a VC++ 2003 application and am getting the "conversion from 'INT_PTR' to 'int', possible loss of data" when calling collection functions like GetSize() and such.
I know these "Warnings" are 64-bit Portability warnings that occur when using the default /Wp64 command line option. I am attempting to accomodate the warnings and adapt my code so that it will compile fine in a 64-bit environment (within reason)
Original code: (Used to work fine in Visual C++ 6.0)
///////////////////////////////////////
// Member variable
CArray<int,int&> m_someArray;
// typical usage
int nObjectCount=m_someArray.GetSize();
///////////////////////////////////////
My question is...
Which type (or typedef) should I use for my offset (int, INT, INT_PTR)?
int nObjectCount=(int)someArray.GetSize(); // OR
INT nObjectCount=(INT)someArray.GetSize(); // OR
INT_PTR nObjectCount=(INT_PTR)someArray.GetSize();
Thanks in advance for any guidance.
|
|
|
|
|
|
I'm not sure if that will properly prepare me for 64-bit compiling later as the standard types are going to remain 32-bit in size. I was under the impression that pointers were the only values that would be 64-bit without explicitly asking for it like _int64, DWORD64, INT64 etc...
size_t is defined as an unsigned int which would still be 32-bit under the 64-Bit Windows abstract data model.
Boy this is confusing...
|
|
|
|
|
size_t is 32 bits long under 32 bits system (unsigned long), but 64 bits long under 64 bits system (__int64) !!!!
so it is exactly what you need, isn't it ?
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
Yes. I apologize as I did not dig deeper to find the __int64.
Thanks again for helping remove the confusion.
|
|
|
|
|
I'm confused too.
<blockquote class="FQ"><div class="FQA">bob16972 wrote:</div>int nObjectCount=m_someArray.GetSize();</blockquote>
Are you compiling for 64 bit or 32 bit? Even if you are compiling for 32 bit, GetSize() returns an int and you are assigning that to an int, so there is no potential for truncation. If you are compiling for 64 bit, I can only assume that the the GetSize() method no longer returns an int, but returns some other type. Are there #ifdef's in the CArray header file that show what it returns differently for a 64 bit compile? If there are then you have to put the same kind of #ifdef's for your declarations prior to the assignment call.
But like I said at the start, I'm confused.
Chris Meech
I am Canadian. [heard in a local bar]
The America I believe in has always understood that natural harmony is only one meal away from monkey burgers. [Stan Shannon]
GOOD DAY FOR: Bean counters, as the Australian Taxation Office said that prostitutes and strippers could claim tax deductions for adult toys and sexy lingerie. [Associated Press]
|
|
|
|
|
GetSize used to return an int.
On VC++ 2003 it returns an INT_PTR
I'm doing everything under 32-bit but the warnings came up so I'm trying to use the INT_PTR but it's like a chain reaction since anything that uses the value needs to be prepared for it. In this case, it's an accessor function for a private member so my return value needs to be INT_PTR I guess and on down the line. It just had enough ripple effect that I thought I needed to question it.
Sorry about the confusion.
|
|
|
|
|
bob16972 wrote: On VC++ 2003 it returns an INT_PTR
That's a pretty significant change.  I'm guessing that this means you are given the address of where the size is stored, and thus when the size changes, in effect you will be notified. Regardless of the reason though, I think you need to change your code to
INT_PTR pObjectCount = m_someArray.GetSize(); and that should compile with the option you previously specified and not produce a warning.
Chris Meech
I am Canadian. [heard in a local bar]
The America I believe in has always understood that natural harmony is only one meal away from monkey burgers. [Stan Shannon]
GOOD DAY FOR: Bean counters, as the Australian Taxation Office said that prostitutes and strippers could claim tax deductions for adult toys and sexy lingerie. [Associated Press]
|
|
|
|
|
It's more of an offset in context so it would resemble x86 real mode offset pointers I guess.
"size" seems to be the agreeable term so far about it thus far. Tox pointed me to the size_t typedef which appears as if it would work. However, I'm inclined to use INT_PTR at this point as it should make the code readily understandable once INT_PTR becomes a household typedef methinks.
Thanks for the comments and help!
|
|
|
|
|
Just FYI, last time I checked (its been a little while, so 2005 may have changed it), INT_PTR and INT were the same thing (for a 32-bit build, they were longs, for 64-bit, they were long longs).
When using the MFC collection classes, I generally use whatever they return for as long as possible and only cast it if absolutely necessary. That usually saves a lot of headaches.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: use whatever they return for as long as possible and only cast it if absolutely necessary
I would agree. I just wrote the program in VC++ 6.0 which was "int" at that point so I'm going through the code adjusting accordingly.
Thanks for the advise!
|
|
|
|
|
I have built an IE (in a dialog-based application) using the microsoft webbrowser activex control.
I know how to get access to the IHTMLDocument and IHTMLElements.
Does any one know how to retrieve the distance the user has scrolled from the top of the page???
Thank you
llp00na
|
|
|
|
|
I believe you can get the get_scrollTop and get_scrollLeft functions of the
IHTMLTextContainer interface, which the IHTMLBodyElement object should implement.
- S
50 cups of coffee and you know it's on!
|
|
|
|
|
I want to include a header file (ServeurDicoView.h (hérited from CFormView.h) in a another class ( MySocket )
but when i put #include "CFormView.h"
i have too many errors like
error C2146: syntax error : missing ';' before identifier 'm_sListenSocket' as it's explained here :
Mot* tabSupp[100];<br />
MonSocket m_sListenSocket; <br />
MonSocket m_sConnectSocket;
in the "Monsocket.h"
#include "ServeurDicoView.h"
thanx for readin' my message .... and certainely for answering me 
i can't compile the "Monsocket.h"...
-- modified at 11:03 Wednesday 24th May, 2006
|
|
|
|
|
Mahhouraaaaaa wrote: #include "ServeurDicoView.h"
The view class is also dependent on the document class. If your going to couple your class to the view like this, you will also need to inclide the document class. (order of inclusion is important but I forget which one comes first). Also, it may take some jacking around with where your declarations are if they are shared by multiple classes. Sometimes forward declarations work, sometimes putting it in the stdafx.h etc...
Lastly, I hate it when others say "you shouldn't do it this way" but for what it's worth, just a friendly FYI, and I still resort to this from time to time so I'm guilty of it as well, but you should try to avoid close coupling your classes to the view/doc/app classes to promote simpler reuse. Sorry. It seems to be our civic duty to point that out around here till it's pouring out of our ears. For what it's worth...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
