Author Topic: const char* issue??  (Read 276 times)

Robert

  • Full Member
  • ***
  • Posts: 157
    • View Profile
Re: const char* issue??
« Reply #15 on: February 10, 2020, 04:01:49 PM »

What I really have been concerned about can be seen in your source code for BC9 Afx. For example, in the LEFT$ function you have changed the parameter data type to const char * and the inside the function you cast the related arguments to char *. Really James!  W.T.F. are you doing there?

I absolutely do not want to patch up code in that manner because it is found later that it doesn't work correctly. I think a good guide would be Pelle's C use on const char * in the parameters of string functions. This will take some time and care to get right.

And the congregation says, "AMEN"

James - I don't understand why you're even bothering with BCX when BC9 and C++ are clearly your focus. 
Maybe I'm missing something obvious.

I agree, I would like to see more stuff in BC9 like this

Code: [Select]

    IF UseCpphdr And Not Use_TCLib THEN
    Prepend FPRINT FP_WRITE,
      "int instr(std::string mane,std::string match,int offset,int sensflag)"
      "{"
      "  char* m1;"
      "  char* m2;"
      "  m1 = (char*)mane.c_str();"
      "  m2 = (char*)match.c_str();"
      "  return instr(m1,m2,offset,sensflag);"
      "}"
    End Prepend
    End If


Clean it up. Define m1 and m2 as proper C++ data types so you don't have to cast from match.c_str(). It's obvious, use the proper data type in the first place. Get a couple of the functions figured out in pure C++ and the rest will be easy. Concentrate on it then the rest will be a piece of cake. That will be impressive. Half assed neither here nor there is not going to do anything for anyone.

BC9 BASIC to C++. PURE C++.

Make more all C++. Stop screwing around with trying to make C/C++ incompatibles compatible. Both will turn around and bite you. You know this.

Robert

  • Full Member
  • ***
  • Posts: 157
    • View Profile
Re: const char* issue??
« Reply #16 on: February 10, 2020, 04:36:44 PM »

What I really have been concerned about can be seen in your source code for BC9 Afx. For example, in the LEFT$ function you have changed the parameter data type to const char * and the inside the function you cast the related arguments to char *. Really James!  W.T.F. are you doing there?

I absolutely do not want to patch up code in that manner because it is found later that it doesn't work correctly. I think a good guide would be Pelle's C use on const char * in the parameters of string functions. This will take some time and care to get right.

And the congregation says, "AMEN"

James - I don't understand why you're even bothering with BCX when BC9 and C++ are clearly your focus. 
Maybe I'm missing something obvious.

Maybe James is looking for the answer to a question he doesn't know how to ask?

Here's a possible answer to an unasked question

Modifying C++ string literals

Because string literals (not including std::string literals) are constants, trying to modify them—for example, str[2] = 'A'—causes a compiler error.

jcfuller

  • Jr. Member
  • **
  • Posts: 56
    • View Profile
Re: const char* issue??
« Reply #17 on: February 11, 2020, 06:22:48 AM »
I was going to update bc9 but the source is such a mess I gave up.
Then along comes Mr Bcx with an (almost) new translator that will compile without warnings with vc++ 2019.
Mr Bcx at the start seemed way more tolerant of c++ ideas than in the past but I guess I pushed a little to far. Sorry Kevin.
I am thinking of a new fork "Valencia Basic 9" VB9. Do you think I can get away with that?

James


MrBcx

  • Administrator
  • Full Member
  • *****
  • Posts: 218
    • View Profile
Re: const char* issue??
« Reply #18 on: February 11, 2020, 08:13:14 AM »
I was going to update bc9 but the source is such a mess I gave up.
Then along comes Mr Bcx with an (almost) new translator that will compile without warnings with vc++ 2019.
Mr Bcx at the start seemed way more tolerant of c++ ideas than in the past but I guess I pushed a little to far. Sorry Kevin.
I am thinking of a new fork "Valencia Basic 9" VB9. Do you think I can get away with that?

James

James,

* You'll get lots of web hits from the VB crowd but you better keep your
head down because the torch and pitchfork clan will be after you in no time.

* Since the revival of the BCX website in Nov 2019 ( Thanks Jeff !!), my
contributions to BCX have been trivial compared to all the changes that were
made during 2005 - 2019 period when I was mostly a lurker.

* When I open sourced BCX in 2004, I knew there would be changes made
that would not always be to my liking (C++ horseshit springs to mind) but I
always knew BCX would be better for it and it mostly is. 

I love using BCX -- maintaining BCX, not so much.


jcfuller

  • Jr. Member
  • **
  • Posts: 56
    • View Profile
Re: const char* issue??
« Reply #19 on: February 11, 2020, 08:22:47 AM »
Kevin,
  You've done a marvelous job cleaning up the code and putting up with my (distasteful c++) requests  ;D. for that I thank you.

James

Robert

  • Full Member
  • ***
  • Posts: 157
    • View Profile
Re: const char* issue??
« Reply #20 on: February 12, 2020, 06:31:00 PM »

