odd behavior

>>I would assume that the "transfer by value" is normally a good thing BUT NOT IN A CONSTRUCTOR. I

Transfer by value, is normally a bad thing, unless the value is of int size or less.

Why do you think transfer by value is normally good?

I still don't understand what you're trying to accomplish with your constructor.

Does your SString class derive from std::string?

I do have a copy constructor and must have one since the pointer element is an element where I keep a reference count.

The class is something like this (I have removed several functions which are irrelevant here).

class SString {
private:
    char * M_s;

    static SString snull;

    // Special constructor fo snull.
    SString(int *);

public:

       SString();
       SString(const SString & s);
       SString(const char * s);
       ~SString();

        // This function is public but in the program only
        // a few selected places actually call them.
        // this one is called if you ever store a copy
        // of M_s anywhere. Dire things will happen
        // if s below is not a SString M_s string.
        static void addref(char * s);
        static void subref(char * s);

     ....lots of other functions....
};

In the .cxx file I have some code like this:

struct stringdata_t {
     int refs;
     int length;
     int size;
};

#define GETDATAFROMSTRING(s) (reinterpret_cast<stringdata_t *>(s) - 1)
#define GETSTRINGFROMDATA(d) reinterpret_cast<char *>((d) + 1)
#define ALLOCDATAFORSTRING(len) reinterpret_cast<stringdata_t *>(xmalloc(sizeof(stringdata_t) + 1 + (len)))
#define ADDREFSTRING(s) \
     do { \
         GETDATAFROMSTRING(s)->refs++; \
    } while (0)
#define SUBREFSTRING(s) \
    do { \
          if ((s) != NULL) { \
             stringdata_t * temp = GETDATAFROMSTRING(s); \
             if (--(temp -> refs) == 0) \
                      xfree(temp); \
         } \
    } while (0)

void SString::addref(char * s)
{
    ADDREFSTRING(s);
}

void SString::subref(char * s)
{
    SUBREFSTRING(s);
}

// Special constructor to build snull.
SString::SString(int *)
{
    stringdata_t * p = ALLOCDATAFORSTRING(0);
     p -> refs = 1;
     p -> size  = 1;
     p -> length = 0;
    M_s = GETSTRINGFROMDATA(p);
}

// Default constructor.
SString::SString()
   : M_s(snull.M_s)
{
    ADDREF(M_s);
}

// Copy constructor
SString::SString(const SString & s)
    : M_s(s.M_s)
{
   ADDREF(M_s);
}

// construct an SString from a char * string.
SString::SString(const char * s)
   : M_s(snull.M_s)
{
    if (s != NULL) {
        size_t len = strlen(s);
         stringdata_t * p = ALLOCDATAFORSTRING(len);
         p -> refs = 1;
         p -> size = len + 1;
         p -> length = len;
        M_s = GETSTRINGFROMDATA(p);
        strcpy(M_s,s);
    } else {
        ADDREF(M_s);
    }
}

SString::~SString()
{
    SUBREF(M_s);
}

Ok, so it's not exactly like above. For example when we allocate buffer for a string the size isn't exactly length + 1 but can be larger. For "small" strings we have a set of "suitable sizes" and we enlarge the size to fit one of those. For large strings we allocate length + 1.

However, the string class works fine - that is really the odd thing, it generally works fine. it is just that this particular place the compiler insist on translating:

SString contact;

so that if I in the debugger display & contact  == XXXXXX and contact.M_s  = YYYYYY and when I enter the constructor SString::SString I see that this is equal to YYYYY and not XXXXX as it should be.

What really freaks me out is that it appears to work fine just about anywhere else... We use this class a lot so I am sure that if it was the class that had a problem we would have seen more problems happening. I am fairly sure it is the place of the call to the constructor that is at fault and not the class itself. However, if I can do something to the class so that it doesn't do this it would solve the problem.

Alf

