The SVN version doesn't compile with it.
Is anyone even interested in support for this?
I'm really interested, but I've tried some time ago, and failed.
I really would like to see that C::B can be compiled with: MSVC, DMars, and Intel compilers.
OK I got the core working and the AStyle plugin :)
Now I'm finishing up with the other main plugins.
It still builds fine in GCC with my changes... better, actually. :woot:
280: Mind explaining what changes are you making so we can understand and maybe cooperate?
Have you tested that GCC doesn't get broken?
Quote from: rickg22 on January 22, 2006, 05:35:09 AM
280: Mind explaining what changes are you making so we can understand and maybe cooperate?
Have you tested that GCC doesn't get broken?
Some of the changes are:
Strings:
Old: _T("text" "moretext")
New: _T("text") _T("moretext")Multiple inheritance (one example)
ProjectManager must derive from wxEvtHandler, THEN from Mgr<ProjectManager>:
class WXDLLIMPEXP_CB ProjectManager : public wxEvtHandler, public Mgr<ProjectManager>dllimport/dllexport... lots of changes to the way these were used and it works in GCC and MSVC now, and obviously won't change non-msw builds.
Fixed unchecked pointer errors, etc.
Fixed incorrectly declared and incorrectly used custom events
I prefer to just check them in if I could. That'd be much easier. :)
Quote from: 280Z28 on January 22, 2006, 05:52:17 AM
Fixed unchecked pointer errors, etc.
Fixed incorrectly declared and incorrectly used custom events
That demonstrates that compiling against more than one compiler is always good. :)
Whoever wrote depslib needs to be informed that in C, all variable declarations go at the beginning of their scope. Microsoft's compiler is rather strict about language rules. :)
Quote from: 280Z28Whoever wrote depslib needs to be informed that in C, all variable declarations go at the beginning of their scope. Microsoft's compiler is rather strict about language rules. :)
And somebody should tell Microsoft C99 is already out (right, since 1999) and it allows variable declarations just like in C++ ("mixed declarations and code" like the standard calls them), and many things more.
Quote from: Ceniza on January 22, 2006, 06:49:13 AM
Quote from: 280Z28Whoever wrote depslib needs to be informed that in C, all variable declarations go at the beginning of their scope. Microsoft's compiler is rather strict about language rules. :)
And somebody should tell Microsoft C99 is already out (right, since 1999) and it allows variable declarations just like in C++ ("mixed declarations and code" like the standard calls them), and many things more.
I think they stopped that because people still writing C code in 2005 are doing it for portability and not for high level language features. Not really sure, but I know reordering the declaration fixed the build problems.
Stopped what? Who? Features are there to implement and use. That's what I hate the most of MS: they give a *** about standards. You can forgive MS Visual C++ 6.0 for being that horrible for C++ 'cause it was released the same year of the first ISO standard for C++, but a recent version of the C compiler still using some kind of C89/C90? C'mon, it's 2006. I think they've had enough time, and obviously money, to implement that.
And add to that those "deprecated by MS" C functions in Visual C++ 2005. Those functions haven't been deprecated by the ISO, no reason for a compiler to throw warnings about!
BTW, portability in this case is highly related to following standards.
The compiler with VS 2005 is one of the most compliant compilers available.
Functions were deprecated primarily for two reasons:
1) Known insecurities. Obvious reason to deprecate. If you don't feel like changing these, define the following directive:
#define _CRT_SECURE_NO_DEPRECATE
2) Non-standard items. Things that were never in the C++ standard to start with have been deprecated. Turn these off:
#define _CRT_NONSTDC_NO_DEPRECATE
I got all the plugins from the main project working in it :)
always use more compilers to compile you code (if possible)
how about turning those c files into c++, so the c++ compiler treats them as c++ and not as c (in case of the same compiler), more over c is subset of c++ ??
[EDIT] It would indeeed by nice to have CB and plug-ins compilable with different compilers, but stick to the standards, so if we use C, don't screw it up for M$-s sake. Make C++ out of it, I know Thomas once wrote here a good reason, to have them as C, don't remember the argument anymore.
Quote from: 280Z28 on January 22, 2006, 09:57:30 AM
I got all the plugins from the main project working in it :)
So that means it works everything just like with GCC?
I wonder if compiling with DMars would work. You know, having C::B to compile exactly 20 times faster than GCC is not something minor. :D
I just compiled Code::Blocks revision 1828 with the Linux version of icc 9.0 and it seems to work well. Just a few changes were necessary:
First one for AngelScript:
Index: src/sdk/as/source/as_scriptengine.cpp
===================================================================
--- src/sdk/as/source/as_scriptengine.cpp (revision 1828)
+++ src/sdk/as/source/as_scriptengine.cpp (working copy)
@@ -2236,7 +2236,7 @@
}
else if( i->callConv == ICC_STDCALL )
{
- void (STDCALL *f)(void *, void *) = (void (STDCALL *)(void *, void *))(i->func);
+ void (STDCALL *f)(void *, void *) = (void (/*STDCALL*/ *)(void *, void *))(i->func);
f(param1, param2);
}
else
I'm sure if this still works - but without this change icc produces weired error messages. Probably because it seems to behave as GCC and has __GNUC__ makros (or something similar) defined and STDCALL is therefore expandet to __attribute(stdcall) (or something similar) and icc doesn't undertand this.
The next patch is for keybinder:
Index: src/plugins/contrib/keybinder/keybinder.cpp
===================================================================
--- src/plugins/contrib/keybinder/keybinder.cpp (revision 1828)
+++ src/plugins/contrib/keybinder/keybinder.cpp (working copy)
@@ -1421,7 +1421,7 @@
// use a combobox + a listbox
m_pCommandsList = new wxListBox(this, wxKEYBINDER_COMMANDS_BOX_ID, wxDefaultPosition,
- wxDefaultSize, 0, NULL);
+ wxDefaultSize, 0, 0);
m_pCategories = new wxComboBox(this, wxKEYBINDER_CATEGORIES_ID,
wxEmptyString, wxDefaultPosition, wxDefaultSize,
0, NULL, wxCB_READONLY);
That's because in C++ 0 should be used instead of NULL for a zero-pointer. With NULL icc complains about two constructors that are matching to the current call.
And the last one is for the profiler-plugin:
Index: src/plugins/contrib/profiler/cbprofiler.cpp
===================================================================
--- src/plugins/contrib/profiler/cbprofiler.cpp (revision 1828)
+++ src/plugins/contrib/profiler/cbprofiler.cpp (working copy)
@@ -85,11 +85,12 @@
if (project->GetBuildTargetsCount() > 1)
{
// more than one executable target? ask...
- wxString choices[project->GetBuildTargetsCount()];
+ wxString* choices = new wxString[project->GetBuildTargetsCount()];
for (int i=0; i<project->GetBuildTargetsCount(); i++)
choices[i] = project->GetBuildTarget(i)->GetTitle();
wxSingleChoiceDialog dialog(Manager::Get()->GetAppWindow(),_("Select the target you want to profile"),
_("Select Target"),project->GetBuildTargetsCount(),choices);
+ delete[] choices;
dialog.SetSelection(0);
if (dialog.ShowModal() != wxID_OK)
return -1;
It seems as if there were arrays with a variable length used. But this is a feature of C99 and *not* C++98. New gcc versions seem to support this for C++, too, but it is not correct.
Another thing is: I used the linux build system. Switching to icc is quite easy, just add CXX=icc CC=icc when invoking the configure-script. But icc doens't understand the same commands for building precomipled headers as the gcc. This means that precomipled headers must be disabled or the flags must be changed to make word with icc, too (anyway, I wasn't able to do this). But adding --enable-pch=no to the configure-call doens't work - configure fails with an error message:
Quote
configure: Configuring Code::Blocks...
configure: error: conditional "PRECOMPILE_HEADERS" was never defined.
Usually this means the macro was only invoked conditionally.
Thus i had to remove the parts for precompiled headers manually from 'src/sdk/Makefile.am' and 'src/plugins/contrib/wxsmith/Makefile.am'.
But then it works, icc just shows a few warnings about parameters it doesn't understand, like '--fast-math'.
Quote from: 280Z28 on January 22, 2006, 08:20:43 AM
The compiler with VS 2005 is one of the most compliant compilers available.
VS 2005 is a relatively good ISO-C++ compliant compiler (for sure better than Visual Studio C++ 6), but may be you would like to give a look at here (http://forums.next.codeblocks.org/index.php?topic=1670.0).
Michael
Quote from: killerbot on January 22, 2006, 09:59:24 AM
[EDIT] It would indeeed by nice to have CB and plug-ins compilable with different compilers, but stick to the standards...
Yes, IMHO it would be really nice :D. Anyway, this will provide additional work, because all the C::B and plugins modifcations, updates and so on need to be checked with all the supported compilers.
Michael
I wanted to use Visual Studio to track down the code completion bug I was facing, and I'd just like to say that within 2 minutes of running CB within the VS debugger for the first time, I found the problem. :shock: :lol:
Rick, you aren't using a Pentium 4, are you? :o
Quote from: 280Z28Functions were deprecated primarily for two reasons:
1) Known insecurities. Obvious reason to deprecate. If you don't feel like changing these, define the following directive:
#define _CRT_SECURE_NO_DEPRECATE
Obvious reason to deprecate? Defining another macro to make this specific compiler behave and stop throwing things it'sn't supposed to?
The reason to deprecate something in a compiler is because the standard says so. C99 and C++98 haven't deprecated that, it's plain wrong for a compiler to start adding deprecations here and there because they want to.
If they just showed a warning suggesting the use of another STANDARD function or read why you should use those functions carefully, that'd be fine, but no, they don't. An example of this is using
gets with gcc under Linux. gets hasn't been deprecated, but should be used with care or replaced with a call to fgets or anything else, but just because it's "insecure" doesn't give "obvious reasons" to the compiler to call it deprecated.
And then what? Will MS just remove those functions in the next release because were deprecated in the current version?
But anyway, if you can find something useful in the whole process of modifying the sources to make them compile with that compiler and not just having that compiler telling lies, that'd be good.
I disagree with you, but I guess that's ok because you'll never be using the VC compiler in the first place and I have a property sheet to add that to macro to projects I'm converting. ;)
I'd like to just check in the fix rather than going through all I did to fix it. Is that possible?
Rick hasn't a P4, but you'ren't saying what problem you found.
Would you mind to explain how P4 and CodeCompletion relate there? :)