Problem 1864

Ok, very important: this happens only with QT GUI! So it could be a problem of Qt.

I confirm the bug is still present in 10.3.beta , but I confirm the bug is only appearing in Qt, so it seems not related to material category

Laurent, I'm just re-assigning the bug report to you, as Andrea noticed this happens only with Qt.

Hi Marc,
actually I am not sure anymore it is a Qt problem.
It looks like a memory corruption in UI category that for whatever reason appears only w/ Qt.

Anyway it is true that the only way to reproduce to problem is with Qt.

Ok, still present on 10.3. I'll see what I can do.
Sure it's a Qt UI problem?

In G4VBasicShell, newCommand is fine, but commandTree is NULL...

void G4VBasicShell::ListDirectory(const G4String& newCommand) const
{
  G4String targetDir;
  if( newCommand.length() <= 3 ) {
    targetDir = GetCurrentWorkingDirectory();
  } else {
    G4String newPrefix = newCommand.substr(3, newCommand.length()-3);
    targetDir = newPrefix.strip(G4String::both);
  }
  G4UIcommandTree* commandTree = FindDirectory( targetDir );
  if( commandTree == NULL ) {
    G4cout << "Directory <" << targetDir << "> is not found." << G4endl;
  } else {
    commandTree->ListCurrent();
  }
}

Laurent

Definitively not a Qt problem, 

Seems to me there is a bug in G4SubString.
try the following (where you want, even at the first line of any main() ): 

  G4String command = "xxxxxtoto ff";
  G4String command2 = command(0,3);
  printf("command %s 3 fisrt:%s\n",command.data(),command2.data());
  if(command(0,3) == "toto " ) {
    printf("WRONG %s\n");
  } else {
    printf("CORRECT %s\n");
  }

Memory leak somewhere….
Any ideas?

I don't see anything wrong with G4String/G4SubString.

The condition in the test:
  if(command(0,3) == "toto " )
is simply wrong, as command(0,3) returns a G4SubString object which cannot be printed, nor compared with a const char*...
If this kind of comparison is done anywhere in the code, it is clearly wrong.

Try with:
  if(G4String(command(0,3)) == "toto " )
and you'll get the correct answer.

I'm confused. G4SubString has comparisons mehotds http://www-geant4.kek.jp/lxr/source/global/management/include/G4String.hh#L78

inline G4bool operator==(const G4String&) const;
inline G4bool operator==(const char*) const;
inline G4bool operator!=(const G4String&) const;
Inline G4bool operator!=(const char*) const;

What is the meaning of these? 
Indeed this is used when handling ls

OK. Here are my findings... :-)

Note that G4SubString is not actually a string - it contains a pointer to the original string and a position and an extent.

This is the offending method:
inline G4bool G4SubString::operator==(const char* str) const
{
  return (mystring->find(str,mystart,extent) != std::string::npos);
}

In Laurent's test code:

1) Even if find is properly used (see (2) below), using it in this way is NOT the way to compare strings.  The length must match too.  The strings must match exactly - in length and characters.  A find only tells you that the matcher string is present somewhere in the string being matched.

2) find is not being properly used.  The 2nd and 3rd arguments refer to the matcher string, str, NOT the string being matched.  From http://www.cplusplus.com/reference/string/string/find/:
size_t find (const char* s, size_t pos = 0) const;
size_t find (const char* s, size_t pos, size_t n) const;
s is a pointer to an array of characters.
If argument n is specified (3), the sequence to match are the first n characters in the array.
Otherwise (2), a null-terminated sequence is expected: the length of the sequence to match is determined by the first occurrence of a null character.
This explains why the match returns true.  *mystring is "xxxxxtoto ff", find looks for the first occurrence of "tot".  Obviously successful.

3) It seems to me that G4SubString is not useful.  Geant4 works fine for me without it.  All I had to do:
G4String.hh/icc: Remove all references to G4SubString except
G4String.hh
-  inline G4SubString operator()(str_size, str_size);
+  inline G4String operator()(str_size, str_size);
G4String.icc
inline G4String G4String::operator()(str_size start, str_size extent)
{
  return G4String(this->substr(start,extent));
}
G4Tokenizer.hh
-  G4SubString operator()(const char* str=" \t\n",size_t l=0)
+  G4String operator()(const char* str=" \t\n",size_t l=0)

Thank you John for the detailed analysis.

Indepenently the usefulness (or lack-of on which I agree) of G4SubString this is a clear bug in G4String that should be addressed ASAP.

I've re-directed the component to global/management.

Andrea

Indeed, G4SubString is an utility class meant for internal use (required at the time migration from Rogue-Wave string was made), it does not represent a finite string null  terminated. Still it is a mystery to me why such (wrong) operators were included in the implementation...
As suggested by John, I've now removed it all along, as it is clearly no longer necessary, given the concept of sub-string exists within STL string (I believe it was not the case originally). Thanks John!
Tagged "global-V10-03-00".