What I really have been concerned about can be seen in your source code for BC9 Afx. For example, in the LEFT$ function you have changed the parameter data type to const char * and the inside the function you cast the related arguments to char *. Really James!  W.T.F. are you doing there?

I absolutely do not want to patch up code in that manner because it is found later that it doesn't work correctly. I think a good guide would be Pelle's C use on const char * in the parameters of string functions. This will take some time and care to get right.

And the congregation says, "AMEN"

James - I don't understand why you're even bothering with BCX when BC9 and C++ are clearly your focus. 
Maybe I'm missing something obvious.

I agree, I would like to see more stuff in BC9 like this

Code: [Select]

    IF UseCpphdr And Not Use_TCLib THEN
    Prepend FPRINT FP_WRITE,
      "int instr(std::string mane,std::string match,int offset,int sensflag)"
      "{"
      "  char* m1;"
      "  char* m2;"
      "  m1 = (char*)mane.c_str();"
      "  m2 = (char*)match.c_str();"
      "  return instr(m1,m2,offset,sensflag);"
      "}"
    End Prepend
    End If


Clean it up. Define m1 and m2 as proper C++ data types so you don't have to cast from match.c_str(). It's obvious, use the proper data type in the first place. Get a couple of the functions figured out in pure C++ and the rest will be easy. Concentrate on it then the rest will be a piece of cake. That will be impressive. Half assed neither here nor there is not going to do anything for anyone.

BC9 BASIC to C++. PURE C++.

Make more all C++. Stop screwing around with trying to make C/C++ incompatibles compatible. Both will turn around and bite you. You know this.

Hi James:

I, and I am sure many others, instead of this

Code: [Select]

int instr(std::string mane, std::string match, int offset, int sensflag)
{
    char* m1;
    char* m2;
    m1 = (char*)mane.c_str();
    m2 = (char*)match.c_str();
    return instr(m1, m2, offset, sensflag);
}
int instr(const char* mane, const char* match, int offset, int sensflag)
{
    char *s;
    if (!mane || !match || ! *match || offset > (int)strlen(mane)) return 0;
    if (sensflag)
        s = _stristr_(offset > 0 ? (char*)mane + offset - 1 : (char*)mane, (char*)match);
    else
        s = _strstr_(offset > 0 ? (char*)mane + offset - 1 : (char*)mane, (char*)match);
    return s ? (int)(s - mane) + 1 : 0;
}



would like to see more, please, whether in VB9 or perhaps Boost BASIC, like this
Note: In the code below, the line "return found + 1;" has been edited from "return found;"
Code: [Select]

int instr(std::string mane, std::string match, int offset, int sensflag)
{
 if (sensflag) {
  transform(mane.begin(), mane.end(), mane.begin(), ::tolower);
  transform(match.begin(), match.end(), match.begin(), ::tolower);
 }
  size_t found = mane.find(match);
 if (found != string::npos)
  return found + 1;
 else
  return 0;
}


The dependencies prototype list goes from this

Code: [Select]

// *************************************************
//               Standard Prototypes
// *************************************************

char*   BCX_TmpStr(size_t, size_t = 0, int = 1);
char*   lcase (const char*);
stdstr lcase(stdstr &, int = 0);
charT lower(charT arg)
{
    return std::use_facet<std::ctype<charT> >(std::locale()).tolower(arg);
}
char*   _strupr_(char *);
char*   _strlwr_(char *);
int     instr(const char*, const char*, int = 0, int = 0);//
int     instr(std::string, std::string, int = 0, int = 0);
char    *MakeLCaseTbl(void);
char    *_stristr_(char*, char*);
char    *_strstr_(char*, char*);


to this

Code: [Select]

int     instr(std::string, std::string, int = 0, int = 0);


No dependencies. STAND ALONE C++ code. No "char *" or "const char *" bitching about the others existence.

But you ask, does it work ???

Or is it more, "I'll shove this crap out there and let someone else fix it." code.

MrBCX may want to put on his Anti See PeePee outfit before approaching the wickedness below. Compile as C++ code.

Note: In the code below, the line "return found + 1;" has been edited from "return found;"
Code: [Select]

#include <algorithm>
#include <iostream>

int instr(std::string, std::string, int = 0, int = 0);

int main(int argc, char *argv[])
{
    static int     Position;
    Position = instr("Why waste time learning, when IgNorAnce is instantaneous?", "waste time");
    printf("%d\n", (int)Position);
    Position = instr("Why waste time learning, when IgNorAnce is instantaneous?", "ignorance", 0, 1);
    printf("%d\n", (int)Position);
    return 0;   /* End of main program */
}

int instr(std::string mane, std::string match, int offset, int sensflag)
{
 if (sensflag) {
  transform(mane.begin(), mane.end(), mane.begin(), ::tolower);
  transform(match.begin(), match.end(), match.begin(), ::tolower);
 }
  size_t found = mane.find(match);
 if (found != std::string::npos)
  return found + 1;
 else
  return 0;
}

