Recent Posts

1

General (but related to Code::Blocks) / Re: Welcome Newcomers - PLEASE READ!!!

« Last post by imtiaz_munna on Today at 11:11:10 am »

 "I am new, I am here"

2

Using Code::Blocks / Re: Project dependent upon another project?

« Last post by Miguel Gimenez on Today at 11:08:21 am »

Future spam added to radar.

3

Using Code::Blocks / Re: Project dependent upon another project?

« Last post by Trasatorn on Today at 11:03:05 am »

Projects can depend on other projects

4

CodeCompletion redesign / Re: use PPToken for preprocessor in native CC

« Last post by ollydbg on Today at 10:28:52 am »

I very briefly glanced across the commit pointed to by the link.

findings:

Thanks for the comment.

class PToken: data-member m_Kind is left uninitialized when PToken is default initialized and when initialized via the ctor with 4 args (while having 5 data-member).
  The call to the latter one is also a little errorprone. It might easily be used incorrectly because it has 3 int args. I'd consider member-initializer for the 4 integral data
  member and delete the default-ctor.

Oh, yes, I should initialize the m_Kind member variable in the default constructor and other constructors.
About the argument: "PPToken(wxString lexeme, int charIndex, int lineIndex, int nestLevel)", I really don't know where does the "charIndex" come from, I will looked into it.

The cctor of PToken is unecessary and breaks the rule-of-0 without need. It might also copy m_Kind from
  an uninitialized data-member. That is undefined behaviour. IMHO the cctor should be removed.

My initial though is that PPToken's copy constructor is used because I think it need to construct the element in the deque, in some cases, the PPToken get copied to the deque. Am I wrong?

Oh, you are correct,

In C++, the "Rule of Zero" is a guideline that suggests avoiding writing custom constructors, destructors, or copy/move assignment operators if the default compiler-generated versions will suffice. The rule states that if a class does not need custom resource management (like dynamic memory allocation), it can rely on the compiler-generated special member functions.

So, the copy constructor is not needed here, because the compiler will generate the same one if I remove it.

The compound statement after  if (IsEOF()) is repeated. It sets 2 data-members of PToken and should be delegated to PToken.

Do you mean that the

Code

    /** Check whether the Tokenizer reaches the end of the buffer (file) */
    bool IsEOF() const
    {
        return m_TokenIndex >= m_BufferLen;
    }

should be removed from the high level parser, but we can return a PPToken which has m_Kind field set as "EOF"?

Thanks.

5

CodeCompletion redesign / Re: use PPToken for preprocessor in native CC

« Last post by blauzahn on Today at 09:08:10 am »

I very briefly glanced across the commit pointed to by the link.

findings:

• class PToken: data-member m_Kind is left uninitialized when PToken is default initialized and when initialized via the ctor with 4 args (while having 5 data-member).
    The call to the latter one is also a little errorprone. It might easily be used incorrectly because it has 3 int args. I'd consider member-initializer for the 4 integral data
    member and delete the default-ctor.
• The cctor of PToken is unecessary and breaks the rule-of-0 without need. It might also copy m_Kind from
    an uninitialized data-member. That is undefined behaviour. IMHO the cctor should be removed.
• The compound statement after  if (IsEOF()) is repeated. It sets 2 data-members of PToken and should be delegated to PToken.

Cheers

6

CodeCompletion redesign / Re: use PPToken for preprocessor in native CC

« Last post by ollydbg on Today at 12:10:55 am »

I have been looking at this commit (the exact location of the changes was not specified).

PPToken looks to me just a way to pack token information, so I assume the real benefit is using the deque afterwards.

Thanks for the comment.

The "deque" here is used to move the token cursor forward or backward, because we have some interface to "peek token" (look ahead) or "undo token"(move the cursor backward), so I think a "deque" is a good structure to use.

I just suggest changing

Code

if (m_PPTokenStream.size() > 0)

to this

Code

if (!m_PPTokenStream.empty())

Thanks, but what's the difference? Maybe the "empty()" function runs much faster?

and removing this part

Code

    else
        ;// peekToken.Clear();

I will read this part of the code later.

Thanks.

7

CodeCompletion redesign / Re: use PPToken for preprocessor in native CC

« Last post by Miguel Gimenez on Yesterday at 05:58:45 pm »

I have been looking at this commit (the exact location of the changes was not specified).

PPToken looks to me just a way to pack token information, so I assume the real benefit is using the deque afterwards.

I just suggest changing

Code

if (m_PPTokenStream.size() > 0)

to this

Code

if (!m_PPTokenStream.empty())

and removing this part

Code

    else
        ;// peekToken.Clear();

8

CodeCompletion redesign / use PPToken for preprocessor in native CC

« Last post by ollydbg on Yesterday at 04:51:01 pm »

I have some code improvement about the preprocessor in our legacy Code completion plugin, see

https://github.com/asmwarrior/codeblocks_sfmirror/tree/master

What I want is that I would like to use "id compare" instead of "string compare" for the high level parser.

Comments are welcome, thanks.

9

Nightly builds / Re: The 14 September 2024 build (13570) is out.

« Last post by ThierryD on September 16, 2024, 01:56:15 pm »

Today, update of CB on Linux Mint 22 is possible ...

Thank's Xav'.

Sincerly.

10

Using Code::Blocks / Re: Update of documentation CB on Windows

« Last post by ThierryD on September 16, 2024, 01:53:17 pm »

OK, sorry newbie with MD format.

Thank's for the link. I read contents and apply on documentations.
 
Bye.