Author Topic: FYI formatting not a BUG  (Read 185 times)

jcfuller

  • Full Member
  • ***
  • Posts: 167
    • View Profile
FYI formatting not a BUG
« on: August 05, 2020, 12:22:33 PM »
Kevin,

Re: Ongoing improvements to the c\c++ output file formatting.
Just a FYI on why I run astyle against all the c++ translations.

James

BCX 7.5.2

This is the C03 c++ example with
$CCODE CONST
using namespace std;
$CCODE


This code cannot not parsed with ULEX.
Code: [Select]
int main ()
{
  int      a={0};
  char     s[100]={0};
  cout<<"This is a sample program."<<endl;
  cout<<endl;
  cout<<"Type your age : ";
  cin>>a;
  cout<<"Type your name: ";
  cin>>s;
  cout<<endl;
  cout<<"Hello "<<s<<" you're "<<a<<" years old."<<endl;
  cout<<endl<<endl<<"Bye!"<<endl;
  Pause();
  return EXIT_SUCCESS;
  return 0;
}



This is the code after ASTYLE has a go at it:

Code: [Select]
int main ()
{
    int      a = {0};
    char     s[100] = {0};
    cout << "This is a sample program." << endl;
    cout << endl;
    cout << "Type your age : ";
    cin >> a;
    cout << "Type your name: ";
    cin >> s;
    cout << endl;
    cout << "Hello " << s << " you're " << a << " years old." << endl;
    cout << endl << endl << "Bye!" << endl;
    Pause();
    return EXIT_SUCCESS;
    return 0;
}


MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 538
    • View Profile
Re: FYI formatting not a BUG
« Reply #1 on: August 05, 2020, 02:59:52 PM »
JC -- Two things:

1) Your version of C03.bas is not the same as what's in the current Help File.  Specifically the std::cout << thing.

2) the following code has existed in BCX for a while now and produces output that closely matches ASTYLE.  If you want to add some similar lines to the code below that would lend themselves to ULEX, I would not be opposed to including it in a future version of BCX, so long as nothing breaks.

Code: [Select]

   '***************************************************
      ' Simple patch to support Unicode Lexer (ULEX.exe)
      '***************************************************
      REPLACE "<<std::"  WITH " << std::"  IN LTmp1$
      REPLACE "::cout<<" WITH "::cout << " IN LTmp1$
      REPLACE "::cin>>"  WITH "::cin >> "  IN LTmp1$
      REPLACE "cout<<"   WITH "cout << "   IN LTmp1$
      REPLACE "cin<<"    WITH "cin << "    IN LTmp1$
      REPLACE "<<endl"   WITH " << endl"   IN LTmp1$
      '***************************************************


dgarner

  • Newbie
  • *
  • Posts: 23
    • View Profile
Re: FYI formatting not a BUG
« Reply #2 on: August 05, 2020, 03:02:05 PM »
James,

I'm not clear what you are trying to say with this post.

I'm familiar with Astyle.  I've used it with C code.  I really like it, but the output can be configured in lots of ways.  C does not normally care about whitespace and AStyle lets you configure a lot of reformatting aspects.

I'm not a C++ guy (yet?), so is there something special that you are trying to point out?  I would not want BCX to care too much about the generated C or C++ formatting.  To me, It's an intermediate output on the way to an executable file.

If you want to use the C++ code, AStyle is a great tool to make it meet your requirements.

jcfuller

  • Full Member
  • ***
  • Posts: 167
    • View Profile
Re: FYI formatting not a BUG
« Reply #3 on: August 05, 2020, 03:48:49 PM »
Kevin,
  It makes no difference. It is the lack of spacing around the "<<";

In the BCX_revisions.txt file you stated:
Ongoing improvements to the c\c++ output file formatting
I was giving an example. That's why the FYI in case you were looking for examples.

I use ASTYLE so it's not an issue for me.

David,
   The utility ULEX (Ian & Wayne) that I use to create Unicode source needs the spacing.
   I refer you to Roberts Post.
https://bcxbasiccoders.com/smf/index.php?topic=254.msg1048#msg1048
   

James

MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 538
    • View Profile
Re: FYI formatting not a BUG
« Reply #4 on: August 05, 2020, 04:35:44 PM »
JC -- I understand.

I also realized a bit late ( better late than never ) that the code I posted earlier could be reduced
to the following and it would have worked for your version of C03.bas -- less code, proper order.