« Last Edit: February 14, 2020, 07:16:35 PM by Robert »

MrBcx

  • Administrator
  • Full Member
  • *****
  • Posts: 218
    • View Profile
Re: const char* issue??
« Reply #21 on: February 12, 2020, 07:16:28 PM »
Robert -- I donned my C++ hazmat suit before trying any of this.


Robert's example, compiled with G++ as a "C++" program, produced a 92.9k executable

The equivalent BCX program (code below), compiled with G++ as a "C" program, produced a 36.8k executable.

C++ results:
5
5



C results
6
6



Wow ... C++ gives me larger file size AND wrong answers ... SIGN ME UP!
 


Code: [Select]

DIM Position
Position = instr("12345abc67890", "abc")
print Position
Position = instr("12345abc67890", "ABC67", 0, 1)
print Position


Robert

  • Full Member
  • ***
  • Posts: 157
    • View Profile
Re: const char* issue??
« Reply #22 on: February 12, 2020, 07:38:50 PM »
Robert -- I donned my C++ hazmat suit before trying any of this.


Robert's example, compiled with G++ as a "C++" program, produced a 92.9k executable

The equivalent BCX program (code below), compiled with G++ as a "C" program, produced a 36.8k executable.

C++ results:
5
5



C results
6
6



Wow ... C++ gives me larger file size AND wrong answers ... SIGN ME UP!
 


Code: [Select]

DIM Position
Position = instr("12345abc67890", "abc")
print Position
Position = instr("12345abc67890", "ABC67", 0, 1)
print Position


Just because it's stupid and fat is no reason not to like it.


Robert

  • Full Member
  • ***
  • Posts: 157
    • View Profile
Re: const char* issue??
« Reply #23 on: February 12, 2020, 07:49:27 PM »
Robert -- I donned my C++ hazmat suit before trying any of this.


Robert's example, compiled with G++ as a "C++" program, produced a 92.9k executable

The equivalent BCX program (code below), compiled with G++ as a "C" program, produced a 36.8k executable.

C++ results:
5
5



C results
6
6



Wow ... C++ gives me larger file size AND wrong answers ... SIGN ME UP!
 


Code: [Select]

DIM Position
Position = instr("12345abc67890", "abc")
print Position
Position = instr("12345abc67890", "ABC67", 0, 1)
print Position


Just because it's stupid and fat is no reason not to like it.

My compiles are even bigger

VS 2019     x64   136,704
Embarcadero x64   491,615
MinGW       x64   839,680
Nuwen       x64 1,123,840

I guess I had better tune up my batch files.

MrBcx

  • Administrator
  • Full Member
  • *****
  • Posts: 218
    • View Profile
Re: const char* issue??
« Reply #24 on: February 12, 2020, 08:01:46 PM »

Just because it's stupid and fat is no reason not to like it.


I've read that tag line somewhere ...   :)


Robert

  • Full Member
  • ***
  • Posts: 157
    • View Profile
Re: const char* issue??
« Reply #25 on: February 12, 2020, 09:08:47 PM »
Stripping my Nuwen batch file down didn't seem to do much so I opened up the Nuwen open_distro_window.bat file and compiled the C++ instr code with

g++ instr.cpp -o instr.exe

and got a 3,305,226 byte instr.exe

I guess we get the whole family and the farm with

<algorithm> and <iostream>

Nothing to be done about that.

It's interesting that Stephan T. Lavavej, a Principal Software Development Engineer at Microsoft, maintaining Visual Studio's C++ Standard Library implementation, has the Boost libary in his MinGW distro and also, yesterday, I saw somewhere that Microsoft was using the Boost math library in some of their product development.

Most Boost libraries are header based, consisting of inline functions and templates, and as such they don't need the whole family and farm and the bloat typically associated with C++ is greatly reduced. But of course it's a whole new learning curve.

C? Si si!

jcfuller

  • Jr. Member
  • **
  • Posts: 56
    • View Profile
Re: const char* issue??
« Reply #26 on: February 13, 2020, 06:22:05 AM »
Robert,
  Thank you for the code.
I am really enamored with Fred's string class. Before I got lost searching for the center of the Universe I was using it as my primary string. One of the nice things I found with std::strings and fred's string class is you don't need the circular buffer for returning a string from a function as done in Bcx/Bc9. It appears(?) the compiler does "whatever" to get that return item into your calling std::string, fstring.
  I believe Patrice has all the PB string functions translated to c++. I think I was going to use them on an update??
  Kevin,
    I thought size didn't matter :)
  I have all the TClib code working with BCX 7.4.4 so if you want tiny you can have it.
The biggest downside with TCLib is there can be no Global Classes.(there are work ways to simulate)
Fred said he was going to add it but  it appears he has way to much to handle on the Colorado homestead.

James

MrBcx

  • Administrator
  • Full Member
  • *****
  • Posts: 218
    • View Profile
Re: const char* issue??
« Reply #27 on: February 13, 2020, 07:39:06 AM »