Because the class happen to be of size int (well, void * to be more exact).

For such 'small' classes it is normally a good thing that you have transfer by value. It avoids a lot of indirect references, no need to worry about memory allocation (keep it in registers) etc, etc...

The problem arise if caller and callee do not agree on whether it is used or not.

Alf

Hmm, stuptid question: Do you have any optimizations turned on?

So, I understand that the declaration...

    SString contact;

...calls the default contructor...

   SString::SString()  : M_s(snull.M_s)
   {
       ADDREF(M_s);
   }

...which increments the stringdata_t reference count in your static SString snull, which itself was constructed by SString::SString(int *) for obvious reasons.

What I don't understand is what you are seeing in your debugger. Do you see constact.M_s point to something other than the address of stringdata_t pointed to by snull.M_s after construction, or does the problem arise later in your code?

Oh hang on... ADDREF isn't defined in the code you posted. Did you mean to put ADDREFSTRING?

I mean...

#define ADDREF(p) \
        ((reinterpret_cast<stringdata_t *>(p))->refs++)
#define SUBREF(p) \
        ((reinterpret_cast<stringdata_t *>(p))->ref--)


??

Does the problem appear with your compiler in the following trivial program:

--------8<--------
#include <iostream>
#include <memory>

#define xfree   free
#define xmalloc malloc

class SString {
private:
   char * M_s;

   static SString snull;

   // Special constructor fo snull.
   SString(int *);

public:

      SString();
      SString(const SString & s);
      SString(const char * s);
      ~SString();

       // This function is public but in the program only
       // a few selected places actually call them.
       // this one is called if you ever store a copy
       // of M_s anywhere. Dire things will happen
       // if s below is not a SString M_s string.
       static void addref(char * s);
       static void subref(char * s);

//    ....lots of other functions....
};

struct stringdata_t {
    int refs;
    int length;
    int size;
};

#define GETDATAFROMSTRING(s) (reinterpret_cast<stringdata_t *>(s) - 1)
#define GETSTRINGFROMDATA(d) reinterpret_cast<char *>((d) + 1)
#define ALLOCDATAFORSTRING(len) reinterpret_cast<stringdata_t *>(xmalloc(sizeof(stringdata_t) + 1 + (len)))
#define ADDREFSTRING(s) \
    do { \
        GETDATAFROMSTRING(s)->refs++; \
   } while (0)
#define SUBREFSTRING(s) \
   do { \
         if ((s) != NULL) { \
            stringdata_t * temp = GETDATAFROMSTRING(s); \
            if (--(temp -> refs) == 0) \
                     xfree(temp); \
        } \
   } while (0)

void SString::addref(char * s)
{
   ADDREFSTRING(s);
}

void SString::subref(char * s)
{
   SUBREFSTRING(s);
}

// Special constructor to build snull.
SString::SString(int *)
{
   stringdata_t * p = ALLOCDATAFORSTRING(0);
    p -> refs = 1;
    p -> size  = 1;
    p -> length = 0;
   M_s = GETSTRINGFROMDATA(p);
        std::cout << "int* constructor called\n";
}

#define ADDREF(p) \
        ((reinterpret_cast<stringdata_t *>(p))->refs++)
#define SUBREF(p) \
        ((reinterpret_cast<stringdata_t *>(p))->refs--)

// Default constructor.
SString::SString()
  : M_s(snull.M_s)
{
   ADDREF(M_s);
        std::cout << "Default constructor called\n";
}

// Copy constructor
SString::SString(const SString & s)
   : M_s(s.M_s)
{
  ADDREF(M_s);
        std::cout << "Copy constructor called\n";
}