Code: [Select]

      '***************************************************
      ' Simple patch to support Unicode Lexer (ULEX.exe)
      '***************************************************
      REPLACE "cout<<"   WITH "cout << "   IN LTmp1$
      REPLACE "cin<<"    WITH "cin << "    IN LTmp1$
      REPLACE "<<std::"  WITH " << std::"  IN LTmp1$
      REPLACE "<<endl"   WITH " << endl"   IN LTmp1$
      '***************************************************


dgarner

  • Newbie
  • *
  • Posts: 23
    • View Profile
Re: FYI formatting not a BUG
« Reply #5 on: August 05, 2020, 05:03:43 PM »
James,

Thanks for the clarification.  Evidently, others were already clued into what you were saying, but I was not.

If C++ compilers will accept the output, then I would argue that the utility, ULEX should probably be improved to accept that output as input as well.


jcfuller

  • Full Member
  • ***
  • Posts: 167
    • View Profile
Re: FYI formatting not a BUG
« Reply #6 on: August 05, 2020, 05:15:27 PM »
Kevin,
  Just an FYI.
  Another oddity I found is with ->. Note the space between the var and the -> in some spots:
return v ->boolVal
  and not in others
if((v->vt==VT_BOOL))

All the c++ compilers ignore the space and compile fine??

James

This is from my IDictionary class wrapper


BCX:
Code: [Select]
Function CVariant::ToBool(iElement As Integer) As BOOL
    Raw As VARIANT Ptr v = ElementAt(iElement)
    If (v <> (VARIANT *) NULL) Then
        If (v->vt = VT_BOOL) Then
            Function = v->boolVal
        Else
            Function = FALSE
        End If
    End If
    Function = FALSE
End Function


Translated c++ code

Code: [Select]
BOOL CVariant::ToBool (int iElement)
{
  VARIANT*  v=ElementAt(iElement);
  if((v!=(VARIANT*)NULL))
    {
      if((v->vt==VT_BOOL))
        {
          return v ->boolVal;
        }
      else
        {
          return FALSE;
        }
    }
  return FALSE;
}


MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 538
    • View Profile
Re: FYI formatting not a BUG
« Reply #7 on: August 05, 2020, 05:40:17 PM »
JC,

That's in part the kind of thing that I've been working to improve.  I'm certain I can improve the situation
involving the space between the var and the member operator (->) easily enough. 

During the period of years when I was mostly a lurker in BCX's life, a lot of stuff was happening that I
wasn't particularly interested in or even paying attention too.  One of those things was all the output
formatting that was added.

Most of that is quite helpful but a lot of it just comes across strange and unorthodox.  It's the latter that
makes me and Robert a little bit crazy over and it's the latter that I'm been hacking to slowly improve it.


jcfuller

  • Full Member
  • ***
  • Posts: 167
    • View Profile
Re: FYI formatting not a BUG
« Reply #8 on: August 05, 2020, 07:18:20 PM »
James,

If C++ compilers will accept the output, then I would argue that the utility, ULEX should probably be improved to accept that output as input as well.

David,
  Why? It's not necessary to change ULEX. I have ASTYLE which produces the formatted code.
Did you not have format rules that had to be followed in your professional "c" coding? Does all of the BCX translated code follow those rules?

James


Robert

  • Sr. Member
  • ****
  • Posts: 449
    • View Profile
Re: FYI formatting not a BUG
« Reply #9 on: August 06, 2020, 01:06:30 AM »
JC,

That's in part the kind of thing that I've been working to improve.  I'm certain I can improve the situation
involving the space between the var and the member operator (->) easily enough. 

During the period of years when I was mostly a lurker in BCX's life, a lot of stuff was happening that I
wasn't particularly interested in or even paying attention too.  One of those things was all the output
formatting that was added.

Most of that is quite helpful but a lot of it just comes across strange and unorthodox.  It's the latter that
makes me and Robert a little bit crazy over and it's the latter that I'm been hacking to slowly improve it.

Hi MrBCX:

I don't know how much attention you were paying when Mike Henning created the C++ and C parsing for those sharp pointy things (->)  (member operator ?) and related stuff but if you are contemplating a quick dirty fix please take the following code into consideration.

The C and C++ translations are significantly different.

