|
Those functions are safe as you are allowed to present a character count to the API. The unsafe ones are the ones that do not allow this, such as gets(), strcpy(), sprintf().
And I would never reccomend using C++ on even my worst enemy! 
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
Toby Opferman wrote:
Those functions are safe as you are allowed to present a character count to the API. The unsafe ones are the ones that do not allow this, such as gets(), strcpy(), sprintf().
They are unsafe in the sense that you have to manage the amount of data that you use. The "safe" classes however do this for you.
Toby Opferman wrote:
And I would never reccomend using C++ on even my worst enemy!
Why is that? 
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
I would hope that a programmer is capabile of managing program resources!
Well, I'm not a fan of C++ for many reasons; but I don't want this to get into a religious battle
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
Toby Opferman wrote:
I would hope that a programmer is capabile of managing program resources!
I can only say that practice makes perfect. And with C++, some people need a lot of practice... 
Toby Opferman wrote:
Well, I'm not a fan of C++ for many reasons; but I don't want this to get into a religious battle
I read some of your tutorials on debugging and I think that if you are a fan of something, it must be assembler. And C++ makes assembler just a little bit harder to understand doesn't it?
You are spending some time here on the VC++ forum and if you are not a fan of C++, what are you a fan of I wonder?
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
I am a fan of assembler and of C programming. C++ doesn't make assembler harder to read, I debug C++ all the time. An extra parameter on the stack or being passed into a function via the ECX register doesn't make the code harder to read than C at that level (It's actually harder to read at the source level!) I have many other issues with it that would take a while to explain, mostly with maintainability and other semantecs.
Well, Visual C++ is just a compiler and it does support C programming as well. Also, I am a fan of programming, so language independent I can talk about Windows or programming in general.
I more consider myself a mid-level programmer (jack of all trades, master of none ) because I do have some interaction with the hardware or just above it in the kernel, but I also have some interaction with applications but again not a lot. I'm usually somewhere inbetween the application and the hardware. So I don't do a lot of GUI programming but I know some of it, and I don't do a lot of direct hardware access but I know some of it, but I understand a lot of what glues them together so to speak. I work all over the place, graphics drivers, network applications, services, user mode, kernel mode, etc. etc.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
The hardware explains why you do a lot of assembler and C. I had some courses on embedded systems in college and C++ is just not going to work on the small ones.
I want to know something about everything and master C++, server oriented architectures and application design. I consider myself now a little under average programmer, so I've got a long road ahead.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
In the DOS days assembly was more nessecary if you wanted to do anything (The DOS API equivlent of Window's WIN32 API was software interrupts!) but with Windows and abstractions it's rarely ever needed except for possibly specialized optimization code and even that is not so common.
Even a lot of embedded systems these days have higher level language compilers! There are some small CPUs which have limited RAM and possibly need optimized for size but even embedded systems you see a trend away from direct assembly.
Console game systems used to be in all assembly. Nintendo, Sega Saturn, etc. all the old consoles didn't have high level langauges and actually that was one of the downfalls of the Sega Saturn. I heard that the assembly language for it was very complicated. Newer console platforms though have high level language SDKs (They just cost like 25k).
I have always liked assembly language so I still use it in pet projects sometimes. I also only debug applications at the assembly level and never at the source level. I have some radical ideas about debugging such as you don't need to understand what the program is doing to figure out what the problem is. That being the case you can ignore most of the code and look for common patterns of problems. It's harder to look for those patterns if you see a higher layer complex overview of what's going on. It makes it harder to abstract since every line of code is really a complex operation that you must understand. A line of assembly is a very simplistic logic operation and doesn't need to be understood at a higher level of thinking.
A lot of bugs also need to be looked at on the lower level to be caught. So if you are already debugging at that level you get everything since we've abstracted out the need for understanding high level logic. An example would be a function call with invalid calling convention, messes up the stack pointer. Harder to see if you're looking at source code and also doesn't require you to understand anything the program is doing!
It works under the same principal that if you wanted to crack a third party application, you don't need to know what that application's logic is you just need to find that one instruction that determines the path divergence to either fail or continue execution of the application.
So, that's mostly why my debug tutorials are in assembly language
I wouldn't say you're below average. For example, you had the right idea on that keyboard input thread yesterday about keeping track of the key presses, other people seemed to miss that on the thread. There's a lot to learn and what you know today is usually only good for a few years before it's replaced by something new that you have to re-learn! Creating an ISR to keep track of key presses is definately not used by application programs anymore for example, yet I did that 10 years ago.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
Hello,
I just got back from my holliday, so this post may be a little late, but I didn't have internet access at my location  .
I agree that some problems are more easy to detect in a lower level context than others, but there is also a plethora of other problems that are more easy to detect with a high level view. An example of this is the infamous corner case bug, where you loop once too many or once to few. This is more easy to detect if you understand the context. (It's actually the comment that does the trick, but the high level view is less cluttered..)
I'll stop with my arguments, since I think that we both don't want to get involved in an endless debate about peoples passion for things.
Toby Opferman wrote:
It works under the same principal that if you wanted to crack a third party application, you don't need to know what that application's logic is you just need to find that one instruction that determines the path divergence to either fail or continue execution of the application.
It's mandatory to think that way, since you'll never have the source code available. If you have it, there would be no need to crack it..
Toby Opferman wrote:
I wouldn't say you're below average. For example, you had the right idea on that keyboard input thread yesterd
ay about keeping track of the key presses, other people seemed to miss that on the thread.
Thank you, I feel flattered
Toby Opferman wrote:
There's a lot to learn and what you know today is usually only good for a few years before it's replaced by something new that you have to re-learn! Creating an ISR to keep track of key presses is definately not used by application programs anymore for example, yet I did that 10 years ago.
The coding techniques are generally old at the moment that you are using them. They are new at the moment you learn them. The key is to learn an abstract technique, algorithm, etc. that you can implement in different languages, so that you don't have to relearn everything. The only thing to relearn is the technique to implement the idea.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Bob Stanneveld wrote:
An example of this is the infamous corner case bug, where you loop once too many or once to few. This is more easy to detect if you understand the context. (It's actually the comment that does the trick, but the high level view is less cluttered..)
I've never had to go to source level debugging and I fix 10x as many bugs as anyone else. I was so good they only had be debugging everyone's code! So, I had to get momentum to move onto a different team (I work in research now) in order to avoid having to fix everyone's code for life. After years of debugging user mode traps, blue screens, etc. I've actually found patterns in debugging and use this to find the answer to the next bugs. I should write a book on "Debugging Patterns", how to recognize what a bug is by it's symptoms and how to fix it. I actually came up with an idea to completely automate debugging and cut down the work by a significant effort (Weeks worth of effort). Most of what you do is routine anyway.
I believe that high level code is more cluttered. Each line is a complex operation and if you attempt to comprehend it you will slow down.
Bob Stanneveld wrote:
I'll stop with my arguments, since I think that we both don't want to get involved in an endless debate about peoples passion for things.
Yes that's true, it becomes like OS wars or editor wars, it never ends!
Bob Stanneveld wrote:
It's mandatory to think that way, since you'll never have the source code available. If you have it, there would be no need to crack it..
I've found that this mentality actually works for everything and finds things faster. The source is always available for referencing if need be.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
STL is an all or nothing proposition though - if you start using it, it triggers some changes in the way that the code is compiled and forces everything to STL. If you are dealing with legacy code this can be a major major - and unnecessary - pain in the neck.
|
|
|
|
|
Hello,
May I suggest that you format your post, so that your for /* or other loop */ statement becomes visible.
May I ask why you use so much ugly C functions and buffers and copy all those things manually? You would write much cleaner code if you utilize all that the STL's streams or MFC's CString and CArray classes have to offer..
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
The reason I use such ugly code, is because that's the only code I know. I am a begginer in programming. At the moment I am reading some materials on STL and MFC, but find it quite difficult to understand, as I have a lot of gaps in my programming knowledge. To that I have no one to ask for help apart from the forum. So THANK YOU all for helping me out! 
Maybe you could help me out with this error I get:
cannot convert parameter 1 from 'unsigned short' to 'char *'
Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast.
The solutions you helped me out with, was not exaclty what I was looking for. Basicaly pszData is only 1 character at a time. So I want to store that 1 character in an array, then add the next character that comes from pszData and add it to the array. When I have 10 characters, That's when I want to display on screen. pszData recieves a character at different times, could be a split second or a whole day.
Thanks in Advance!
|
|
|
|
|
tomek18 wrote:
The reason I use such ugly code, is because that's the only code I know. I am a begginer in programming. At the moment I am reading some materials on STL and MFC, but find it quite difficult to understand, as I have a lot of gaps in my programming knowledge.
Only time and practice will learn. We were all beginners once, and we are glad to help a fellow programmer!
tomek18 wrote:
cannot convert parameter 1 from 'unsigned short' to 'char *'
Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast.
Can you post the code? It's much easier for us to understand your problem if we see some code. If we see it, we can tackle the problem much faster.
tomek18 wrote:
The solutions you helped me out with, was not exaclty what I was looking for. Basicaly pszData is only 1 character at a time. So I want to store that 1 character in an array, then add the next character that comes from pszData and add it to the array. When I have 10 characters, That's when I want to display on screen. pszData recieves a character at different times, could be a split second or a whole day.
If you only need to wait for 10 characters, why are you using so large buffers? You don't even need to do all the copying! Try the following code:
std::stringstream m_sstrDataBuffer;
void CChildView::SortData(LPCTSTR pszData)
{
m_sstrDataBuffer << pszData;
if( m_sstrDataBuffer.str().length() >= 10 )
{
DisplayData(m_sstrDataBuffer.str().c_str());
m_sstrDataBuffer.str("");
}
}
Hope this helps!
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Bob Stanneveld wrote:
Can you post the code? It's much easier for us to understand your problem if we see some code. If we see it, we can tackle the problem much faster.
I would if it just wasn't that long. I got the source code from this web site. if your interested http://www.codeproject.com/system/serial.asp
Basicaly the program just reads a character through the serial COM port, then passes that character to pszData. What I want to do, is to store all the single characters that come in, and after 80 have been recieved I want to sort out the data, and only send about 10 characters to the Display.
At the moment I am having problems converting Data types. Pointers, Strins, LPCTST, etc... I don't understand them much. And everytime I try a method I get an error saying something like: cant convert pointer to string vice versa.
Please Help me
|
|
|
|
|
As long as a pointer doesn't point to a class, you can convert it from anything to anything. Unless you don't know what you are doing, you will get away with it.
The serial class that you are using is a good one. I use it too in one of my programs. So the problem is definitly not there.
Your problem however, is that you don't pass the number of bytes in the buffer (pszData) to your SortData function. You have that number, since the serial class demands a buffer size for the read actions. I suggest that you use those values to determine how much data is recieved.
tomek18 wrote:
At the moment I am having problems converting Data types. Pointers, Strins, LPCTST, etc... I don't understand them much. And everytime I try a method I get an error saying something like: cant convert pointer to string vice versa.
Use static_cast<PointerType>(OtherPointerType) for this purpose.
I think that you are a little bit over your head with this project if you have problems like this. I suggest that you do some more reading about data types, pointer arithmic and such. The basics should be enough to get the job done.
Good luck with it.
P.S.
If you have some problems with something, by all means, ask and post the source code too! Otherwise we will not be able to help you much...
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
tomek18 wrote:
Basicaly pszData is only 1 character at a time.
While the compiler couldn't care less, and it certainly is not required, you might want to consider a different variable naming convention so that you and others who read your code can make better sense of it. See here.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
i debug my program, and the exception (unhandled exception in gis.exe(MFCO42D.DLL):0xc0000005 access violation.) arised when the instruction(mapinfo.CreateDispatch("MapInfo.Application"))run. how can i deal with it?
|
|
|
|
|
It is the debug version of the MFCOLE Shared Library.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
how can i deal with the problem?
|
|
|
|
|
Well, either mapinfo is not a valid COleDispatchDriver object, or "MapInfo.Application" is not a valid automation object identifier. I'd have to see more of your code to know for sure.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
liuyue wrote:
mapinfo.CreateDispatch("MapInfo.Application"))
Please Check that mapinfo variable hold valid reference to memory
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
|
|
|
|
hello,
i need to know who to determine whether a user is logged on or not. i have already tried GetUserName but this didn't work, because i have a service running as 'system', so GetUserName only returns 'system'. Now, how can i get this information ?
OS: Windows 2000
Thanks in advance.
|
|
|
|
|
Check out the UserName property of Win32_ComputerSystem.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
If this is Windows 2000 and you think they will always launch the shell you could simpy enumerate processes looking for explorer.exe or whatever they replaced the shell with.
Alternatively you could write a Winlogon Notification DLL which gets notified of events such as Logon and Logoff.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
thanks for the hints, but i have found another workaround. because i have already a process which gets launched at startup - i simply put a pipe in it, which delivers the needed informationen whether a user has logged on.
thanks anyway.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