// construct an SString from a char * string.
SString::SString(const char * s)
  : M_s(snull.M_s)
{
   if (s != NULL) {
       size_t len = strlen(s);
        stringdata_t * p = ALLOCDATAFORSTRING(len);
        p -> refs = 1;
        p -> size = len + 1;
        p -> length = len;
       M_s = GETSTRINGFROMDATA(p);
       strcpy(M_s,s);
        std::cout << "Constructed from non-NULL char*\n";
   } else {
       ADDREF(M_s);
        std::cout << "Contructed from NULL char*\n";
   }
}

SString::~SString()
{
   SUBREF(M_s);
        std::cout << "Destructor called\n";
}

SString SString::SString::snull((int*)0);

int main()
{
        std::cout << "main entered\n";
        {
                SString contact;
                std::cout << "contact constructed\n";

                SString contact2("Fred");
                std::cout << "contact2 constructed as \"Fred\"\n";

                SString contact3(contact2);
                std::cout << "contact3 contracted from contact2\n";

        }
        std::cout << "contacts all destructed\n";

        std::cout << "main exiting\n";
}
--------8<--------

I suggest that you have look at the source code for MFC's CString class.   The brains at Microsoft have confronted these issues and solved them all.  Perhaps examining their code will jar something loose.

They call an Init() fn in every constructor that presets the CStringData structure to a predefined value, including a reference count of -1.

-- Dan

Salte,
Your explanation is still ambiguous.  You usually do such a good job of giving long detailed answers for other member's questions, but in your question here, you seem to be missing the important details.

Can you post an example code that uses you're SString class, and that gives you the undesired results?
Something like this:
SString Data1 = "Data needed to reproduce error";

SString Data2 = Data1; //Format that produces error, and comment stating the erroneous results

Try to keep it simple, an comment the point at which you get the undesired results.

I think I now see what you're trying to accomplish.

Correct me if I'm wrong, but you're trying to create a default SString so that when an EMPTY SString object is created, all you have to do is point to the snull object, instead of allocating memory for a new SString object.

If this is the case, then I agree with DanRollins, in that you should look at the CString class.
The current method of this class has a lot of potensial problems with using snull.

Please verify if your current problem is associated with the creation of your snull object.

Note that some of the code for CString is in AFX.H and AFX.INL as well as STRCORE.CPP and STREX.CPP
-- Dan

I just looked at your code some more, and there are diffinitely problems with the use of snull.

snull is a static member, which is created in a seperate tranlation unit.
According to the C++ standard, there's no method for garanteeing the order in which none-POD objects are created in different translation units.

So say you have the following:

//In SString.cpp
SString SString::SString snull((int*)NULL);


//In main.cpp

SString MyString;

int main(int, char*)
{
  cout << MyString;
  return 0;
}

This code is considered to have undefined results, because there's no garantee that snull will be created before MyString is created.
If MyString is initialized first, then M_s will be pointing to sum random value.

SString::SString()
 : M_s(snull.M_s) //Since snull is not yet initialized, this can be pointing to anything

continue....

The way Microsoft got around this problem, was by initializing a CString object to a POD type.
This works, because the standard does garantee that build-in types get initialized before custom types, and POD types get initialized before custom types (types with constructors).

This is the method I recommend you use.

If you need help with setting it up, I can post an example.

Here's a workaround solution:

class SString {
private:
   char * M_s;

   static SString &snull; //Make this a reference

***********************
In cpp file:

struct stringdata_t {
   int refs;
   int length;
   int size;
};


stringdata_t DataForSnull= {1,1,0};
SString SString::SString &snull = (SString)GETSTRINGFROMDATA(&DataForSnull);


This should work because DataForSnull is a POD type, and snull is a reference.
Both type will get initialized before any other custom type, which will insure you're snull is initialized before any other SString object.

From your original question:
>>d) The result is that the random garbage value is then taken as the pointer to where the SString object should be constructed and the constructor returns.

The random garbage is most likely due to the object been initialized in seperate translation unit.
So to answer your original question, what the debugger is showing you is the multi translation unit problem previouly described, and it has nothing to do with the compiler picking the wrong constructor.

