Passing char* not working

[Paul Bibbings]

Yes, but this thread has been restarted on comp.std.c++, so maybe
there's a better mechanic over there.

And on comp.lang.c++.moderated. At least it's not a cross-posting.
Having said that, these three are my personal stock comp.* groups. Is
it reasonable to reply from one group to say "see over there, where your
question has already been `answered'"?

Regards

Paul Bibbings

 

[Ian Collins]

And on comp.lang.c++.moderated. At least it's not a cross-posting.
Having said that, these three are my personal stock comp.* groups. Is
it reasonable to reply from one group to say "see over there, where your
question has already been `answered'"?

I already have!

I wonder if there are any groups where this hasn't been asked?

 

[Ankit]

That sounds like taking the working car to a car designer and asking for
help repairing the broken one.

Brian

What to do? It is really very difficult to pull out the code from
large base and provide here. best is proxy the same and provide the
simplified version. unfortunately simplified version works. But same
doesn't works in actual environment.

I tried using string, char[] and other means but not working.

 

[Ankit]

I already have!

I wonder if there are any groups where this hasn't been asked?

I have asked on 3 groups. One this. Another on solaris group and
another on moderated C++ group, with the hope of extending chances of
some solution from probably wider community.

 

[Kai-Uwe Bux]

What to do? It is really very difficult to pull out the code from
large base and provide here. best is proxy the same and provide the
simplified version.

True, the operative word being _same_.

unfortunately simplified version works. But same
doesn't works in actual environment.

Then it's not the _same_. At least, the exercise shows you that the problem
is in the parts of the code that you did _not_ incorporate in the posted
sample. However, since the code you posted does not show the problem, we
cannot help.

I tried using string, char[] and other means but not working.

All you can do is keep working until you have a code sample that shows the
problem. Then we can help finding the cause _within the code you post_.


Best

Kai-Uwe Bux

 

[Paul Bibbings]

What to do? It is really very difficult to pull out the code from
large base and provide here. best is proxy the same and provide the
simplified version. unfortunately simplified version works. But same
doesn't works in actual environment.

I tried using string, char[] and other means but not working.

Start with your `large code base' and make a working copy of that
somewhere. I'm assuming, as it is large, that there will be large
elements that are not relevant to your current problem. In your copy,
begin removing these and, *at each stage*:

1. Adjust (if necessary) what remains so that it still compiles -
i.e., remove any calls into the code that you have identified as
irrelevant to the problem; and
2. Ensure that the problem remains exactly as in the original
project.

Keep doing this systematically (including the above checks) until you
have removed everything that is `obviously' irrelevant.

Then, start focussing on what remains and begin *simplifying*.
Concentrate on reducing the code that you have left until you have the
*smallest* code example possible that is still able to illustrate the
problem.

The first stage above should sheer off vast chunks of your project. The
real work is in the second stage and, as Pete stated in an earlier post,
it is very likely that in doing this, you will find the error for
yourself.

To assist with this, start with identifying a single call into your code
base that triggers the error. Follow through all nested calls and
invocations and isolate these from the rest of the code that is not
called. (You had probably assumed that you had done this in the code
you have already posted, but clearly you had not, since you had
obviously removed something that was *not* irrelevant in the above
sense.)

I don't think that anyone here is wanting to suggest that this kind of
process is necessarily easy. However, the ability to possess this skill
and be able to apply it efficiently is indispensible in a programmer's
toolbox.

It may be frustrating. However, in ultimately getting there, it can be
rewarding too. Especially if you do find it for yourself.

Regards

Paul Bibbings

 

[Paul Bibbings]

I tried using string, char[] and other means but not working.

Be careful here. Given what little we can understand of the problem as
it stands, this looks a little like trying to find *solutions* before
you have identified the *problem*. It is, of course, possible that you
will be lucky doing it this way. However, even if this were to be the
case, very likely your opportunities for learning will have been greatly
reduced. Furthermore, you would have effectively denied yourself the
greater opportunity of learning - and putting into practise - an
invaluable skill.

