Fredrik Modéen schrieb:
This code: BPath path1 = "/aaa/bbb"; BPath path2 = "/ccc/ddd"; path1.Append(path2.Path()); printf("%s\n", path1.Path()); Will print "(null)". The reason is that path2 must be relative (and not absolute) so the call to Append fails. I don't have anymore any working ZETA or BeOS installations here to test but I would be surprised if this behaviour is expected. IMHO, it should simply not change the original path. So, is this really the wanetd behaviour? Can someone test this on BeOS/ ZETA and check if the same happens?Same Behavor in Zeta 1.5. BPath path1 = "/aaa/bbb"; BPath path2 = "/ccc/ddd"; path1.Append(path2.Path()); printf("%s\n", path1.Path()); Prints = null BPath path1 = "/aaa/bbb/"; BPath path2 = "ccc/ddd"; path1.Append(path2.Path()); printf("%s\n", path1.Path()); Prints = null BPath path1 = "/aaa/bbb"; BPath path2 = "ccc/ddd"; path1.Append(path2.Path()); printf("%s\n", path1.Path()); Prints = /aaa/bbb (no ccc/ddd added) BPath path1 = "/aaa/bbb"; //BPath path2 = "/ccc/ddd"; path1.Append("ccc/ddd"); printf("%s\n", path1.Path()); Prints = /aaa/bbb/ccc/ddd/
This all becomes clear when reading through the BeBook documentation for BPath. So both the BeOS and Haiku version perform as documented. Append() is implemented via SetTo(). SetTo() is destructive even in case of error. It becomes a matter of liking (or not) the fact that Append() is destructive... and whether this can even be changed, or if this would break any existing apps.
Best regards, -Stephan