On the other hand, Microsoft is the *actual* evil empire, so maybe you should not emulate anything that they have done.

Salte --

// Special constructor to build snull.
SString::SString(int *)
{
   stringdata_t * p = ALLOCDATAFORSTRING(0);
    p -> refs = 1;
    p -> size  = 1;
    p -> length = 0;
   M_s = GETSTRINGFROMDATA(p);
}

This is already handled by the void-parameter-list version of the constructor. Can you live without this?  b/c it seems that your reported mis-overloading of the constructor may be related to this.  Comment that out...

Peace,
Nick

First off,

I think I have resolved the problem. The code is sort of doing the right thing.

The declaration is fine, it's just that since that string is returned, the compiler appear to do it like this:

Ok, he declares a string and then returns it. Since the function have SString return type I translate that into a hidden pointer to SString parameter as input, so the function:

SString SomeClass::func(int x);

is translated into:

void SomeClass_func(SString * retval, SomeClass * const this, int x);

The declaration is ignored, since it is only used to build the return type and whenever my code refer to 'contact' it translates it into a reference to 'retval' since retval is a pointer to string the compiled code does the right thing.

I should have guessed it was something like that since the location of that value was in a positive offset from EBP - local variables are stored in negative offsets from EBP while arguments have positive offsets.

It does puzzle me though still since the call is like:

SString some_str = SomeClassObj -> func(x);

and the &some_str is NOT the value passed in as argument to func....

Intstead the code appearantly creates an additional temp in the callers stack frame and it is the value of that SString that is passed as argument. I hope that when I turn on optimization that it removes that utterly useless compiler generated temporary SString variable.

The debugger still get it wrong though since the debugger appearantly treat 'contact' as a regular SString variable and not as a pointer to string as it should but I guess that is a gdb bug and not a gcc bug. What is really going on is that the compiler essentially ignore the 'contact' declaration and pretend that variable wasn't declared and whenever I use 'contact' in the code the compiler translates it to *retval and whenever &contact is called for it uses retval. However, the debugger, gdb, is obviously unaware of all this and pretend that contact exist and that is the cause of the problems.

Anyway, thank you for any help you guys offered and it at least gave me a nudge to look in the right direction. Not sure how to distribute the points though...I might split them between ya.

Alf

Not really with you, Alf, but SString should indeed be allocated in the calling function otherwise it could be clobbered by the next thing to be pushed on the stack after the function returns. EDX:EAX should point to it when the function returns (assuming you are talking 32-bit Intel).

> EDX:EAX should point to it when the function returns (assuming you are talking 32-bit Intel).

I mean 64 bit - doh.

Read EAX for 32-bit.

Were you hoping/expecting the SString object to be returned entirely in registers?

Well, as I found out it wasn't a problem with gcc at all.

The problem is with gdb.

gcc see the following declaration.

SString SomeClass::func(...params)

and internally in gcc this is translated to:

void func(SString * returnvalue, SomeClass * const this, ....params)

This function is written along these lines:

SString SomeClass::func(...params)
{
     SString contact;
     SString host;

    ....some code here...
   return contact;
}

Now. since the compiler translates the return to be a hidden argument, and the contact parameter is used as return value, you don't really need it - just use *returnvalue instead, right?

So the compiler essentially let 'contact' silently disappear although it tells the debugger that 'contact' is the return value, so the declaration is like this:

void func(SString contact, SomeClass * const this, ...params)

And here is a bug or misunderstanding between gcc and gdb. gcc are aware that this is really a pointer to a string and generates code for that, so it correctly loads returnvalue which holds the address of contact, thus gcc treat the function declaration as if it was:

void func(SString & contact, SomeClass * const this, ...params);

but somehow gdb get this wrong and thinks that the declaration is:

void func(SString & contact, SomeClass * const this, ...params);

and so when I want to dump the contents of contact I see that contact.M_str is some address. This is really the address of contact but gdb appear to get a level of indirection wrong.