Also, I do not think that we have heard anything yet about your attempts
at applying a debugger to the `large code base'. You have presented a
scenario in which a string presented to printf prints under some
circumstances and doesn't under others. In a debugger, have you
analysed whether, for the failing instances, there is actually a string
to print? If you find that there is not - where your perception of your
code would lead you to expect there would be - have you traced it back
through your code to locate the point where it `disappears' (or, more
correctly, to that earliest point at which you would expect a printable
string to be available where one is, in fact, not)?

Bring *all* your skills and tools to bear on this. With application,
you *will* solve this, with or without the need to seek help from this
group. (And do not be disheartened if it feels, at this stage, that
no-one here is giving you the help that you seek. Your request has not
been ignored, but there are a number of minimal requirements that *must*
be in place for the code that you present with your question for it to
be at all /possible/ to offer help. When those requirements are met, if
you have still not reached a solution, you will find no shortage of help
here, I can assure you.)

Regards

Paul Bibbings

 

[Paul Bibbings]

Paul Bibbings ha scritto:


Since when is multi-posting considered an acceptable practice on Usenet?

I have no idea about it. I think that my point was that it at least
would help in cutting down the proliferation of repeated replies going
to all three places that the OP didn't cross-post. Assuming, that is,
the a cross-posted message immediately picks up all the groups posted to
as a `reply-to'.

Regards

Paul Bibbings

 

[Öö Tiib]

I have asked on 3 groups. One this. Another on solaris group and
another on moderated C++ group, with the hope of extending chances of
some solution from probably wider community.

But your question can not be answered based on information you have
given. There is quite likely some undefined behavior in parts of your
code that you have not posted. Software containing undefined behavior
behaves strangely, may work on one operating system and not work on
other operating system. I have seen it lot of times during years.

Only thing that is sure, do not attempt to voodoo-fix it. Even if it
temporarily goes away it will most likely come back after some changes
elsewhere and then you have voodoo code about what no one can tell
what it is.

 

[Kaar]

On 05/22/10 08:17 AM, Ankit wrote:

Please:

a) stop top-posting and
b) take the time to distil a compilable example the demonstrates your
problem.

I would suggest the following:

1) When you are writing C++, stick with C++ and use string. Not only
because it is better and safer than char*, but for consistency of your
code and the ability to have compilers better optimize your code, and
most importantly to make better use of external libraries which are
also C++ and not C directed.

2) IF you insist on passing a pointer to any function with the intent
of passing an array (char or otherwise) make sure you pass the length
of the array with it and use it to dissolve any ambiguity. Different
compilers have different symantics to analyze arrays for which no size
parameters is passed. In case of char array, some compilers would
translate it as "keep reading until you hit a \n" which the people
mentioned above. Other compilers may interpret it differently, and
hence the minor non-portability issues.

3) For example, see these two different constructors of string:

string ( const char * s, size_t n );
Content is initialized to a copy of the string formed by the first
n
characters in the array of characters pointed by s.


string ( const char * s );
Content is initialized to a copy of the string formed by the null-
terminated character sequence (C string) pointed by s. The length of
the caracter sequence is determined by the first occurrence of a null
character (as determined by traits.length(s)). This version can be
used to initialize a string object using a string literal constant.

See how the first resolves the ambiguity completely, but the second
relies on that null character.

Unfortunately, your code does not help a lot, but it would do you
best, not for this particular error, but for your program in general,
to move to C++ directed syntax and symantics. To keep your huge code
base in your case, try to change the definitions of char* to string,
and then if you have used the char* in ALOT of places, just use
yourString.c_str() to handle backward compatibility.

David Karam

 

[James Kanze]

On 05/22/10 10:29 AM, James Kanze wrote:

Eh? I don't think I've ever *not* used a string constant as
the format specifier for printf.

Really? And how to you handle internationalization? The fact
that the format string has to be translated into many different
languages?

 

[Ian Collins]

Really? And how to you handle internationalization?

Being English, I shout

OK, don't usually have to. Just about everything I write is for local
clients for internal use.

The fact
that the format string has to be translated into many different
languages?

The couple of times I've had to do that, we used code generation from
text files we could send away for translation.