1st post by 1st time C coder

Hello! I'm Servo Wizard.

I'm an accomplished VB6 programmer who is attempting to learn the C-C++ programming language. This project is my very first DLL and it is also the extent of my C programming experience. I proto-typed the functions in a console project and then moved on to the DLL.

1st major obstacle was figuring out how to return something that VB could digest. There was no way that I know of to export 21 digits other than a string. After 3 days of extensive research I learned how to export a string that VB would accept.

OK! End of 1st major obstacle, start of 2nd MAJOR OBSTACLE. When called from VB app it returns a string of 21 digits, all being the correct value when split into 7 individual values. I'm calling the DLL from a timer sub in VB and I noticed that the values were not varying as they occasionally should. It did not take to long to find that my string of 21 digits returned as 42 digits, 84 digits, 168 digits and so on until the MS error message arrived. It's quite obvious that the DLL does not close between calls.

I have spent the entire Labor day weekend trying to learn how to erase, free or whatever method is used to unload the 2 arrays in my DLL so as to prevent the compounding of the export string. Now, I sure that I have looked right at the solution several times but did not recognize it due to my inexperience with the C language.

It's not my style to have some one else do my learning and thinking for me but I would really appreciate some help with this problem.

Servo

Code:

---

#include "myheader.h"

char NxtBt[22];
char Bytes[22];

int  Something;

HANDLE h;

BOOL APIENTRY DllMain
(
HANDLE hModule,
DWORD  ul_reason_for_call,
LPVOID lpReserved
)

{
return TRUE;
}

BSTR __stdcall This()
{
if(Something)
  {
  strcat(Bytes, "0");
  }
  itoa(_inp(Blank),NxtBt,10); // decimal value of 4Bh as string "075"
  strcat(Bytes,NxtBt); // array[0]="075"

// repeats the following conditional 5 times with different value (Blank) each time.

  if(_inp(Blank)<100)
    {
    strcat(Bytes, "0");
    }
    itoa(_inp(Blank),NxtBt,10);
    strcat(Bytes,NxtBt); // Bytes[0-2]="075";Bytes[3-5]="0??" ; and so on to Bytes[18-21]="0??"
  }
return SysAllocString((OLECHAR*)Bytes);
SysFreeString((OLECHAR*)Bytes);
}

---

Some seemingly random code attempting to make a point:

Code:

---

#include <stdio.h>

void foo(int *array, size_t size)
{
  char text[22];
  size_t i, j = 0;
  for ( i = 0; i < size; ++i )
  {
      j += sprintf(&text[j], "&#37;03d", array[i]);
  }
  puts(text);
}

int main(void)
{
  int a[] = {0x4B,1,2,3,4,5,6}, b[] = {1,2,3,4,5,6,7};
  foo(a, sizeof a / sizeof *a);
  foo(b, sizeof b / sizeof *b);
  return 0;
}

/* my output
075001002003004005006
001002003004005006007
*/

---

Basically I think I'm saying there sounds like an issue with concatenation.

Quote:

---

Basically I think I'm saying there sounds like an issue with concatenation.

---

Dave,

Yes, I agree with your synopsis. One of most troubling aspects of C-C++ is the lack of a String type, or my lack of knowledge there of.

The word string occurs in many C-C++ articles, but I sure don't see the ability to perform any of the string manipulations <string.h> with a 'string'.

That stated, I realize that VB was wrote in C language so if VB has a String type then C must have the ability to create a String.

If your code sample equates to a String function then once again I'm missing the point, but like a dog with a bone, I won't let go of it until I've ate all of it, or choked on it.

Again, thanks for your effort.

Servo

I think I was merely recommending to tack a different way in regard to your string creation using C-style arrays. My implementation is not quite the same as yours, so I went a standard route.

Please don't say "C-C++" there are two distinct languages, C and C++ (use a slash instead of a hyphen).
btw What you have written is entirely C language code, no C++ at all.

Don't use a variable with the same name as the function please.