since I got the wrong value in gdb I assumed first that it was a bug in the compiler and so I posted the question here.

It is really just a bug in gdb and it doesn't know how to print the value correctly, so I just ignore it There's no work-around needed.

Kinda hard though to get it right I guess, since contact is declared as a SString so gdb really have to see it that way, it's just that where SString is located is not at EBP+8 but it is that EBP+8 contain a pointer to it. Appearantly gdb is unable to handle that situation. It could be fixed by having gdb see the type of contact to be a reference to SString but that would confuse most users who would then see that they declare contact as a SString and gdb report it as SString &.

Best way would be to just report the type as 'SString' but internally know that the actual type is really 'SString *' or 'SString &', but this is hidden from user.

However, as it is a gdb bug I don't really worry about it any more.

Alf

Salte,
Your code is still going to have a problem with snull not being initialized before it gets used when you have any global or static member SString objects.

Well, snull is initialized before it gets used - I am very sure of that ;)

It was hard work to ensure that and it probably would be better to use the STL method of having an object that doesn't
require constructor at all so if I were to write the code over again I won't do it the way I did.

However, the snull constructor is the first user-level constructor called - It has the lowest priority number (gcc call constructors with lower priority number before any other and those without any explicit priority get a high value so they are called late).

All my key declarations have such priorities attached to them and have to have that, snull is just one of them.

The reason is that I have to have very exact sequence on when things from different compilation modules are constructed so I have the __attribute__ ( __priority__( ....) ); on several of my declarations.

It was a pain to type all that in but it's done and it works so I am not going to change that in the near future.

And I have lots of global and static SString objects but they are all constructed after snull.

Alf

I admit that I would probably have written the code differently today using other ways to achieve the same result but the code is written and it works so I won't bother with it.

Alf

>>The reason is that I have to have very exact sequence on when things from different compilation modules are constructed so I have the __attribute__ ( __priority__( ....) ); on several of my declarations.

Ahh!
You left this out, so I wasn't aware of it.  Actually I didn't even know that GCC had that feature.

It does and it's handy but it of course makes the code non-portable.

Fortunately, all the priority declarations are placed in some macros so it's not a big deal to write it for a new system that uses slightly different syntax or which doesn't allow for priority (although in the latter case the code will have serious problems to run).

And about leaving out things. Yes, I have left out much of the code which I considered irrelevant for the problem at hand.

The problem was that I did

p contact

in gdb and got a value which was "garbage" and I so I started to check the assembly code and found that the compiler treat the value as a pointer to SString and not as an SString as I had expected it to. At first I misunderstood this and thought that it did a transfer by value but that wasn't the case at all. What was the case was that it simply left out the declaration since it is only used to build a return value which is then returned. Since the return value is reached through the data space given by the function call it makes sense.

I also think I know why it uses a separate temporary space and not a pointer to the SString variable I store the return value into. The return value is of course an object which isn't constructed while the object receiving the return value is already constructed. So it cannot give a pointer to that, instead it build a temporary object in caller's stack frame, provide a pointer to it. Then the function construct an SString in that object and then the caller can copy the SString built there into the variable I have declared for it by a copy constructor it then call a destructor for the temporary object (callee construct it and caller destroys it).

Oh well, case is closed for my part in the sense that I found that it is simply an error in the way gdb display the value - not in the way gcc handle it. The only thing left is how to distribute points. I sort of solved it myself but I did get some valuable input from various people so I will probably split the points to some posters here ;)

Alf

Repeat after me:

   gdb cannot be trusted
   gdb cannot be trusted
....

The quality of gdb doesn't come close to the quality of gcc/g++.

Gary

I sort of knew that already. It's not that long ago that I read an article where the gcc developers had slammed gdb for lacking vital functionality for supporting a language such as C++. For example scoping, namespaces etc have horrible support in gdb. Every time I try to do a

