User forums > Nightly builds
The 12 October 2014 build (9958) is out.
eckard_klotz:
Hello Ollydbg.
Please excuse my late reply but the Friday afternoon and Saturday are my most busy times in the week.
First of all please excuse my bad orthography, especial if it is the core-reason, that I was not able to describe my point understandable. I know that Firefox normally offers spell checking since in my company it works and I know that this is a tool I have to use as often as possible. But for some reasons it is not working on my private Win 8 computer even it is activated. Furthermore I'm not able to use the Button Preview of this forum anymore, what I normally use to check how my post looks like. I think I have to look for some plug-in updates and to check the security adjustments. If somebody has tip for me, it will be great.
As attachment I added the combination of 2 screen shots that contains for one project the symbol browsers of the nightlies from September the 16th and October the 12th. As you can see in the older nightly I have to open the nesting namespace to see the nested namespace ( as I like), while in the newer nightly the nested namespaces are visible on the directly under the root node together with the nesting namespaces also (as I don't like). For me the hiding of nested namespaces is a very important key feature of the old symbol browser since it gave me the only possibility to define a kind of package structure, that was respected by the symbol browser. The idea is, once I look for a special source element, I normally know in what sub-package it is located. Thus I open the namespace path step by step until I reach the one that contains this element. Now the root-list of namespaces is full of namespaces I'm not interested in, if I want to navigate to a special one by opening the tree stepwise. This kind of visibility makes it very difficult to find that top-level namespace I have to open to first, while my navigation.
Furthermore if I click on a nested namespace shown on the same level as the nesting namespaces, C::B is not showing the location where the namespace is defined. C::B just opens the file and shows its first source lines. This was the case last year also.
I assume that one reason you have to get my point, is that my use of namespaces is more or less a misuse of them to establish a workaround. I use them to reduce the number of source elements shown in the symbol browser. Without doing this for me it is very difficult, to use the symbol browser for navigating through the code, since this means always a lot of scrolling. Unfortunately the possibility to reduce the number of source elements shown in the symbol browser is very limited. For example you have a context command to enable the showing of inherited members but there is no context command to disable the showing of those member elements on the top level of the symbol browser. In the past namespaces gave me the possibility to do so. Using namespaces for convincing the symbol browser to offer me a package-view is not really a good solution but until the nightly of September the 16th it worked. If you define the new behaviour as a feature you disabled this last possibility. Once there are some additional configuration possibilities to configure the symbol browser to offer as deeper tree-view and to disable the view of flat lists I would delete most of my namespaces. That's why I asked so often if it would be possible to offer a possibility to define virtual folders like in the project browser.
I already mentioned the limited possibility of reducing the since of top level lists in the symbol browser in the past. But until now nobody reacted. OK, I can understand, that this may mean a bigger change, what may be currently not possible for the C::B developers. You may also ask me why I would not do it by my self. To be honest I already thought about and did some investigations in your sources. But doing it by myself means to stop my own projects. Furthermore it means I have to learn how C::B intently works. I don't think, that you would accept a change to improve one part of C::B, if it influences other parts negatively, since the one who implemented the change was not aware of it. As a newbie in C::B development I would assume, that it would take at least one year to provide a solution that harmonise with the rest of the project and while this time I need frequently support from you also. But perhaps this is a thing we should discuss not in the nightly forum.
However, I hope that my attached picture is helpful to understand my doubts as well as my description of the goal I try to reach by using namespaces.
Best regards,
Eckard Klotz.
ollydbg:
--- Quote ---Furthermore I'm not able to use the Button Preview of this forum anymore, what I normally use to check how my post looks like. I think I have to look for some plug-in updates and to check the security adjustments. If somebody has tip for me, it will be great.
--- End quote ---
The preview button is broken, see:Code::Blocks forum 'Preview' not working
--- Quote ---As attachment I added the combination of 2 screen shots that contains for one project the symbol browsers of the nightlies from September the 16th and October the 12th. As you can see in the older nightly I have to open the nesting namespace to see the nested namespace ( as I like), while in the newer nightly the nested namespaces are visible on the directly under the root node together with the nesting namespaces also (as I don't like).
--- End quote ---
I have debugged a little and I have the same symbol tree results in the two version of nightlies, and see that you have such code:
MuLanPa\process\h\transform.h
--- Code: ---#ifndef DOXYGEN
namespace CL_PROCESS {
namespace CL_TRANSFORM {
#endif //DOXYGEN
...
...
#ifndef DOXYGEN
#define USING_NAMESPACE using namespace
};}; USING_NAMESPACE CL_TRANSFORM;
#endif //DOXYGEN
#undef USING_NAMESPACE
--- End code ---
Question:
Why do you use:
--- Code: --- using namespace CL_TRANSFORM
--- End code ---
I recommend you should use
--- Code: --- using namespace CL_PROCESS::CL_TRANSFORM
--- End code ---
Since CL_TRANSFORM is a child of CL_PROCESS.
Anyway, the CC parser's behaviour is correct in this case as I can see.
--- Quote ---Furthermore if I click on a nested namespace shown on the same level as the nesting namespaces, C::B is not showing the location where the namespace is defined. C::B just opens the file and shows its first source lines. This was the case last year also.
--- End quote ---
This is the same issue as I said before.
See here: Re: The 12 October 2014 build (9958) is out.
When you click on the second "b" (the namespace "b" under global namespace), because the second "b" is created as a dummy token.
--- Quote ---I assume that one reason you have to get my point, is that my use of namespaces is more or less a misuse of them to establish a workaround. I use them to reduce the number of source elements shown in the symbol browser. Without doing this for me it is very difficult, to use the symbol browser for navigating through the code, since this means always a lot of scrolling.
...
...
--- End quote ---
Please don't use the "misuse" any more, since our parser works correctly now.
--- Quote ---...
...
That's why I asked so often if it would be possible to offer a possibility to define virtual folders like in the project browser.
--- End quote ---
Note that symbol browser just build a hierarchy tree from the TokenTree, so if we get the correct parsing result, the symbol browser issue will be fixed, I don't think a "virtual folder" is possible, because the symbol tree are always created dynamically.
--- Quote ---I already mentioned the limited possibility of reducing the since of top level lists in the symbol browser in the past. But until now nobody reacted. OK, I can understand, that this may mean a bigger change, what may be currently not possible for the C::B developers. You may also ask me why I would not do it by my self. To be honest I already thought about and did some investigations in your sources. But doing it by myself means to stop my own projects. Furthermore it means I have to learn how C::B intently works. I don't think, that you would accept a change to improve one part of C::B, if it influences other parts negatively, since the one who implemented the change was not aware of it. As a newbie in C::B development I would assume, that it would take at least one year to provide a solution that harmonise with the rest of the project and while this time I need frequently support from you also. But perhaps this is a thing we should discuss not in the nightly forum.
--- End quote ---
The source code of C::B is not that hard to understand, so if you have any problems reading the source code, just ask here, I think you can get help from other ones(including me).
ToApolytoXaos:
OS: Debian testing (32-bit) [but it's the same on 64-bit at home PC]
GCC: gcc (Debian 4.9.1-16) 4.9.1
SVN: 10001
Bug detected in AStyle formatting.
Copy the following code in your C / C++ project.
--- Code: ---#include <stdio.h>
#include <stdlib.h>
int valid(void *p) {
extern char _etext;
return (p != NULL) && ((char*) p > &_etext);
}
int global;
int main(void) {
int local;
printf("pointer to local var valid? %d\n", valid(&local));
printf("pointer to static var valid? %d\n", valid(&global));
printf("pointer to function valid? %d\n", valid((void *)main));
int *p = (int *) malloc(sizeof(int));
printf("pointer to heap valid? %d\n", valid(p));
printf("pointer to end of allocated heap valid? %d\n", valid(++p));
free(--p);
printf("pointer to freed heap valid? %d\n", valid(p));
printf("null pointer valid? %d\n", valid(NULL));
return 0;
}
--- End code ---
DO NOT compile it just yet; right-click inside editor and choose "Format use AStyle"
The code becomes
--- Code: ---#include <stdio.h>
#include <stdlib.h>
int valid(void *p)
{
extern char _etext;
return (p != NULL) && ((char*) p > &_etext);
}
int global;
int main(void)
{
int local;
}
printf("pointer to local var valid? %d\n", valid(&local));
printf("pointer to static var valid? %d\n", valid(&global));
printf("pointer to function valid? %d\n", valid((void *)main));
int *p = (int *) malloc(sizeof(int));
printf("pointer to heap valid? %d\n", valid(p));
printf("pointer to end of allocated heap valid? %d\n", valid(++p));
free(--p);
printf("pointer to freed heap valid? %d\n", valid(p));
printf("null pointer valid? %d\n", valid(NULL));
return 0;
}
--- End code ---
Can you see the unnecessary } right after int local? Of course it won't compile as it closes main() prematurely, before reaching return 0.
Now, the mystery lies in the following order; paste the code in editor, compile it, and run it.
Close the run application and format the code. No curly brace added.
Alpha:
This will make AStyle play nice again..
--- Code: ---diff --git a/src/plugins/astyle/astyleplugin.cpp b/src/plugins/astyle/astyleplugin.cpp
index 80c002c..123fa65 100644
--- a/src/plugins/astyle/astyleplugin.cpp
+++ b/src/plugins/astyle/astyleplugin.cpp
@@ -419,6 +419,10 @@ bool AStylePlugin::FormatEditor( cbEditor *ed )
void AStylePlugin::ApplyTextDelta(cbStyledTextCtrl* stc, wxString text, int rangeStart, int rangeEnd)
{
+ stc->SetTargetStart(rangeStart);
+ stc->SetTargetEnd(rangeEnd);
+ stc->ReplaceTarget(text);
+#if 0
rangeStart = stc->LineFromPosition(rangeStart);
rangeEnd = stc->LineFromPosition(rangeEnd) + 1;
const wxString& eolChars = GetEOLStr(stc->GetEOLMode());
@@ -483,4 +487,5 @@ void AStylePlugin::ApplyTextDelta(cbStyledTextCtrl* stc, wxString text, int rang
}
stc->SetTargetEnd(stc->GetLineEndPosition(rangeEnd - 1));
stc->ReplaceTarget(buffer);
+#endif // 0
}
--- End code ---
ApplyTextDelta() attempted to make only the lines in the editor that actually changed be marked as updated. Unfortunately, it appears my logic had been flawed, and it is in a bad need of a rewrite.
Alpha:
--- Quote from: Alpha on October 21, 2014, 05:11:48 pm ---ApplyTextDelta() attempted to make only the lines in the editor that actually changed be marked as updated. Unfortunately, it appears my logic had been flawed, and it is in a bad need of a rewrite.
--- End quote ---
On second thought, magic numbers fix everything, right?
--- Code: ---diff --git a/src/plugins/astyle/astyleplugin.cpp b/src/plugins/astyle/astyleplugin.cpp
index 80c002c..afc645a 100644
--- a/src/plugins/astyle/astyleplugin.cpp
+++ b/src/plugins/astyle/astyleplugin.cpp
@@ -450,7 +450,10 @@ void AStylePlugin::ApplyTextDelta(cbStyledTextCtrl* stc, wxString text, int rang
int i = rangeStart + 1;
for (; i < rangeEnd; ++i)
{
- StrVecItr searchItr = std::find(lnItr + 1, (StrVecItr)textLines.end(), stc->GetLine(i).BeforeLast(eolChars[0]));
+ wxString edLine = stc->GetLine(i).BeforeLast(eolChars[0]);
+ if (edLine.Strip(wxString::both).Length() < 7) // magic number
+ continue;
+ StrVecItr searchItr = std::find(lnItr + 1, (StrVecItr)textLines.end(), edLine);
if (searchItr != textLines.end())
{
stc->SetTargetStart(stc->PositionFromLine(rangeStart));
--- End code ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version