06 Feb, 2009, David Haley wrote in the 21st comment:
Votes: 0
It outputs the "accents" as fancy quotes when it detects that the locale supports it. It makes things pretty but very annoying to copy/paste…
06 Feb, 2009, quixadhal wrote in the 22nd comment:
Who was the brainiac that decided to add locale support to everything anyways? I want to go back in time and smear icy hot on his keyboard…
You can "fix" that issue by setting your shell's locale to "normal", I use "export LANG=C" in by .bashrc file. That stops all your GNU tools from trying to get cute.
If you really code in another language that needs the extended characters (and your boss doesn't flog you for writing code that can't be shipped to the overseas office), you can always not do that. :)
You can "fix" that issue by setting your shell's locale to "normal", I use "export LANG=C" in by .bashrc file. That stops all your GNU tools from trying to get cute.
If you really code in another language that needs the extended characters (and your boss doesn't flog you for writing code that can't be shipped to the overseas office), you can always not do that. :)
06 Feb, 2009, David Haley wrote in the 23rd comment:
There are good reasons for locale support; for example, oh, the vast majority of the world's languages other than English needing other characters… :wink: I think your real complaint should be with the smart quotes, not the fact that programs support locales. (If you really don't like locales, what you're saying is that you don't care about other languages, which is a whole different discussion…)
Most compilers don't accept extended characters in program input, so this isn't really a problem, fortunately.
Quote
If you really code in another language that needs the extended characters
Most compilers don't accept extended characters in program input, so this isn't really a problem, fortunately.
06 Feb, 2009, Zeno wrote in the 24th comment:
Igabod said:
ok now I'm starting to think my entire code is corrupted, I got this after commenting out line 2806 of merc.h
–> Compiling file: act_comm.c <–
[- act_comm.c compiled OK -]
–> Compiling file: act_info.c <–
act_info.c: In function âdo_diagnoseâ: <—————————supposed to be do_diagnose but it's adding an accented a to both ends.
act_info.c:4233: warning: the address of âargâ will never be NULL <————— arg with accented a on both ends
[- act_info.c compiled OK -]
–> Compiling file: act_move.c <–
act_move.c: In function âdo_trainâ: <——————————supposed to be do_train but it's adding an accented a to both ends.
act_move.c:2710: error: lvalue required as left operand of assignment
act_move.c:2717: warning: assignment from incompatible pointer type
act_move.c:2725: warning: assignment from incompatible pointer type
make: *** [obj/act_move.o] Error 1
Those "accented" are how PuTTy etc displays it. See this: http://www.arthmoor.com/forum/index.php?...
06 Feb, 2009, quixadhal wrote in the 25th comment:
DavidHaley said:
There are good reasons for locale support; for example, oh, the vast majority of the world's languages other than English needing other characters… :wink: I think your real complaint should be with the smart quotes, not the fact that programs support locales. (If you really don't like locales, what you're saying is that you don't care about other languages, which is a whole different discussion…)
And yet, most of those other countries all use English as the language of business, and most multi-national corporations require that program source code be written in, you guessed it, English. I have no issue with localization for data, and for display purposes. I don't even really mind it in source code (although it's a pain). I do, however, mind the seemingly arbitrary decision to add "cute" things like those so-called "smart quotes", which do absolutely nothing to help you debug your program, and break more often than not in most people's terminal emulators.
06 Feb, 2009, David Haley wrote in the 26th comment:
Your initial comment was bemoaning the stupidity of localization in general, not in source code, and I was pointing out that wasn't a really fair statement :wink:
This is a wee bit exaggerated. Yes, it is likely that communication with other companies from other countries is done in English. But it is incredibly unlikely that people don't use their native language internally. The exception would be large multinationals with lots of international people at each office location; SAP is an example of this. Even so, in Germany, they have a very strong propensity to speak in (no surprise) German…
They're only enabled if the terminal supports it in the first place. The problem isn't the terminals, it's with other programs that don't support the charsets as you move text between them.
quixadhal said:
And yet, most of those other countries all use English as the language of business
This is a wee bit exaggerated. Yes, it is likely that communication with other companies from other countries is done in English. But it is incredibly unlikely that people don't use their native language internally. The exception would be large multinationals with lots of international people at each office location; SAP is an example of this. Even so, in Germany, they have a very strong propensity to speak in (no surprise) German…
quixadhal said:
and break more often than not in most people's terminal emulators.
They're only enabled if the terminal supports it in the first place. The problem isn't the terminals, it's with other programs that don't support the charsets as you move text between them.
07 Feb, 2009, Igabod wrote in the 27th comment:
I'm just gonna paste the entire do_train function in pastebin so you can see how it's done. The pAbility += 1 is done a little different than you said.
http://www.mudbytes.net/index.php?a=past...
I've edited the rest of do_train a little bit so it's not quite stock, but the parts in question so far are basically stock.
http://www.mudbytes.net/index.php?a=past...
I've edited the rest of do_train a little bit so it's not quite stock, but the parts in question so far are basically stock.
07 Feb, 2009, Sharmair wrote in the 28th comment:
Igabod said:
I'm just gonna paste the entire do_train function in pastebin so you can see how it's done. The pAbility += 1 is done a little different than you said.
http://www.mudbytes.net/index.php?a=past...
I've edited the rest of do_train a little bit so it's not quite stock, but the parts in question so far are basically stock.
http://www.mudbytes.net/index.php?a=past...
I've edited the rest of do_train a little bit so it's not quite stock, but the parts in question so far are basically stock.
Actually, it look like your stat mod line is exactly what I had you looking for (line 805 in the pastebin).
Though that part of my fix would have to be changed just a bit because of the else just before it.
Your code lines 804 to 806 (with fixed up indentation):
else
*pAbility += 1;
if ( !str_cmp( arg1, "avatar") )
Can be replaced with:
else{
if(pAbility)
*pAbility += 1;
else if(pIntAbil)
*pIntAbil += 1;
}
if ( !str_cmp( arg1, "avatar") )Also, I noticed you use pAbility with hp, mana and move at lines 709, 714 and 719. The pAbility
in those three lines should be replaced with pIntAbil.
The idea of this fix (which is really a fix of you changing some of the trainable data from sh_int
to int) is to still use pAbility for the sh_int data, but add the pIntAbil for use by the int data.
pIntAbil should be used in all places pAbility was for the changed int type data (in your case now
hp, mana and move). Now, since there are two different data pointers that could be used, both
are initialized to NULL at the start. Then the one that matches the data type of the target data
is used. Then at the end, when it comes time to actually change the data, the pAbility is checked
to see if it is still NULL, if it is not, it is the one used and the data it is pointing to is upped. If it
is NULL, then pIntAbil is checked to see if it is still NULL, if it is not, then that pointed to data is
upped. If both are still NULL, then neither was used and nothing is upped through either of them
(this case might never happen in the code as it is, as it probably would have crashed with the
old code, but with a function as complex as this seems to be now, having the safety of the check
is probably good).
07 Feb, 2009, Igabod wrote in the 29th comment:
Perfect explanation, I was having trouble understanding what you said yesterday but this is crystal clear. I'll make the changes and let you know how it goes, thanks for the patience and assistance.
07 Feb, 2009, Igabod wrote in the 30th comment:
Ok crashed again, the backtrace is rather long for some reason, but here it is.
A common line is act_move.c 2637 which is line 107 in the pastebin. I am still unskilled in the ways of gdb so i'm completely at a loss for what to do here.
#0 do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:3211
#1 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#2 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#3 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#4 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#5 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#6 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#7 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#8 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#9 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#10 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#11 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#12 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#13 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#14 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#15 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#16 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#17 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#18 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#19 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#20 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#21 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#22 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#23 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#24 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#25 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#26 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#27 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#28 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#29 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#30 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#31 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#32 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#33 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#34 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#35 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#36 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#37 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#38 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#39 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#40 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#41 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#42 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#43 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#44 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#45 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#46 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#47 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#48 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#49 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#50 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#51 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#52 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#53 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#54 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#55 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#56 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#57 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#58 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#59 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#60 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#61 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#62 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#63 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#64 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#65 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#66 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#67 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#68 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#69 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#70 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#71 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#72 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#73 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#74 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#75 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#76 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#77 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#78 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#79 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#80 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#81 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#82 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#83 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#84 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#85 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#86 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#87 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#88 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#89 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#90 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#91 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#92 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#93 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#94 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#95 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#96 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#97 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#98 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#99 0x000000000041953c in do_train (ch=0x7fdc9f1c3360, argument=<value optimized out>) at act_move.c:2637
#100 0x000000000047ba90 in interpret (ch=0x7fdc9f1c3360, argument=0x7fdc9f1c3180 "hp 100") at interp.c:4816
#101 0x0000000000450d0f in game_loop_unix (control=7) at comm.c:883
#102 0x0000000000451204 in main (argc=2, argv=0x7fffa852bd38) at comm.c:497
A common line is act_move.c 2637 which is line 107 in the pastebin. I am still unskilled in the ways of gdb so i'm completely at a loss for what to do here.
07 Feb, 2009, Guest wrote in the 31st comment:
What line in your pastebin copy is act_move.c:3211? That's where the problem seems to be.
Also, your backtrace is a mile long because you told it to train HP 100 times, and your code recursively calls do_train until the "amount" variable is down to 1.
Also, your backtrace is a mile long because you told it to train HP 100 times, and your code recursively calls do_train until the "amount" variable is down to 1.
07 Feb, 2009, Igabod wrote in the 32nd comment:
line 3211 is 684 in pastebin
07 Feb, 2009, Sharmair wrote in the 33rd comment:
On all those if statements that have *pAblility or *pIntAbil at the start, switch the order like:
Make that:
I will look the code over a bit closer to see if there are other issues that the change affects.
if ((*pAbility >= max_stat) && (!str_cmp( arg1, "str")))
Make that:
if ((!str_cmp( arg1, "str")) && (*pAbility >= max_stat))
I will look the code over a bit closer to see if there are other issues that the change affects.
07 Feb, 2009, Igabod wrote in the 34th comment:
That was it, if you don't mind though, could you explain why that actually made a difference?
07 Feb, 2009, Sharmair wrote in the 35th comment:
Igabod said:
That was it, if you don't mind though, could you explain why that actually made a difference?
When C/C++ evaluates a conditional like this, it evaluates from left to right and as soon as it
knows the outcome (whether the whole thing will be true or false) it will stop evaluating. In
this case we have an AND (both parts have to be true for the outcome to be true) so if the first
part is false, it knows the outcome can't possibly be true, so it stops and never evaluates the 2nd
part (and in this case, does not try to dereference the NULL pointer). This same thing works
with OR, but will stop when it knows the outcome will be true.
08 Feb, 2009, Igabod wrote in the 36th comment:
ah ok that makes a lot of things that I couldn't figure out on another codebase I'm playing with make sense. Thank you so much. Now I've got pretty much all my new warnings from the 4.3.2 switch fixed except for one file.
the others are just other weapon types with the same format. I've never seen this warning before and don't know what it means. Any assistance would be appreciated.
fight.c: In function 'dam_message':
fight.c:3679: warning: comparison with string literal results in unspecified beh
avior
fight.c:3679: warning: comparison with string literal results in unspecified beh
avior
fight.c:3822: warning: comparison with string literal results in unspecified beh
avior
fight.c:3822: warning: comparison with string literal results in unspecified beh
avior
fight.c:3869: warning: comparison with string literal results in unspecified beh
avior
fight.c:3869: warning: comparison with string literal results in unspecified beh
avior
fight.c:3869: warning: comparison with string literal results in unspecified beh
avior
fight.c:3931: warning: comparison with string literal results in unspecified beh
avior
fight.c:3943: warning: comparison with string literal results in unspecified beh
avior
fight.c:3996: warning: comparison with string literal results in unspecified beh
avior
fight.c:4005: warning: comparison with string literal results in unspecified beh
avior
fight.c:4005: warning: comparison with string literal results in unspecified beh
avior
if ( attack == "slash" || attack == "slice" ) <————–line 3679 of fight.c
{
damp=number_range(1,8);
if ( damp == 1 )
{
act("You swing your blade in a low arc, rupturing $N's abdominal ca$
act("$n swings $s blade in a low arc, rupturing $N's abdominal cavi$
act("$n swings $s blade in a low arc, rupturing your abdominal cavi$
victim->fatal = 26;
make_part(victim,"entrails");
}
else if ( damp == 2 )
{
act("You thrust your blade into $N's mouth and twist it viciously.\$
act("$n thrusts $s blade into $N's mouth and twists it viciously.\n$
act("$n thrusts $s blade into your mouth and twists it viciously.\n$
victim->fatal = 27;
}
the others are just other weapon types with the same format. I've never seen this warning before and don't know what it means. Any assistance would be appreciated.
08 Feb, 2009, Kline wrote in the 37th comment:
Don't compare strings with ==. Use !str_cmp(attack,"slash") … etc instead. Or another string comparison func.
08 Feb, 2009, David Haley wrote in the 38th comment:
That's funny, I didn't think the behavior was unspecified. Useless and unexpected, perhaps, but not unspecified…
08 Feb, 2009, quixadhal wrote in the 39th comment:
Hmmm, actually… it could be unspecified, in a roundabout way.
"hello" == "hello" is only true (in C) if both constants evaluate to the same memory address, since you aren't comparing the string contents, you're comparing the addresses where they begin. I could see some compilers collapsing all constant strings like that to single entries in the code segment to reduce space. I could also see some compilers giving them each a seperate location, which would allow you to change one without changing others.
I'd also be willing to bet that 99% of them would collapse to the same address… but there's probably one oddball one out there. :)
I would hope that C++ would provide an operator for char * constants that would compare them as you'd expect it to work (and as std::strings vs. char * constants do work).
"hello" == "hello" is only true (in C) if both constants evaluate to the same memory address, since you aren't comparing the string contents, you're comparing the addresses where they begin. I could see some compilers collapsing all constant strings like that to single entries in the code segment to reduce space. I could also see some compilers giving them each a seperate location, which would allow you to change one without changing others.
I'd also be willing to bet that 99% of them would collapse to the same address… but there's probably one oddball one out there. :)
I would hope that C++ would provide an operator for char * constants that would compare them as you'd expect it to work (and as std::strings vs. char * constants do work).
08 Feb, 2009, David Haley wrote in the 40th comment:
No, what I meant is that the behavior is very specified: it compares the memory address of the two literals. Of course you could get unexpected results depending on implementation etc., but I just thought it was weird to say that the comparison itself is unspecified.
How do you tell a char* that is a string from a char* that is a pointer to an address in memory? When do you use the pointer equality test and when do you go into "string equality" mode?
The problem here is that char* are strings kind of incidentally: a char* is a pointer to an address in memory first and foremost.
Quote
I would hope that C++ would provide an operator for char * constants that would compare them as you'd expect it to work
How do you tell a char* that is a string from a char* that is a pointer to an address in memory? When do you use the pointer equality test and when do you go into "string equality" mode?
The problem here is that char* are strings kind of incidentally: a char* is a pointer to an address in memory first and foremost.
Random Picks