First bug is using strcat on an uninitialised variable. Use strcpy(Blank, "0"); instead.
Second bug: SysFreeString wont do anything if you put it after the return statement because the function exits before reaching that.
Third bug: Don't just cast a char* to an OLECHAR* they are not the same. You may need to switch to WCHAR or TCHAR instead.

This part confuses me:

Code:

---

BSTR __stdcall Blank()
{
if(Blank)
  {
  strcat(Bytes, "0");
  }
  itoa(_inp(Blank),NxtBt,10); // decimal value of 4Bh as string "075"
  strcat(Bytes,NxtBt); // array[0]="075"

---

You have a function called Blank, then you do "if(Blank)" which essentially takes teh address of the function and says "if it's not zero, perform the following code". Since Blank is a function, it won't EVER be zero, so you could just as well not have the if-statement.

Then you do _inp(Blank) - what's this supposed to do, again it uses the address of the function to do something - not sure where 4B comes into it...

Note that when referring to symbols, the symbol that is closest (in an "going outwards") will be the one used, so the integer variable called Blank further out isn't the one used by the compiler.

--
Mats

C++ does have a string class.

http://www.cprogramming.com/tutorial/string.html

Kernel,

Thanks for your input. After 6 hours of sleep for the 1st time in 3 days I can now see how the example code could be confusing. I'll try it again.

Code:

---

BSTR __stdcall This()
{
if(Something)
  {
  strcat(Bytes, "0");
  }
  itoa(_inp(Blank),NxtBt,10); // decimal value of 4Bh as string "075"
  strcat(Bytes,NxtBt); // array[0]="075"

---

Servo

You need to initialize Bytes before you strcat to it. Either use strcpy(bytes, "") before the first strcat, or use strcpy(bytes, "0"); else strcpy(bytes, "");

--
Mats

Kernel,

Yes you're right, strcpy would have been a better choice for first use of the variable, but it works with strcat. I think that iMalc might have explained why my returned string is compounding but I have yet to figure out how to correct it. I learned VB the same way that I'm attempting to learn C, the internet is worlds best text book. I rarely beg for help but I'm really jammed up tight on this problem.

Servo

It works because the variable is initialized to zero before the first use - but if you call the function again, it will add the zero at the end of the previous string - do this a few times and you start overwriting the next string, etc, etc.

--
Mats

Quote:

---

Originally Posted by Servo Wizard

I learned VB the same way that I'm attempting to learn C, the internet is worlds best text book.

---

Usually yes, but remember not to be unfair but there are a lot of unqualified people who find it "fun" to write tutorials which may not be to the standard of a well written book - by a well regarded publisher, K&R for example.

But it is true the internet is often the most convenient for reference.

Quote:

---

Originally Posted by xp5

I'm reading this programming book and it gives a sample code:

Code:

---

int get_maxpos(int x[], int eff_size)
{
  int i, maxpos = 0;

  for (i = 0; i < eff_size; i++)
    maxpos = x[i] > x[maxpos] ? i: maxpos;
  return maxpos;

}

---

---

Books can also be badly written. Who in their right mind reccomends leaving out braces in a for loop? /me shakes head sadly

QuantumPete

Quote:

---

Originally Posted by QuantumPete

Books can also be badly written. Who in their right mind reccomends leaving out braces in a for loop? /me shakes head sadly

QuantumPete

---

There's nothing wrong with that...

Quote:

---

Originally Posted by zacs7

There's nothing wrong with that...

---

Just because the language supports it, doesn't mean it should be done!

Code:

---

if (false == result)
    action_on_false (arg1, arg2);

---

Then you want to print an error message as well:

Code:

---

if (false == result)
  printf ("result is false\n");
  action_on_false (arg1, arg2);

---

Now action_on_false will always be executed and it's a hard bug to spot if result *usually* is false (such as when you're checking the return code of fopen). Defensive programming saves hours of debugging!

It's not that hard to spot, in some cases it can improve readability, consider:

Say I wanted to fill each dimension of 'x' with '10'.

Code:

---

#define DIM 5
/* ... */

int x[DIM][DIM][DIM][DIM];
int a, b, c, d;

for(a = 0; a < DIM; a++)
    for(b = 0; b < DIM; b++)
        for(c = 0; c < DIM; c++)
            for(d = 0; d < DIM; d++)
                x[a][b][c][d] = 10;

/* OR */

for(a = 0; a < DIM; a++)
{
    for(b = 0; b < DIM; b++)
    {
        for(c = 0; c < DIM; c++)
        {
            for(d = 0; d < DIM; d++)
            {
                x[a][b][c][d] = 10;
            }
        }
    }
}

---

It's just an example, there are easier ways to fill that array ;)

Anyway it proves to be more compact and I'd say is readable at a first glance, not to mention the potential bug of leaving off a closing brace (and accidentally closing it later).

My point is, the author has done nothing wrong - it really comes into coding style, after all that's what tab-indenting is really supposed to help solve. Plus you should be able to recognize that if there is no braces the first statement after will be run, (keep going until you find a ';').

Quote:

---

Plus you should be able to recognize that if there is no braces the first statement after will be run, (keep going until you find a ';').

---

I can, I'm saying it's a bad thing to teach a beginner. Make it easy for beginners, use braces for all if and for loops, put parantheses around everything. When they get more advanced, they can play it fast and loose ;)

