Clang Complete new try?

[golgepapaz]

I rather prefer Code::Blocks style icons, but that may just be me.

  Well I am red-green colour blind and do better with shapes than colours.I am yet to see a better icon scheme (personally) than the MS icon library.
I am not comfortable with the C::B icons. It's a nx16 png strip anyway and can easily be replaced with something more suitable if the need arises.
  

[oBFusCATed]

1. clicking doesn't matter if you're serious about it. Because if the interface is unstable you'll loose the clicking and stop working on the project the first time you have to support two-three version of clang or even more. We want to support all distros.
2. see the gcc-4.1 note here. C::B doesn't work well with wx2.9 also I doubt it will be released in the next year or even two
3. boost is the main cause for harmed kittens, don't use boost please if you're serious about your plugin. Every linux distro has its own version of boost, good luck with the compatibility.

You can ignore all of the above if you're just playing and you're not serious (to be involved with the plugin for a long period of time (2+ years))

[MortenMacFly]

You should not wonder that after a while from our point of view its hard t believe in the success of a complete new trial. Looking into the past all such attempts failed.

I can only recommend to use what Eran has to offer: His CC library (if still decoupled from the IDE) is feature-rich, includes clang and ctags and is ready to use. Although I don't want to distract you from what you are doing, but new attempts should seriously believe making use of whats already out there and not something new.

[killerbot]

3. boost is the main cause for harmed kittens, don't use boost please if you're serious about your plugin. Every linux distro has its own version of boost, good luck with the compatibility.

Please stop telling and trashing things. Boost works perfectly nice, it all depends on what you use.

Instead of critiquing we should encourage every attempt, since every attempt might learn us something.
First we need proof of concepts and later in we can see how we can use them.

Have indeed a look at Eran's current state, I did some tests with it a couple of weeks ago, and it had a lot of failures. My code did however contained C++11 code.
But that is also what it needs to support, this is a hard requirement ! We are targeting the future.
Maybe it is good to study Erans work, and see how it can be improved , extended. Personally I would ignore the ctags part, and focus on the clang.


Do take into account, the current things of CB, eg wx2.8.x and not wx2.9. Prefer to use only official things (wx2.9 is beta, for like a zillion years :-(  )

[oBFusCATed]

Please stop telling and trashing things. Boost works perfectly nice, it all depends on what you use.

No it doesn't. Because they break their API. I'm talking from experience here.
I've tried to do an OSS app, which used boost::thread (and some others bind/function, nothing fancy) and had the chance
to try handle interface breakage. It was pretty funny. I've abandoned the project.
Another cool feature of my app was that the debug version was 20mbytes large for 10kloc, the linking wasn't fast.

Yes boost::shared_ptr should work everywhere, but we have cb::shared_ptr, so there is no need to use boost for that.

Boost might be safe to use in a project you're shipping statically linked, where you know the boost version and have tested it.
But not for OSS projects, where the project should work on a random distro with random boost version and compiler.

p.s. the only pluign which uses boost is disabled on centos5, because of too old version of boost shipping on centos5.
p.p.s. I'm just warning golgepapaz what are the requirements.

[killerbot]

the problem is centos5/6, these distros block evolution, in every aspect. Server software, great, but should not be seen as development os.
Well it doesn't matter, there are for example even ways to get the latest gcc compiler on centos instead of their ancient versions, so even there there is a way out :-)

[oBFusCATed]

the problem is centos5/6, these distros block evolution, in every aspect. Server software, great, but should not be seen as development os.
Well it doesn't matter, there are for example even ways to get the latest gcc compiler on centos instead of their ancient versions, so even there there is a way out :-)

Not if you want to treat you customers/users well. Forcing your users to install other compilers is not good.
And after that you'll have to ship wrapper scripts which modify LD_LIBRARY_PATH so the libstdc++ is found and so on. Lots of complications.

Also what about all the users of ubuntu 10/11 or older debians?

[stefanos_]

the problem is centos5/6, these distros block evolution, in every aspect. Server software, great, but should not be seen as development os.
Well it doesn't matter, there are for example even ways to get the latest gcc compiler on centos instead of their ancient versions, so even there there is a way out :-)

Not if you want to treat you customers/users well. Forcing your users to install other compilers is not good.
And after that you'll have to ship wrapper scripts which modify LD_LIBRARY_PATH so the libstdc++ is found and so on. Lots of complications.

Also what about all the users of ubuntu 10/11 or older debians?

@oBFusCATed: Are you suggesting ANSI C in such cases, so you can take the advantage of its portability? If yes, is there an existing project you can recommend? I'm interested to look its code please.