next topic »

[Reply #15 on:]

I knew machines (were they called computer in those days ?) with word sizes of 12 or 36 bit !

A byte being 8 bit is common sense,
uint16_t is known by rather basic include files to "all" c compilers to get rid of that annoying uncertainly what an int is, when it matters.

But  word = uint16_t and dword = uint32_t, might be something you do not need to follow, if you don't want to.

[Reply #16 on:]

I do believe that the term word as used in computing originated before Gates was in business.

It's size is not obvious, though. int, long, byte, float, double, all have easily remembered sizes. word is some vague typedef'd mess that never should have been allowed. It's far too vague.

[Reply #17 on:]

A word is not shit. In programming terms, it is a group of bytes. On my Windows Programmer's Calculator, there is an option to choose the [signed] number size in bytes:
1) Byte (8 bits)
2) Word (16 bits)
3) Dword (32 bits)
4) Qword (64 bits)
In Arduino, it is a short term for unsigned int. http://arduino.cc/en/Reference/Word.
I like using words.

[Reply #18 on:]

I'm a bit more hardware oriented. Word length means a different thing to me. It was DEC who had the 12-bit words, either 4 too many or 4 too few.

[Reply #19 on:]

So, do you think that I should just give up on VectorString? Would it be better to have 3 String/string/VectorString objects, or 3 char arrays with 50 character space allocation each? I still want to know what is preventing my VectorString::getString() function from returning a string printable to the Serial Monitor.

[Reply #20 on:]

Would it be better to have 3 String/string/VectorString objects, or 3 char arrays with 50 character space allocation each?

If you need 3 texts, each max 50 characters wide, and you have the RAM space available, 3 char arrays definitely is the way to go.
If during run time, one text shrinks considerably while another one grows, and you are low by about 50 bytes of RAM, I'd think about the worst cases and probably anything else isn't a solution either

I still want to know what is preventing my VectorString::getString() function from returning a string printable to the Serial Monitor.

That's a valid reason not to give up.

[Reply #21 on:]

I still want to know what is preventing my VectorString::getString() function from returning a string printable to the Serial Monitor.

Are you referring to this code?

Code:

char* VectorString::getString(){
  const word vecSize = vec.size();
  char buf[vecSize] = "\0";
  for(word i = 0; i < vecSize; i++) buf[i] = vec[i];
  return buf;
}

If so, it's already been explained why that does not work. You are returning a pointer to space on the heap. As soon as the function ends, that heap space is reclaimed, and your pointer now points to garbage.

[Reply #22 on:]

You are returning a pointer to space on the heap

heap sp. "stack"

[Reply #23 on:]

heap sp. "stack"

OK. I'll try to keep them straight.

[Reply #24 on:]

Actually the function is now:

Code:

char* VectorString::getString(){
  const word vecSize = vec.size();
  //char* buf;
  char buf[vecSize+1];
  //buf = (char*)malloc(sizeof(char)*vecSize+1);
  for(word i = 0; i < vecSize; i++) buf[i] = vec[i];
  buf[vecSize] = '\0';
  return (char*)buf;
}

I forgot to change it. It still returns nothing.

[Reply #25 on:]

Actually the function is now:

You haven't changed the fundamental fact that the array you are returning a pointer to is allocated on the stack. When the function ends, the stack is unwound, and there goes your data, down the drain.

You could call malloc() to allocate space on the heap, instead, and return a pointer to that space. You need to be sure to free() it when done with it.

[Reply #26 on:]

Or you can allocate a buffer as part of the Vector class but WTH, you'll probably use a freaking String and then wonder why your sketch crashes later.

[Reply #27 on:]

You need to be sure to free() it when done with it.

You need to be sure that free() does not have bugs in it, which I am not sure of in the current IDE release.

[Reply #28 on:]

I found an c++ example in a book that includes functions that return char arrays. I have omitted the irrelevant parts:

Code:

class CArgNode
{
  private:
    char szCommand[255], szParameter[255];
    //...
  public:
    //...
    char * GetCommand();
};
char* CArgNode::GetCommand()
{
return (char*)this->szCommand;
}

A string is strcpy'd to szCommand in the constructor.

One thing I notice that is different for my function is that the char array that it returns is a class variable.

You could call malloc() to allocate space on the heap, instead, and return a pointer to that space. You need to be sure to free() it when done with it.

How would I do that? Do I have to use free() outside of the function?

If you need 3 texts, each max 50 characters wide, and you have the RAM space available, 3 char arrays definitely is the way to go.

What if the length of the strings can be anywhere from 4 to 50 characters?

[Reply #29 on:]

If you need 3 texts, each max 50 characters wide, and you have the RAM space available, 3 char arrays definitely is the way to go.

What if the length of the strings can be anywhere from 4 to 50 characters?

You make space for as many characters as the string might possibly get to, and for good engineering you control the length of the strings to what you need.

Sometimes the thing to do is make one Big Buffer for all your strings and set a pointer for each within, but again you must control memory use especially when memory is very limited. Find a programming book that mentions that any more! It will likely be old or about MCU programming. Sorry but you're not in Kansas any more.