QuantumPete

I agree if he doesn't explain it in depth then it's bad, making assumptions are generally bad :)

Quote:

---

Originally Posted by iMalc

First bug is using strcat on an uninitialised variable. Use strcpy(Blank, "0"); instead.

---

Actually, Bytes is a global variable. Global arrays are automatically initialized to all zeros. This means that the first time this function is called, it will work as expected; but subsequent calls to it would cause a buffer overrun.

The simplest thing to do, of course, is to replace the first strcat() with strcpy().

Hey Guys!

Remember me? I'm the guy that originally posted for help. Well I figured it out on my own. The solution was so simple that I have to wonder about those whom replied.

In case you have forgot, the problem was that after the first return the string would begin to compound in length by the strlen.

OK, granted my defaced code wasn't to cool, but you all clearly picked up on the use of strcat() so you knew that I was building an array of chars for the purpose of returning a string.

That stated, the two that suggested replacing strcat() with strcpy() weren't too sharp because the variable would have only contain the last copied content.

All that it took to solve my problem was:

Code:

---

BSTR GetIOReadings()
{
if(strlen(Bytes)>2)
  {
  SysFreeString((OLECHAR*)Bytes);
  }
strcpy(Bytes,"0");

---

Servo

There's no need to insult anyone. They were trying to help you, and they certainly weren't obligated to do so. There's a chance that the people in this thread won't feel like helping you in the future.

Quote:

---

That stated, the two that suggested replacing strcat() with strcpy() weren't too sharp because the variable would have only contain the last copied content.

---

Besides the tone, didn't you do just that in your final code? I see a strcpy(), not a strcat().

Code:

---

BSTR GetIOReadings()
{
if(strlen(Bytes)>2)
  {
  SysFreeString((OLECHAR*)Bytes);
  }
strcpy(Bytes,"0");

---

So, if the length of Bytes is more than two, you free the data allocated by Bytes, and then proceed to assign a value to the memory? You're overwriting memory that has been freed. This is an exceedingly bad idea. You'll likely get segmentation faults and random buffer overruns and other annoying bugs.

That's assuming that Bytes was dynamically allocated in the first place. If it's declared like this, then you have even bigger problems.

Code:

---

char Bytes[22];

---

Arrays aren't meant to be freed by the program.

Your indentation's not the best, either. It could use some working on.

Plus you're missing a closing curly brace, }. :)

dwks,

There's more to the code then what I illustrated. There are seven occurances of strcat() in the code below where I copied. As I stated, replacing strcat() with strcpy() would not work due to the previosly mentioned reason.

Believe me, the driver, dll and debug program all work, but iIf you need additional proof then I will attach a copy of the compiled driver, dll, and the debug.exe program.

Servo

No, if you think it works, than that's all that matters. :)