return string

[Eric Kaplan]

I have a function like this
=============
bool Table::Get(char* FieldName, char* FieldValue)

and I call the function like the follow
=============
while(!tbl.ISEOF())
{
char id2[300];
if(tbl.Get("program",id2))
cout<<"program:"<<id2<<endl;
else
{
tbl.GetErrorErrStr(ErrStr);
cout<<"\n"<<ErrStr<<"\n";
break;
}

}
above I passed in a char pointer (char*) - FieldValue and use it just
like a return value.

but it seem not efficient as each time i initialize a char array of
[300] characters.

but some string (FieldValue) is only like [5] char.

how to I do better for returning string? any example code?

=================

should I just return the string in regular return type like -
std::string Table::Get(char* FieldName)

[Ian Collins]

Eric Kaplan wrote:

I have a function like this
=============
bool Table::Get(char* FieldName, char* FieldValue)

Why not

std::string Table::Get( const std::string FieldName& );

You can test for an empty string as you failure condition.

--
Ian Collins.

[Andrey Tarasevich]

Eric Kaplan wrote:

I have a function like this
=============
bool Table::Get(char* FieldName, char* FieldValue)

and I call the function like the follow
=============
while(!tbl.ISEOF())
{
char id2[300];
if(tbl.Get("program",id2))
cout<<"program:"<<id2<<endl;
else
{
tbl.GetErrorErrStr(ErrStr);
cout<<"\n"<<ErrStr<<"\n";
break;
}

}
above I passed in a char pointer (char*) - FieldValue and use it just
like a return value.

but it seem not efficient as each time i initialize a char array of
[300] characters.

Where exactly do you "initialize" a char array of 300 characters? What I
see in your code is an _uninitialized_ array of 300 characters.

--
Best regards,
Andrey Tarasevich

[Jim Langston]

Eric Kaplan wrote:

I have a function like this
=============
bool Table::Get(char* FieldName, char* FieldValue)

and I call the function like the follow
=============
while(!tbl.ISEOF())
{
char id2[300];
if(tbl.Get("program",id2))
cout<<"program:"<<id2<<endl;
else
{
tbl.GetErrorErrStr(ErrStr);
cout<<"\n"<<ErrStr<<"\n";
break;
}

}
above I passed in a char pointer (char*) - FieldValue and use it just
like a return value.

but it seem not efficient as each time i initialize a char array of
[300] characters.

but some string (FieldValue) is only like [5] char.

how to I do better for returning string? any example code?

Instead of using a c-style string, you would be better to use a std::string
which is dynamically sized. You can copy from/to c-style strings relatively
easy.

bool Table::Get( char* FieldName, std::string& FieldValue )
{
// Determine the data that FieldValue is to get. You'll probably get a
pointer
// to a c-style string somewhere returned from some database.
// for an example:
char data[] = "12345678";

FieldValue = data;
}

The key to it is assigning std::string = char* will dynamically size the
string to hold the amount of characters needed.

Now to call it:

while(!tbl.ISEOF())
{
std::string id2;
if (tbl.Get("program", id2))
cout<<"program:"<<id2<<endl;
else
{
tbl.GetErrorErrStr(ErrStr);
cout<<"\n"<<ErrStr<<"\n";
break;
}
}

=================

should I just return the string in regular return type like -
std::string Table::Get(char* FieldName)

You could, yes. You seem to know about std::string yet didn't realize you
could pass a reference to a std::string just as you can a char pointer.

--
Jim Langston
ta*******@rocketmail.com

[Ian Collins]

Jim Langston wrote:

Eric Kaplan wrote:

>I have a function like this
=============
bool Table::Get(char* FieldName, char* FieldValue)

and I call the function like the follow
=============
while(!tbl.ISEOF())
{
char id2[300];
if(tbl.Get("program",id2))
cout<<"program:"<<id2<<endl;
else
{
tbl.GetErrorErrStr(ErrStr);
cout<<"\n"<<ErrStr<<"\n";
break;
}

}
above I passed in a char pointer (char*) - FieldValue and use it just
like a return value.

but it seem not efficient as each time i initialize a char array of
[300] characters.

but some string (FieldValue) is only like [5] char.

how to I do better for returning string? any example code?

Instead of using a c-style string, you would be better to use a std::string
which is dynamically sized. You can copy from/to c-style strings relatively
easy.

bool Table::Get( char* FieldName, std::string& FieldValue )

Make that const char* FieldName or const std::string& FieldName.

--
Ian Collins.

[James Kanze]

On Apr 17, 2:47 am, Ian Collins <[e-mail]:

Eric Kaplan wrote:

I have a function like this
=============
bool Table::Get(char* FieldName, char* FieldValue)

Why not

std::string Table::Get( const std::string FieldName& );

You can test for an empty string as you failure condition.

Except that an empty string could be a legitimate field value.
I'd use a fallible in this case:

Fallible< std::string Table::get(
std::string const& fieldName ) ;

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Eric Kaplan]

On Thu, 17 Apr 2008 12:47:45 +1200, Ian Collins <ia******@hotmail.com>
wrote:

>Eric Kaplan wrote:

> I have a function like this
=============
bool Table::Get(char* FieldName, char* FieldValue)