p foo::bar

and get that there is no 'bar' defined anywhere when I know very well that there is a static member bar defined in class foo, or a member bar defined in namespace foo etc...

So, I sort of knew that already. It does surprise me that it cannot even handle this properly.

I guess nothing much is done with gdb in the last decade because nobody wants to say "I am working on gdb", it will just cause them to get yelled at since gdb is so bad, it's not much to be proud of so to speak.

What alternatives exist for gcc under linux?

Alf

Alternatives to gcc on Linux:  Perl, Python, Java, etc.

Or were you expecting a serious answer?  There's probably an Intel compiler for Linux, but I don't know of any alternative to gdb.

Gary

I don't need alternatives to gcc, that's just fine... it's alternatives to gdb I was asking for...

Perl is just fine, Java too but not for the projects I use now. I don't have much experience with Python although I know the basics features of the language (indentation determine block level). It's essentially enough to make me get shivers... ;)

Alf

>>What alternatives exist for gcc under linux?
The alternative is to have a good  debug logger.

I goofed and said:
>> What alternatives exist for gcc under linux?

OOops, I just realize that the cause of the misunderstanding is my own.

I meant to write:

What alternatives to gdb exist under Linux.

That was just a screw-up in my brain there I guess... I never wanted alternatives to gcc, gcc is just fine ;)

It's gdb that is the problem.

Sorry about that.

Alf

> What alternatives to gdb exist under Linux

Being infallible? ;-)

Getting gcc's assembler listing with source code comments is handy.

e.g.

   gcc -Wa,-ahls=MyModule.lst -c -g -o MyModule.o MyModule.cpp

Dan,

Probably because it just didn't triggered in my brain at the time.

I saw the disassembly via gdb and saw that it loaded [EBP+8] and that should have triggered as you say. It just didn't. I was fairly tired, been working all weekend to get something fixed by today (most of the things seems to be ok now, but I still have some testing to do before I am all set so I am kinda behind schedule). Anyway, I did eventually stop and think over
that odd offset and thus found the solution, I just didn't do it immediately and it did take me a while before I did.

I just got shocked when I saw the very wrong value in the SString variable and then it was returned... and I just never came to examine the returned string to see that it was actually ok.

Ok, so I goofed. Should I just go and shoot myself and get it over with? For those of you who've read Douglas Adams you might recognize the line: Should I stand in a corner and rust or just fall apart where I'm standing? (That was one of Marvin's famous lines)

No, don't worry, I have no immediate plans for suicide just because I goofed in a debugging session.

Alf

Salte,
Just out of curiousity, why didn't you just derive your class from std::string, at let it do the reference counting work?

Hey let's all jump on Salte! :)

After I posted, I realized how much we depend on our tools.  If it is hard to saw through a piece of wood with a new handsaw, our first thought is that the wood is extra hard, not that the sawblade is dull.

I recommend using Microsoft tools for all projects.  That is becasue they have been tested by millions of really grouchy programmers.  Who can one hold responsible when some "free" debugger upchucks garbage?

Dan,

I doubt that MS tools will run on this linux machine.....

Alf

Well, but that still uses gdb as debugger on linux and it is gdb that is the problem here. I use 'make' when I compile the program so command line options are never a problem.

Alf

This question has been classified as abandoned.  I will make a recommendation to the moderators on its resolution in approximately one week.  I would appreciate any comments by the experts that would help me in making a recommendation.

It is assumed that any participant not responding to this request is no longer interested in its final deposition.

If the asker does not know how to close the question, the options are here:
http://www.experts-exchange.com/help.jsp#hs5

Tinchos
EE Cleanup Volunteer

Axter,

> So I created an Add-In for VC++ 6.0

Have you written a full description of what you did somewhere or other? This sounds interesting.  Sorry to pick up on this, just as tinchos is classifying the question as abandoned, but I missed your comment.