Code: [Select]

 DIM Link$
 
 Link$ = Startup_Folder$() + "GnotePad.lnk"
 
 CreateLink("c:\windows\notepad.exe",Link$,"","MS Notepad")
 
 FUNCTION Startup_Folder$()
   DIM A$
   DIM Wshell AS OBJECT
   SET Wshell = CreateObject("Wscript.Shell")
   A$ = Wshell.SpecialFolders("Startup")
   SET Wshell = NOTHING
   FUNCTION = A$ + "\"
 END FUNCTION
 
 FUNCTION CreateLink (Exe$, Link$, Args$, Desc$) AS HRESULT
   DIM hres AS HRESULT
   DIM psl AS IShellLink PTR
   DIM w[MAX_PATH] AS WORD
 
   CoInitialize(NULL)
 
   hres = CoCreateInstance(CLSID_ShellLink, NULL, CLSCTX_INPROC_SERVER, _
                           IID_IShellLink, (LPVOID*)&psl)
 
   IF (SUCCEEDED(hres)) THEN
     DIM ppf AS IPersistFile PTR
     psl->lpVtbl->SetPath(psl, Exe)
     psl->lpVtbl->SetDescription(psl, Desc)
     psl->lpVtbl->SetShowCmd(psl, SW_SHOWMAXIMIZED)
     psl->lpVtbl->SetArguments(psl, Args$ )
     hres = psl->lpVtbl->QueryInterface(psl, IID_IPersistFile, (LPVOID*)&ppf)
     IF (SUCCEEDED(hres)) THEN
       MultiByteToWideChar(CP_ACP, 0, Link, -1, (LPWSTR)w, MAX_PATH)
       hres = ppf->lpVtbl->Save(ppf, (LPCOLESTR)w, TRUE)
       ppf->lpVtbl->Release(ppf)
     END IF
     psl->lpVtbl->Release(psl)
   END IF
 
   CoUninitialize()
   FUNCTION = hres
 END FUNCTION


MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 538
    • View Profile
Re: FYI formatting not a BUG
« Reply #10 on: August 06, 2020, 10:21:00 AM »
Robert,

The code you posted is written for C++. 
To get it to compile on Pelles and Lccwin32, I needed to add the conditional compilation lines shown below.

Code: [Select]

 FUNCTION CreateLink (Exe$, Link$, Args$, Desc$) AS HRESULT
      DIM hres AS HRESULT
      DIM psl AS IShellLink PTR
      DIM w[MAX_PATH] AS WORD

      CoInitialize(NULL)

      $IFDEF __cplusplus
        hres = CoCreateInstance(CLSID_ShellLink, NULL, CLSCTX_INPROC_SERVER,  IID_IShellLink, (LPVOID*)&psl)
      $ELSE
        hres = CoCreateInstance(&CLSID_ShellLink, NULL, CLSCTX_INPROC_SERVER,  &IID_IShellLink, (LPVOID*)&psl)
      $ENDIF

      IF (SUCCEEDED(hres)) THEN
        DIM ppf AS IPersistFile PTR
        psl->lpVtbl->SetPath(psl, Exe)
        psl->lpVtbl->SetDescription(psl, Desc)
        psl->lpVtbl->SetShowCmd(psl, SW_SHOWMAXIMIZED)
        psl->lpVtbl->SetArguments(psl, Args$ )

        $IFDEF __cplusplus
          hres = psl->lpVtbl->QueryInterface(psl, IID_IPersistFile, (LPVOID*)&ppf)
        $ELSE
          hres = psl->lpVtbl->QueryInterface(psl, &IID_IPersistFile, (LPVOID*)&ppf)
        $ENDIF

        IF (SUCCEEDED(hres)) THEN
          MultiByteToWideChar(CP_ACP, 0, Link, -1, (LPWSTR)w, MAX_PATH)
          hres = ppf->lpVtbl->Save(ppf, (LPCOLESTR)w, TRUE)
          ppf->lpVtbl->Release(ppf)
        END IF
        psl->lpVtbl->Release(psl)
      END IF

      CoUninitialize()
      FUNCTION = hres
    END FUNCTION





My hack for removing the space between a variable and the member operator (->) works just fine and does not affect the compiling or functioning of either the C or C++ version of your code.

By the way, my hack is

Code: [Select]
    REPLACE (" " + "->")  WITH "->"    IN Source$


You might be thinking, why not this?

REPLACE ("  ->")  WITH "->"    IN Source$

The answer is, because BCX will convert the 1st string to the second and nothing is achieved.

The hack can be added after line 2943 in v752.


If I am mistaken with any of this, please point me in the right direction.

Thanks,
MrBcx

« Last Edit: August 06, 2020, 10:39:36 AM by MrBcx »