Why not

std::string Table::Get( const std::string FieldName& );

You can test for an empty string as you failure condition.

Is this

std::string Table::Get( const std::string FieldName& );

return by value? should I return a pointer instead? which speed up the
copy of value. may be the string is 500 character long.

[Ian Collins]

Eric Kaplan wrote:

On Thu, 17 Apr 2008 12:47:45 +1200, Ian Collins <ia******@hotmail.com>
wrote:

>Eric Kaplan wrote:

>> I have a function like this
=============
bool Table::Get(char* FieldName, char* FieldValue)

Why not

std::string Table::Get( const std::string FieldName& );

You can test for an empty string as you failure condition.

Is this

std::string Table::Get( const std::string FieldName& );

return by value? should I return a pointer instead? which speed up the
copy of value. may be the string is 500 character long.

Why don't you ask Carmen?

--
Ian Collins.

[Thomas J. Gritzan]

Ian Collins schrieb:

Eric Kaplan wrote:

> I have a function like this
=============
bool Table::Get(char* FieldName, char* FieldValue)

Why not

std::string Table::Get( const std::string FieldName& );

You can test for an empty string as you failure condition.

Should be:

std::string Table::Get( const std::string& FieldName );
^

--
Thomas
http://www.netmeister.org/news/learn2quote.html
To iterate is human, to recurse divine.
-L. Peter Deutsch

[James Kanze]

On Apr 17, 9:05 pm, Eric Kaplan <[e-mail]:

On Thu, 17 Apr 2008 12:47:45 +1200, Ian Collins <[e-mail]>
wrote:

Eric Kaplan wrote:

I have a function like this
=============
bool Table::Get(char* FieldName, char* FieldValue)

Why not

std::string Table::Get( const std::string FieldName& );

You can test for an empty string as you failure condition.

Is this

std::string Table::Get( const std::string FieldName& );

return by value?

Yes.

should I return a pointer instead?

A pointer to what?

If the string is guaranteed to be part of your internal
structure, and can never be a calculated value, then returning a
pointer can make sense if you need the possibility of indicating
some sort of non-differentiated error as well---it's a classical
solution in cases where the string is the result of a table
lookup, and there is no default value.

If the string is part of your internal structure, and you want
the client code to be able to modify it (i.e. the value that it
has in your internal structure), then you must return either a
pointer or a reference.

If the string is guaranteed to be part of your internal
structure, but you don't need the error possibility, it's
preferrable to return a reference, rather than a pointer
(although a value might still be preferred to a reference).

which speed up the copy of value. may be the string is 500
character long.

And maybe it's not. And maybe copying the value is fast enough.
Until you actually have a performance problem, and the profiler
indicates that it is due to copying the string, it's stupid to
worry about it.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Pete Becker]

On 2008-04-18 04:24:05 -0400, James Kanze <ja*********@gmail.comsaid:

>
And maybe it's not. And maybe copying the value is fast enough.
Until you actually have a performance problem, and the profiler
indicates that it is due to copying the string, it's stupid to
worry about it.

That depends on context. Certainly, when you're writing an application,
spending time optimizing things that aren't bottlenecks is a waste of
time. But when you're writing a general purpose library that's going to
be distributed to others, if you don't spend time optimizing things,
you'll spend time responding to complaints from users that your code is
too slow. If that's just an internal feedback loop, fine; but if you're
not part of your users' development process, you'd better put the time
in up front.

Of course, that doesn't mean micro-optimizing every return statement.
But understanding relative performance is an important part of proper
optimization; if the time taken by a return statement is a significant
fraction of the overall time taken by a function, it could easily
become a bottleneck in a customer's code.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[James Kanze]

On 18 avr, 13:58, Pete Becker <[e-mail]:

On 2008-04-18 04:24:05 -0400, James Kanze <[e-mail]:

And maybe it's not. And maybe copying the value is fast
enough. Until you actually have a performance problem, and
the profiler indicates that it is due to copying the string,
it's stupid to worry about it.

That depends on context. Certainly, when you're writing an application,
spending time optimizing things that aren't bottlenecks is a waste of
time. But when you're writing a general purpose library that's going to
be distributed to others, if you don't spend time optimizing things,
you'll spend time responding to complaints from users that your code is
too slow. If that's just an internal feedback loop, fine; but if you're
not part of your users' development process, you'd better put the time
in up front.

I'll admit that library implementers have it tough, here. They
do have to do some guessing, and (for example) were I
implementing the standard library, I'd certainly make sure that
std::vector<>::operator[]() was as fast as possible. Without
waiting for feedback from actual users.

Still, given the apparent level of the original poster, I don't
think he's implementing a standard library. First things first,
and all that. Until you know how to write correct code, you
shouldn't worry about optimization (and you probably shouldn't
be writing libraries for widespread use).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Pete Becker]

On 2008-04-18 15:59:26 -0400, James Kanze <ja*********@gmail.comsaid:

>
Still, given the apparent level of the original poster, I don't
think he's implementing a standard library.

<g>

First things first,
and all that. Until you know how to write correct code, you
shouldn't worry about optimization (and you probably shouldn't
be writing libraries for widespread use).

Well, sure. Proper optimization of library code is an advanced topic.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)