Home/ Questions/Q 9160795
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T13:49:15+00:00

I have been stumped by this for a few days now. I am running

  • 0

I have been stumped by this for a few days now. I am running a unit test on one of my classes to make sure everything is correct.

However I am encountering a very strange ‘bug’ when comparing the name of an object.
The name is set when I call constructor. The name is correctly set based on the notes I pass in. However in this one case the BOOST_CHECK fails

To show just how strange this is, here are the values of the two strings in the debugger:

Fdim.name() // "F Diminished"
BOOST_CHECK(Fdim.name() == "F Diminished");  // this fails

Here are the specs for the two strings, taken from debugger:

Fdim.name() 
// size - 12, capacity - 15, 
// chars: [70, 32, 68, 105, 109, 105, 110, 105, 115, 104, 101, 100]

"F Diminished" stored inside a variable (to see specs of string)
// size - 12, capacity - 15,
// chars: [70, 32, 68, 105, 109, 105, 110, 105, 115, 104, 101, 100]

As you can see the strings are identical, yet the == and .compare both fail.

Here is something even more strange:

std::string n = Fdim.name();
std::string r = "F Diminished";
unsigned val = n.compare(r);       // RETURNS 0, everytime
BOOST_CHECK(val == 0);             // fails 
BOOST_CHECK(val == ((unsigned) 0));// fails

I am completely dumbfounded. val always returns 0 when i compare the strings (so they are equal) but val != 0 when I compare?

Does anyone know what the problem could be?
Are there any attributes to a string I should know about that might throw off this comparison check?

EDIT***
The strings are being stored as std::string, i am not using char*, or cstring. member _name is std::string.

Here is the BOOST OUTPUT:

c:/directory etc(64): error in "ChordIdentification": check val == 0 failed
c:/directory etc(65): error in "ChordIdentification": check n == r failed
c:/directory etc(66): error in "ChordIdentification": check val == ((unsigned) 0) failed
c:/directory etc(67): error in "ChordIdentification": check Fdim.name() == "F Diminished" failed

Here is the code for the test case, just to make sure people know what val, n, and r are:

BOOST_AUTO_TEST_CASE(ChordIdentification)
{
MAKE_NOTE(Db, 'D', FLAT);   // macro that creates a note
MAKE_NOTE(F, 'F', NATURAL);
MAKE_NOTE(Ab, 'A', FLAT);
MAKE_NOTE(Cb, 'C', FLAT);

Chord DbMajor7 = Chord(Cb, Ab, F, Db);
Chord Fdim = Chord(Ab, Cb, F);

CHORD_TEST(DbMajor7, "Db Dominant7", MAJ, THIRD_INVERSION, DOMINANT7); macro of several boost tests, checking members. This test passes completely for this instance of chord. name() check is passed
std::string n = Fdim.name();
std::string r = "F Diminished";
unsigned val = n.compare(r);
//if (val == 0)
BOOST_CHECK(val == 0);
BOOST_CHECK(n == r);
BOOST_CHECK(Fdim.name() == std::string("F Diminished"));    // these strings fail to compare. no idea why, lengths are same, chars same?????
BOOST_CHECK(std::strcmp(Fdim.name(), "F Diminished") == 0);
CHORD_TEST(Fdim, "F Diminished", DIM, FIRST_INVERSION, DIMINISHED); // partially successful, again the string comparison is responsible for this
}
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I have finally discovered why this was happening. It was to do with the fact that the debugger could not determine what instance of child class it was trying to evaluate.

    The chord’s are being identified via a map, with a polymorphic key, with an abstract base class (Composite_Key), child (Composite_Key_2Intervals) and Child from that child (Composite_Key_3Intervals)

    What was failing, was the fact that any sort of test on whether or not a key was indeed 3 intervals, or 2, was always returning true, because 3intervals : 2intervals. The compiler was not able to pick up on this, and always gave back the wrong value found in the look up table.

    Also, the map never sorted in debugger mode, so the order that the keys were inserted stayed the same. However in reality they were being reshuffled, which caused the whole evaluation while debugging to be completely false.

    To fix this, I now made sure that these two classes only inherit from the abstract base, so that they are not related in any way to each other. Now all tests pass and everything comes back true.

    This cause of this problem was solely the debugger. It did not evaluate appropriately.

    • 0