|
#include <stdio.h >
char *return_Char_Pointer(char *ptrChar)
{
ptrChar = "hello hi! I am returning a return char pointer (char *p)\n\n";
return ptrChar;
}
int main(int argc, char* argv[])
{
char *ptrChar = new char[255];
char *ptrChar1;
ptrChar1 =return_Char_Pointer(ptrChar);
printf("%s",ptrChar1);
delete []ptrChar;
return 0;
}
|
|
|
|
|
Are you posting bad code to set the enemy on the wrong track?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
You'd better use memcpy to copy the literal string to ptrChar. Doing it like the makes you call delete on statically allocated memory.
The assignment just returns the address of the literal string
Cheers, AT
Cogito ergo sum
|
|
|
|
|
I am surprised this will compile given the 'delete' is unreachable. 
Anyway, just remove the delete and return strout to the caller. It is then the callers responsibility to free the memory.
==============================
Nothing to say.
|
|
|
|
|
Good one; make sure that you set the comiler warnings to max (4) and warnings as errors. That will at least make sure that something like this won't even compile.
Cheers AT
Cogito ergo sum
|
|
|
|
|
The problem with that is:
1. The caller may not know what method was used to allocate the memory (e. g. malloc or new), or if it was allocated at all, or instead just points to a static buffer! (Of course you could put that kind of information into the function documentation)
2. The OP put this function into a library interface. If bound statically, that would not pose a problem, but if bound dynamically, as a DLL, this DLL may use a separate heap - that means the caller may not even be able to release that memory. At least that's my understanding of DLLs.
|
|
|
|
|
Stefan_Lang wrote: The caller may not know what method was used to allocate the memory (e. g.
malloc or new), or if it was allocated at all, or instead just points to a
static buffer!
Thats what documentation is for. This is actually quite common procedure, many APIs do this.
Stefan_Lang wrote: The OP put this function into a library interface
Then the dll can expose a func that the caller can call to do the delete.
==============================
Nothing to say.
|
|
|
|
|
hi guys where am i going wrong?? bear in mind this is just part of the prog.
#include <stdlib.h>
# include <string.h>
#include <stdio.h>
#include <iostream>
use namespace std ;
static FILE *stream;
static char buffer[80];
abnormal_end()
{
fclose(stream);
printf("Abnormal extraction termination.\n");
return (0);
}
int main()
{
char path[80];
FILE *stream;
char filestr[256];
|
|
|
|
|
Where are you going wrong? ...Do you want us to guess at what your problem is?
|
|
|
|
|
my apologies ..i am a complete novice to c++. i have decided to write the extraction program in parts . the part i posted is an attempt to write the file reader....hope it makes sense
#include <stdlib.h>
# include <string.h>
#include <stdio.h>
#include <iostream>
use namespace std ;
static FILE *stream;
static char buffer[80];
abnormal_end()
{
fclose(stream);
printf("Abnormal extraction termination.\n");
return (0);
}
int main()
{
char path[80];
FILE *stream;
char filestr[256];
|
|
|
|
|
You still didn't state your problem...
[Note: I didn't downvote, but if you keep posting code with no clear problem statement, expect more downvotes.]
|
|
|
|
|
[Note: I did 1 vote]
You have showed precisely 3/5ths & 5/8ths of nothing new in this post. There IS NOT enough information for any kind of useful (in the sense of this particular problem) response.
Problems with your posts include (though are not limited to):
1) Failure to use code tags (this time)
2) Repetition of the same useless snippet of code (this time)
3) A failure to actually state what the problem is (both times)
4) The changing to a different username for the repost (this time)
5) Nothing you've showed has anything to do with the DXF format, even if this is the type of file you're trying to process, there is nothing related to DXFs in any way. (both times)
You do realize that we've got no idea of what you're trying to do, save for the mention of DXFs in the subject line? You've not showed any code that can fail, with the possible exception of the fclose - though you don't check the return value, nor will an attempt to close an invalid file result in a crash.
(Assuming your primary language is indeed english) This is an example of sloppiness and lazy questioning at close to its peak.
Wait a minute - even if it's not, you still (presumably) have access to the same Google Translate pages that we do. Even if the grammar may become a little battered in the process of automatic translation, there is still no actual information in your posts.
I'd be happy to change that 1 back into something a little more pleasant, should you have the urge to edit the last post such that it resembles a serious question.
But if that doesn't happen, it's remains merely 'noise'.
|
|
|
|
|
I can't believe you took the time to write all that...
[I accidentally bookmarked your post last night, fat fingers+small mobile screen= pushing wrong links].
|
|
|
|
|
Correct me if I'm wrong, but I am guessing that what you are saying here is that you have have no idea how to write the rest of the program and you think CP members are going to do it for you.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
It seems your code is a small random snip which may or may not be relevant. You did not describe any compiler or runtime issues you have. No one can help you if you don't give them something to work with.
Regards, AT
Cogito ergo sum
|
|
|
|
|
|
This is my first time working with c++ and SQL Server.
Well I figured out how to connect to a SQL Server using the native 10.0 SQLCLI10. I can connect to the server, run my SQL Command and get back a rowset with columns now.
But for the life of me, some things are fuzzy. I now believe that all data returned are BYTES stored in a buffer pointer. So I run a small command to get back 1 row and 1 column, but I can't figure out how what to do with the BYTE response. I want to just get a WCHAR value, check it and be on my way.
SELECT CASE WHEN db_id('NASE') IS NOT NULL THEN 'TRUE' ELSE 'FALSE' END
buffer = new BYTE[ prgInfo[0].ulColumnSize + 3 ];
ULONG valbufferlen = ( ULONG ) prgInfo[0].ulColumnSize;
memset( buffer, 0, prgInfo[0].ulColumnSize + 3 );
hr = pIRowset->QueryInterface( IID_IAccessor, ( void ** ) &pIAccessor );
hr = pIAccessor->CreateAccessor( DBACCESSOR_ROWDATA, 1, DBBindings, prgInfo[0].ulColumnSize, &hAccessor, DBBindStatus );
while( DB_S_ENDOFROWSET != pIRowset->GetNextRows( NULL, 0, 1, &cRowsObtained, &prghRows ) ) {
hr = pIRowset->GetData( rghRows, hAccessor, buffer );
for ( ULONG i = 0, j = 0 ; i < valbufferlen ; i++, j+=2 ) {
}
pIRowset->ReleaseRows(1, prghRows, NULL, NULL, NULL);
}
|
|
|
|
|
I just copied the bytes to chars and did a compare, the buffer looked like is was already null terminated. Well it's a start at least, until I get to more complex return results.
I just got a taste of what SQL Server really is, didn't know asp.net masked and wrapped the extreme complexities of the product to this degree, to make it way easier to talk to. I think I just a short lesson in pointers as well.
if (prgInfo[0].wType == DBTYPE_STR) {
char *szDatabaseStatus = new char[valbufferlen];
for ( ULONG i = 0; i < valbufferlen ; i++ ) {
szDatabaseStatus[i] = buffer[i];
}
int iCompare = stricmp(szDatabaseStatus, "TRUE");
if (iCompare == 0)
bResult = TRUE;
delete [] szDatabaseStatus;
}
|
|
|
|
|
Why are you torturing yourself like this? (Using OleDB).
Why not use ADO to access the SQL server DB?
|
|
|
|
|
I had a really bad experience with Microsoft and ADO in 2001.
I starting to understand it now, and figured out I can assign a value like LPWSTR to the return value.
For right now, I only need to do 5 things with SQL, Create Database, user, assign permissions, and create and populate the tables.
When this progrmam is finished, I'm going to look into MFC.
|
|
|
|
|
I understand. I started developing SQL DB apps back in 2002, ended up using ADO and C++. I equally hated and loved it.
FYI MFC is not needed to use ADO in C++.
Is it an option for you to use .NET? All this SQL DB stuff if SOOOOOOOOOOOOOOOO much easier in C# and .NET.
|
|
|
|
|
I wrote a eCommerce program in asp.net, that uses server control dll's. I've been trying to sell the program, but I need more users. I have a 99% failure rate on installation. So I wrote a Setup Wizard, one click app in asp.net, but when I added support for Vista and 7, it bombs on XP. Plus it's not 100% reliable. It's also a pain in the ** to deploy consistently.
So I decided to write a new setup wizard, this time in C++. I fired up my VS2010, and choose win32 project, not really knowing what it was. Now I almost have all the functionality I had before, almost done, and so far so good. It's works on XP', Vista and 7 in X86.
A long time ago, I wrote a eCommerce program in classic asp, and used ado for the database. Once a month the server would lock up, and not be able to communicate to the database server. I spent a week hunting down the issue, and it was the ado module, crashing from a 3Com hardware driver. There was no support with the issue, and felt helpless. My store was down for a week, and at any given moment in time, it could crash.
|
|
|
|
|
It sounds like a hardware problem.
Swapping your network card out (diff brand), may have solved all of your headaches.
I understand that you're gun shy now, but it has been a decade since you had that trouble with the 3Com Drivers.
|
|
|
|
|
I took me a month to figure out that the 3Com 3C 909 I think, a dual port 10/100 ethernet card was the problem, so I switched to Intel and Broadcom Chipset cards since them. Back then I had no idea how a hardware driver could only interfere with just talking to the MySQL Server, which was on board, and everything else still worked fine including the web server. So I concluded that the OBDC was evil, and stayed away from it since.
Long story short, I ended up going open source, LAMP, and regretted that as well, because I spent more time fixing issues with the programs, then actually writing programs. Found it was cheaper to just buy programs that work, and let someone else fix them.
Back to ODBC, I hear it's officially dead now. I think to the best of my knowledge!, like Ethernet, OLEDB has become the standard now, and ODBC was like token-ring, good idea, but lost out in the end. I may be wrong, just my opinion.
Oh, I'm still using that 3Com card in a CentOS Linux Server right now. LOL!
I know I was talking about ADO in the last post, I still stay away from both of them.
|
|
|
|
|
I ran into a number of cards that had bad drivers back in the day.
The issue was in persistent connections. There were protocol stack bugs.
You wouldn't see it on web servers, especially then, because connections aren't persistent.
I still use ODBC. It's not dead. The OleDB layer rests on top of it.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
