Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » Newbie corner » Few questions
Few questions [message #29636] Fri, 05 November 2010 05:48 Go to next message
OvermindDL1 is currently offline  OvermindDL1
Messages: 2
Registered: November 2010
Junior Member
Greetings, I have a few questions left that I was unable to answer after a large amount of Google searching.

- Is there any Boost package, preferably to the trunk?

- Supposing there is not Boost trunk package, I would like to create one, preferably in a reusable way, such a way being that I would like to svn checkout/export into a predefined directory and tell the boost/trunk package to rebuild itself (or preferably have it notice that I svn checkout/export'd an update and issue the rebuild automatically). Of course Boost is on the *monstrous* side in terms of size and complexity, so I do not fathom wanting to port it to the U++ build system (as truly fascinating as it is, I am impressed by it), so I would prefer to just issue the bjam command directly on it, with command parameters being specified by various options in the U++ build system (if we have python, build Boost.Python for example, etc...). Through my delving of the UPP project format I can discern that I could do this, but do not yet have the skill to actually implement it, more digging will be required for that, in the mean time, any and all tips, tricks, etc... that could be thrown my way would be exceedingly appreciated.

- Is U++ able to update the source of a project automatically using svn checkout/export (does it come with an svn client in other words that I can call from script?).

- If I do port boost/trunk to a reusable UPP package, would anyone be interested in it in the bazaar?

The main parts of boost I am wanting are ASIO, Fusion, Phoenix, and Spirit for note, no where near any form of a U++ equivalent for those.

- Would also think of making a boost/upp package as well to include headers to let Boost work with many UPP structures, one of the nice things about boost is its extensibility to support other container, structure, etc... types, would this be welcome?

- Hard to get an indication from these forums (the bazaar forum appears to have even fewer submissions then Boost, and it is *really* hard to get a submission into Boost...), but how active is the community and so forth?

- Is there a good third-party package repository of various libraries 'ported' to the U++ package format for ease of use U++ projects?

- Is there a mailing list, IRC, newsgroup, etc..., or just these forums?

I shall have more questions later, but how about these to start with.


My background, been programming in C++ for going on 18 years, huge advocate of Boost, regardless of its monolithicly huge compile times in certain libraries (Spirit is such a great parser...), and I have a tendency to push things to their limits. Generally program in Visual Studio with the Visual Assist plugin for Windows, *nix, and Mac programming work (Virtual Machines are great) due to how amazingly productive it is, Visual Assist practically reads my mind it seems, testing out U++ + TheIDE to see if it will make a better 'native' multi-platform build engine and IDE, and as stated above, I am impressed with the layout of how builds work, tag based systems can be very nice.

EDIT: Another question

- Have you though about including clang++ as a build engine? You could even import its sema library to provide full VisualAssist-level and above code verification, analysis, intellisense, etc...?

[Updated on: Fri, 05 November 2010 05:58]

Report message to a moderator

Re: Few questions [message #29639 is a reply to message #29636] Fri, 05 November 2010 09:41 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
OvermindDL1 wrote on Fri, 05 November 2010 05:48

- Is there any Boost package, preferably to the trunk?


No. Does it even need a package, isn't it just set of headers to include? (I don't use Boost, so I'm not sure)

About creating package... simply create package, include the .cpp/.h/other project files (.cpp inclusion is crucial for project build, .h and other directly non-build-able files just for easy edit trough IDE).
Then add the package to whatever other package where you want to use it.

If you refresh the sources of that boost package trough SVN, build process should detect changes in "modified" timestamp and rebuild everything related. (although with such fundamental classes used all over place it's more safe to hit Rebuild All, especially if you get some weird error after ordinary build)

I'm very likely wrong, but as long as Boost is just a helpful .h header, I don't see any problem with building it and using it in U++ (without any modification to source).

Quote:


- Is U++ able to update the source of a project automatically using svn checkout/export (does it come with an svn client in other words that I can call from script?).



TheIDE has SVN support in menu, it does use common command line client (svn.exe in win and svn in POSIX), which is IIRC not part of U++ installation. So TheIDE is just an front-end for classic SVN client, nothing more. (and if you prefer to have more control about what's happening under hood, I would suggest to use external tool like TortoiseSVN, TheIDE is a bit too simplified for my taste)

Quote:


- If I do port boost/trunk to a reusable UPP package, would anyone be interested in it in the bazaar?


Me: not now, nor planning it. But it never hurts to have something working in bazaar, so in case the need arise, you can try it out in ~3 clicks of mouse.

Quote:


- Would also think of making a boost/upp package as well to include headers to let Boost work with many UPP structures, one of the nice things about boost is its extensibility to support other container, structure, etc... types, would this be welcome?


This requires some work and R&D and experiments, right?
Of course anything of this is welcome and highly appreciated, just make sure your effort is well documented, so you will save time of other U++ users and make a path for them.
(If your idea of "welcome" is that it will get heavily adopted soon... take a break, this is BSD world, you give things away and see what picks up, but don't hold your breath. Smile )

Quote:


- Hard to get an indication from these forums (the bazaar forum appears to have even fewer submissions then Boost, and it is *really* hard to get a submission into Boost...), but how active is the community and so forth?


Community is small, but very active. Getting submission into bazaar is not very hard (even of lower quality or work in progress), getting patch into uppsrc is reasonably (much more) difficult (90% of good patches get in, and 90% of ballast get rejected, I don't think you can do much better with project of this size).
Bazaar pretty much follows it's name. If you dare to share your work, you will very likely get it there.

Quote:


- Is there a good third-party package repository of various libraries 'ported' to the U++ package format for ease of use U++ projects?


Bazaar is best place to start, then this forum. I'm not aware of anything for U++ being advertised elsewhere and not here, so I guess the answer is "no".

Quote:


- Is there a mailing list, IRC, newsgroup, etc..., or just these forums?


Forums are fastest and most active channel. There were also some IRC discussions, and also already a small live session in Prague, then PM on forums and some IM, but basically if you are active on forum, you shouldn't miss anything.

Quote:


My background, been programming in C++ for going on 18 years, huge advocate of Boost, regardless of its monolithicly huge compile times in certain libraries (Spirit is such a great parser...), and I have a tendency to push things to their limits. Generally program in Visual Studio with the Visual Assist plugin for Windows, *nix, and Mac programming work (Virtual Machines are great) due to how amazingly productive it is, Visual Assist practically reads my mind it seems, testing out U++ + TheIDE to see if it will make a better 'native' multi-platform build engine and IDE, and as stated above, I am impressed with the layout of how builds work, tag based systems can be very nice.



Nice to have you here, you can surely contribute by feedback of your U++ experience (as it's usually quite a rough ride at the beginning Smile) and I hope the community will be able to help you. Although with your experience and being a avid boost user you are not truly "compatible" with U++, so don't be surprised if it takes some time for you until you find a good way how to exploit U++ for your advantage. You will have to relearn some things for no obvious gain, and some things you will very likely do more efficiently in MSVS+boost, if you are good at it. Still if you ask me, U++ is worth a try, especially if you like to push things on limit, there are areas where U++ is clear winner.

Quote:

- Have you though about including clang++ as a build engine? You could even import its sema library to provide full VisualAssist-level and above code verification, analysis, intellisense, etc...?

clang in latest version is capable to build TheIDE, dolik is toying with it. Basically the building with clang already works, search forum to see what additional setup is needed. (you need working GCC build method and then just add clang build method as an replacement variant to GCC build)

And, one more thing about additions to Bazaar: BSD/MIT license or compatible is a good start for new package. (From reading the boost license right now I would say it's BSD compatible, but I didn't dig deep into it) If it's not compatible, you should mark it clearly as such (or maybe not include it into bazaar at all and push it just to forums), because most of the U++ users expect everything in bazaar to be free to use in commercial apps without consequences.
Re: Few questions [message #29642 is a reply to message #29636] Fri, 05 November 2010 10:51 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

Hi Overmind,

Welcome to the forum Wink Mr_ped pretty much answered all you questions, so just a few details:

There is IRC channel #upp at slashnet.org. I am online most of the time, other than me only about 2 people drop by occasionally.

Clang works fine on linux and probably other unix-like systems. There are still some problems on windows. As for deeper integration (inellisense, code analysis,...) it would require bit more work (especially the intellisense, as it would have to act as a replacement to Assist++, which is part of theide). But I'm not saying it won't happen at some point in future.

U++ is very good in pushing the limits. Not only the limits of what can be done in C++, but often also the limits of programmer Smile It learned me huge amount of new things about C++ and programing in general and also a lot of useful tricks... It is definitely worthed a try Wink

Best regards,
Honza
Re: Few questions [message #29663 is a reply to message #29639] Sat, 06 November 2010 02:04 Go to previous messageGo to next message
OvermindDL1 is currently offline  OvermindDL1
Messages: 2
Registered: November 2010
Junior Member
mr_ped wrote on Fri, 05 November 2010 02:41

OvermindDL1 wrote on Fri, 05 November 2010 05:48

- Is there any Boost package, preferably to the trunk?


No. Does it even need a package, isn't it just set of headers to include? (I don't use Boost, so I'm not sure)

About creating package... simply create package, include the .cpp/.h/other project files (.cpp inclusion is crucial for project build, .h and other directly non-build-able files just for easy edit trough IDE).
Then add the package to whatever other package where you want to use it.

If you refresh the sources of that boost package trough SVN, build process should detect changes in "modified" timestamp and rebuild everything related. (although with such fundamental classes used all over place it's more safe to hit Rebuild All, especially if you get some weird error after ordinary build)

I'm very likely wrong, but as long as Boost is just a helpful .h header, I don't see any problem with building it and using it in U++ (without any modification to source).


Boost is a meta-library, not a library in and of itself, but rather a lot of smaller libraries (some *very* small, some quite large) just held together under one umbrella, if they are good enough. As such, most are header-only, some require pre-compilation (using the bjam build engine, although a CMake port was finally 'completed' after much effort, bjam was made to work around the multi-platform inconsistencies very well), and some have a header-only or build option depending on if you want higher optimization or faster link time, and the build ones all (sans like two of them that have to be shared by their design) can be shared libraries or static libraries.

Reason I ask is that Boost is not auto-picked up from my global MSVC headers it seems, so I either need to explicitly include its directory in every one of my projects (hard-coding in the directory is *not* good in my opinion), or need to add the lookup to the U++ build methods, hence a package.

mr_ped wrote on Fri, 05 November 2010 02:41

Quote:


- Is U++ able to update the source of a project automatically using svn checkout/export (does it come with an svn client in other words that I can call from script?).



TheIDE has SVN support in menu, it does use common command line client (svn.exe in win and svn in POSIX), which is IIRC not part of U++ installation. So TheIDE is just an front-end for classic SVN client, nothing more. (and if you prefer to have more control about what's happening under hood, I would suggest to use external tool like TortoiseSVN, TheIDE is a bit too simplified for my taste)


That would be sufficient for my use, just some easier way to update from boost trunk instead of needing to do it manually, although that could be done too.

mr_ped wrote on Fri, 05 November 2010 02:41

Quote:


- If I do port boost/trunk to a reusable UPP package, would anyone be interested in it in the bazaar?


Me: not now, nor planning it. But it never hurts to have something working in bazaar, so in case the need arise, you can try it out in ~3 clicks of mouse.


It is better then hardcoding in include links for sure, I am still very surprised that this was not already done considering how massive and useful Boost is.

mr_ped wrote on Fri, 05 November 2010 02:41

Quote:


- Would also think of making a boost/upp package as well to include headers to let Boost work with many UPP structures, one of the nice things about boost is its extensibility to support other container, structure, etc... types, would this be welcome?


This requires some work and R&D and experiments, right?
Of course anything of this is welcome and highly appreciated, just make sure your effort is well documented, so you will save time of other U++ users and make a path for them.
(If your idea of "welcome" is that it will get heavily adopted soon... take a break, this is BSD world, you give things away and see what picks up, but don't hold your breath. Smile )


I know how the world is, I shun the limited gpl like a plague, I only release under truly free licenses, such as Boost (even BSD is 'less-free' then the Boost license, but I still use it).

mr_ped wrote on Fri, 05 November 2010 02:41

Quote:


- Hard to get an indication from these forums (the bazaar forum appears to have even fewer submissions then Boost, and it is *really* hard to get a submission into Boost...), but how active is the community and so forth?


Community is small, but very active. Getting submission into bazaar is not very hard (even of lower quality or work in progress), getting patch into uppsrc is reasonably (much more) difficult (90% of good patches get in, and 90% of ballast get rejected, I don't think you can do much better with project of this size).
Bazaar pretty much follows it's name. If you dare to share your work, you will very likely get it there.


Heh, so no multi-year-long review process then like I am used to then? Wink

mr_ped wrote on Fri, 05 November 2010 02:41

Quote:


- Is there a good third-party package repository of various libraries 'ported' to the U++ package format for ease of use U++ projects?


Bazaar is best place to start, then this forum. I'm not aware of anything for U++ being advertised elsewhere and not here, so I guess the answer is "no".


So the amount of packages is relatively low overall then? I shall work on fixing that as I get needs.

mr_ped wrote on Fri, 05 November 2010 02:41

Quote:


- Is there a mailing list, IRC, newsgroup, etc..., or just these forums?


Forums are fastest and most active channel. There were also some IRC discussions, and also already a small live session in Prague, then PM on forums and some IM, but basically if you are active on forum, you shouldn't miss anything.


Well I am stuck here in the USA, so a bit far for me. Forums are fine for me, just more used to mailing lists due to their ease of use and power.

mr_ped wrote on Fri, 05 November 2010 02:41

Quote:


My background, been programming in C++ for going on 18 years, huge advocate of Boost, regardless of its monolithicly huge compile times in certain libraries (Spirit is such a great parser...), and I have a tendency to push things to their limits. Generally program in Visual Studio with the Visual Assist plugin for Windows, *nix, and Mac programming work (Virtual Machines are great) due to how amazingly productive it is, Visual Assist practically reads my mind it seems, testing out U++ + TheIDE to see if it will make a better 'native' multi-platform build engine and IDE, and as stated above, I am impressed with the layout of how builds work, tag based systems can be very nice.



Nice to have you here, you can surely contribute by feedback of your U++ experience (as it's usually quite a rough ride at the beginning Smile) and I hope the community will be able to help you. Although with your experience and being a avid boost user you are not truly "compatible" with U++, so don't be surprised if it takes some time for you until you find a good way how to exploit U++ for your advantage. You will have to relearn some things for no obvious gain, and some things you will very likely do more efficiently in MSVS+boost, if you are good at it. Still if you ask me, U++ is worth a try, especially if you like to push things on limit, there are areas where U++ is clear winner.


Only been messing with it for a day now, I have not seen any rough ride, it seems quite smooth to me. The 'pick'ing, which I just take as 'move'ing in modern C++ terminology, has always made a lot of sense to me and it seems perfect for me.

I do question one design aspect though, why use an unused integer as a differentiator between pick/move and copy constructors and so forth? To me it seems better to use one of these two designs:
// instead of this:
  myType t(getMyType); // pick/move
  myType t(getMyType, 1); // copy

// Should do one of these for copy:
  myType t(copy(getMyType));
    // possibly renamed from copy,
    // but a single argument, copy should do nothing but return
    // something like _copy<myType> that just contains a
    // reference, yes, reference to MyType, which would call a
    // constructor specialized on that _copy<myType> type or so.

// Or this way:
  myType t(getmyTpe(), COPY);
    // where COPY is just a struct _COPY{}; static _COPY COPY;
    // or so, empty, etc...

The advantage of both of those is less register pressure in the call by not including an integer as an argument, and no chance of ambiguity if the call (potentially not a constructor call but a function call) if more parameters are passed.

The second method is more like your current method but reduces register pressure and removes ambiguity.

The first method, however, can also let the type have a conversion to the _COPY container as well so a function like void callMe(_COPY<myType> t); would work when myType t;callMe(t); is called so the function would always make a copy and never move without needing to add scaffolding inside of it to make an explicit copy after taking myType by reference or so, so that saves a line of code, *plus* it documents the method signature.

Also note, Boost *loves* move semantics, so it seems that U++ would fit right transparently in after making adapters to integrate them. There is actually a reviewed library (which I need to finish reviewing... >.<) that adds a C++1x style move semantic library including replacement std containers that support them, basically like U++ containers, but to move something you have to actually do something like:
mytype t(move(getMyType()));

Else it defaults to copy as per the C++1x standard.

Even if I do not use TheIDE, the U++ library itself seems quite useful so I would probably end up using it anyway, the gui aspect seems quite useful for some simple projects of mine without needing to whip out all of wxWidgets.

mr_ped wrote on Fri, 05 November 2010 02:41

Quote:

- Have you though about including clang++ as a build engine? You could even import its sema library to provide full VisualAssist-level and above code verification, analysis, intellisense, etc...?

clang in latest version is capable to build TheIDE, dolik is toying with it. Basically the building with clang already works, search forum to see what additional setup is needed. (you need working GCC build method and then just add clang build method as an replacement variant to GCC build)


It would be nice to include clang with TheIDE including a set of headers for pure multi-platform use thus not requiring a previous setup and not having to worry about compiler differences on various platforms

mr_ped wrote on Fri, 05 November 2010 02:41

And, one more thing about additions to Bazaar: BSD/MIT license or compatible is a good start for new package. (From reading the boost license right now I would say it's BSD compatible, but I didn't dig deep into it) If it's not compatible, you should mark it clearly as such (or maybe not include it into bazaar at all and push it just to forums), because most of the U++ users expect everything in bazaar to be free to use in commercial apps without consequences.


The Boost license is compatible with BSD, and it is in fact even more free then BSD as it does not require an text saying that you are using or anything, about the only thing it says is there is no warranty and you cannot claim that it is still boost code if you make modification, thus, if you make a modification to a boost header you cannot claim that it is still boost code, but rather your own, and you are allowed to change the license to pretty much whatever you wish. Boost can be included with any project, no charge, etc...



dolik.rce wrote on Fri, 05 November 2010 03:51

Hi Overmind,

Welcome to the forum Wink Mr_ped pretty much answered all you questions, so just a few details:

There is IRC channel #upp at slashnet.org. I am online most of the time, other than me only about 2 people drop by occasionally.


I might hover around in there, not been on that server before so would need to setup another account first.

dolik.rce wrote on Fri, 05 November 2010 03:51

Clang works fine on linux and probably other unix-like systems. There are still some problems on windows.


Actually Windows support on it works quite well for most people now, assuming you use mingw's headers and not Visual Studio's, although support for Visual Studio's headers is increasing at a very rapid pace.

dolik.rce wrote on Fri, 05 November 2010 03:51

As for deeper integration (inellisense, code analysis,...) it would require bit more work (especially the intellisense, as it would have to act as a replacement to Assist++, which is part of theide). But I'm not saying it won't happen at some point in future.


Correct, Assist++ would be rewritten, but you would have absolute and full parse, semantic, etc... information of the source code in question, even being able to follow back through complicated template or even macro expressions.

dolik.rce wrote on Fri, 05 November 2010 03:51

U++ is very good in pushing the limits. Not only the limits of what can be done in C++, but often also the limits of programmer Smile It learned me huge amount of new things about C++ and programing in general and also a lot of useful tricks... It is definitely worthed a try Wink


I am curious, if you had to sum up the limits that U++ pushes other then pick'ing/moving support, what else would you say that it is? To me it seems like a well made library, but does not particularly push much. Although, to be honest, my definition of 'pushing' something is like Boost.Spirit (assuming U++ is properly exposed to Boost):
  upp::Vector<int> vi;
  upp::String s("1,2,3,42");
  boost::spirit::parse(start(s), end(s), int_%',', vi);
  // vi now contains {1, 2, 3, 42}
  // And spirit expressions can be complex enough that there is
  // even one that can parse a C-style language and more.

Or like Boost.Phoenix (assuming U++ is properly exposed to Boost):
  template<typename cbType> void mapInts(Vector<int> &v, cbType cb)
  { // assuming foreach exists
    foreach(int &i, v) cb(i);
  }

  // Hmm, lets make one for something else too
  struct myType {int i; float f;} // assume this is properly exposed to Boost too
  typename boost::fusion::vector<int,float> myTuple;

  template<typename T, typename cbType> void map(Vector<T> &v, cbType cb)
  { // assuming foreach exists
    foreach(T &i, v) cb(i);
  }

  // And how to use Phoenix in a situation like this,
  // and Phoenix is *very* generically useful:
  Vector<int> v = {1,2,3,4,5}; // assuming this supports C++1x init lists for ease of reading
  Vector<int> v1(v,1); // copy
  Vector<int> v2(v,1); // copy
  Vector<int> v3(v,1); // copy
  mapInts(v1, arg1*=2);
  mapInts(v2, if_(!(arg1%2))[arg1/=2].else[arg1=0]);
  mapInts(v3, let(_a=arg1)[
                while_(--arg1)[
                  _a+=arg1
                ]
                ,arg1=_a
              ]);
  assert(v1 == {2,4,6,8,10});
  assert(v2 == {0,1,0,2,0};
  assert(v3 == {1,3,6,10,15};

  myType ty(42,3.14);
  myTuple tu(2,3.4);
  map(ty, arg1*=2);
  map(tu, arg1/=2);
  assert(ty == myType(84, 6.28)); // assuming the floats compare equally
  assert(tu == myTuple(1, 1.95)); // assuming the floats compare equally


Basically, phoenix implements C++ in C++ lazily so you can pass a phoenix-c++ expression as a functor, so you can do something like this:
  std::function<void(int&)> f1(arg1*=2);
  std::function<int(int)> f2(arg1*2);
  std::function<int(int,float,std::string)> f3(((COUT()<<arg3<<arg2<<arg1<<"\n"),arg1*arg2));
  
  auto myFun = arg1*2;
  std::function<int(int)> f4(myFun);
  std::function<float(float)> f5(myFun);

  int i=2;
  f1(i); // `i` become 4
  f2(3); // returns 6
  f3(2,3.5, "hi!"); // prints "hi!3.52\n" to COUT(), then returns 2*3.5, which
                    // is promoted to 2.0*3.5, which is 7.0, which is returned as int 7
  f4(4); // return 8
  f5(5.5); // returns 11.0

  struct myType { int i; void operator*(int i){COUT()<< "i=" << i << "\n";}};
  myType t;

  myFun(3); // returns 6
  myFun(3.3); // returns 6.6
  myFun(string("hi")); // returns "hihi" as a string is the string type support repeating
                       // by multiplated amount
  myFun(t); // prints "i=2", returns void
  int j=myFun(t); // does not compile because myFun returns void here
  int k=myFun(2); // k is set to 4


Unlike C++1x lambdas, which are monomorphic, boost::phoenix is polymorphic, meaning that it adjusts itself to the passed-in types. f1, f2, and f3 are just monomorphic in use, the polymorphism is examplified by myFun, f4, and f5. myFun is an unknown-type, meaning that if you want to save it to a variable you have to use either BOOST_AUTO or C++1x's auto keyword to save it to a variable, at this point it contains no data, is zero in size, and just an ast of types is generated (see Boost.Proto). When it is finally 'called', either by explicitly calling it like myFun(2), or by saving it to something that is capable of holding a functor (such as a boost/std::function, maybe U++'s callback methods depending on their power), then it generates code, the code is specific based on the input arguments and due to some template work there are no real functions generated, but is rather generated inline, thus doing myFun(2) will literally generate 2*2 inline, which the optimizer optimizes to an inline 4, hence no code is generated other a constant 4, and myFun(i) literally compiles inline to i*2, and is optimized by the optimizer if possible, all at compile time. If saved to an std::function<int(int)> for example, a single functor is generated that contains the highly optimized code. In the much above example mapInts function, the cbtype is a function parameter and not a boost/std::function as you may have noticed, meaning the real phoenix type is passed in, which is not a functor yet, but is then called in the loop, which inlines the call in the loop, meaning that the loop contains no function call, it is all done right there, very fast, all at compile time.

Admittedly, things like Spirit and Phoenix, which are *heavy* in modifying the C++ AST by using templates (again, see Boost.Proto, which is how they are implemented), do cause greatly increased compile time, but they both give you greatly increase runtime performance. The characteristics of Phoenix let you create lazy C++ function inline without needing to create external functions/functors to call, which may not be inlined like phoenix will be. The characteristics of Spirit generate parsing code (actually Spirit.Qi creates parsers from streams, usually text, but could be binary, to C++ structures, and Spirit.Karma goes the other way, from C++ structures to a stream, and Spirit.Lex is a lexer for ease of use for some patterns for parsing) at compile time that use both embedded optimizers to optimize the C++ AST using templates, then is further optimized by using the C++ optimizer in the compiler itself, as such, Boost.Spirit is currently the fastest parsing engine on the planet, outperforms every single tested parsing engine from Yacc/bison/antlr/hand-coded/etc, and so much more. If there is ever a case where Spirit is outperformed by something else, a simple test case sent to the devs can let them specialize a template optimizer to transform the code into something better for those use-cases, as such, Spirit can and always shall perform better then any other parsing engine.

As a disclaimer, yes, I have helped create both Phoenix and Spirit in small ways, so I do like to show them off. ^.^

So yes, those are what I traditionally think of when I think of 'pushing' C++. Smile

As for pushing the programmer, I know of the move semantics, they are getting popular in optimized C++ applications, and I see how the gui engine is designed, minimizing pointers, etc..., but it is all quite clear to me, so what are you describing about pushing the programmer? I have made continuation and coroutine engines in C++, made an Actor style library to all but remove all locks in multi-threaded programming to allow arbitrary expansion across any amount of cores, so I am used to 'pushing' things. Smile

[Updated on: Sat, 06 November 2010 03:29]

Report message to a moderator

Re: Few questions [message #29678 is a reply to message #29636] Mon, 08 November 2010 09:44 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
Boost includes can be maybe fixed just by adjusting build method?
Still if you want some of those built parts, create a package.

Quote:


I am still very surprised that this was not already done considering how massive and useful Boost is.


Well, surprising, but it's like that, the boost libs are mentioned by U++ users very rarely.
I can't speak for others, but for me the whole STL and Boost were too complex to feel well with them, I was doing pure C++ for a long time (even doing my own containers on the fly when I needed them, but in my area of problems I did usually need just static pools and other simple concepts which were easy to manage without libs). That's what turned me to U++, it's so small (considering what it does), that I forced myself to learn a bit more then C++.

This is also maybe answering a bit of your "pushing the programmer" question. You look to be extraordinary bright person with very good memory and logic, so you can remember those extended syntax sugar of boost/spirit/Phoenix, as you demonstrate. For me it's burden, I would have very hard time to learn all those new options, and to use them on the fly from head. From what you do showcase it looks very good, and I can imagine to adopt it if I would use it daily, but if I keep using C++ just rarely like now, I can't afford to learn things like this, too complex/abstract for me, so it would take serious time to learn, and I would forgot it next 2 weeks without using it.
Everyone has different limits, skills and needs. Wink (and once you have hammer in hand, many things looks suddenly like a nail Wink )

So if you don't find U++ too much weird, and you can use it straightaway, it's just good for you (and I bet some people here will envy you a bit, including me Wink ).

Quote:

Heh, so no multi-year-long review process then like I am used to then?

To bazaar not, you just ask for SVN access and commit, that's basically it.
To core the process is everything but years long. Usually you either have Mirek's attention and then it takes as much time as it's needed (from minutes to several iterations and changes over months), or you don't have his attention, then it can take longer or get forgotten at all. But usually changes to core are small, so easy to review and adopt.

We don't have time here for long review... the code either works and can be used, or doesn't work. Wink If it turns wrong later, it will be refactored out anyway, so no point to hesitate too much, U++ is far from overly rigid system. There's serious will to not break backward compatibility just for the sake of change (because core people are running considerable amount of commercial apps on U++ and have to adapt them to every such change), but when something is broken by design, it gets fixed, no matter how much it breaks old apps.

Quote:

So the amount of packages is relatively low overall then? I shall work on fixing that as I get needs.

Yes, new packages pop out mostly when somebody needs it. Although some of bazaar stuff was done just for experimental fun, but most of it is result of somebody using it at his work.

Quote:

I do question one design aspect though, why use an unused integer as a differentiator between pick/move and copy constructors and so forth?

This is clearly question at Mirek, although I'm not sure if he's reading such long posts carefully enough to notice. Smile
I don't mind your copy constuctor way either, looks quite natural to me.
I wouldn't worry about registers pollution, didn't check the assembly of compilation, but I think most of the modern compilers can optimize that part out, at least I think somebody claimed so. Anyway, I didn't hit performance problems there yet (usually when you need deep-copy, it will take so much CPU time, that handling one int parameter more would be "for free" even if optimizer would be unable to cut it out? IMHO)

Try to use TheIDE a bit too if you can? I think it may irritate you a bit, but the feedback would be very welcome, also it may help you to understand how many people U++ use and look at. (as an RAD GUI app dev tool, so they can produce some forms/reports with few clicks and put it into DB .. that maybe also partly answers why so few people miss those boost goodies)

Clang was unable to compile U++ sources for long time, that's why the support is lacking. Since their new improvements I think U++ will be extended in next months to fully support it.

About Assist++ rewrite... the performance can be the decisive factor. Assist++ is outperforming most of the C++ parsers/analyzers because of it's flaky (or almost non existent) macro/template support. Unless you have much more clever parser, you can't do much better as Assist with the same performance. Let's say you don't have much clever parser, just more valid one, so more slower. In such case I think TheIDE would have to extend some caching schemes (right now the Assist doesn't use any permanent cache at all IIRC, just parse all the source upon start of TheIDE and selecting the package to create temporary cache). So it's not only about parser replacement, it would require the whole Assist++ design change in case the parser would be not fast enough.
(I personally did use commercial extension Visual Assist years back, and since then I didn't see anything so good. Assist++ is not bad, it helps me a bit, but it's not as amazing, plus the global/local references separation is not to my taste either, but I got used to it now, and can work effectively even in TheIDE)
Re: Few questions [message #29699 is a reply to message #29663] Tue, 09 November 2010 06:53 Go to previous message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

OvermindDL1 wrote

I am curious, if you had to sum up the limits that U++ pushes other then pick'ing/moving support, what else would you say that it is?

Well, I see that the term "pushing" is a bit shifted for you Smile

Anyway, few things that I think are different in U++ compared to other frameworks and that try to take most of the language are:

Everything belongs somewhere philosophy. Every single bit in U++ app is accounted for, there are literally no memory leaks. This is partly by design of the containers etc. and partly by U++ allocator, that warns you automatically in debug if there is a leak.

The allocator mentioned above is also a great piece of code, which contributes to the great performance of U++. I can't tell you how it pushes the limits, as I never studied it, but the benchmarks IMHO say something. Also in addition to memory leak detection, the allocator also guards other things, like writing into freed memory.

Painter code is also worth mentioning, I think. It provides a feature rich and complete support for drawing, with very clean and intuitive interface, while being very fast. Compared to my previous experience with AGG engine, Painter is just a miracle.

All the little things, that save our time. IMHO, this is one of the most important reasons why I like U++. Chaining (mydialog.Sizable().Title("...").Icon(img)...). Clever operator overloads with similar interfaces even for unrelated classes, so that their use across the whole framework is quite homogeneous and therefore soon becomes intuitive. Handy helpers for common tasks (Format(),sorting,minmax...) written in very generic ways, usually templated, so that most of the time you can use them with your own types without any additional work. It might not be pushing the limits, but it is certainly great to have...

I hope this I at least partially satisfies your curiosity. Again, I understand that the above might be just a good use of C++ for you, but for me it was far beyond my imagination limits when I first came to U++ Smile

Honza
Previous Topic: Simple thread example
Next Topic: Open file as stream for fgetpos(), fseek(), etc.
Goto Forum:
  


Current Time: Tue Apr 23 15:17:39 CEST 2024

Total time taken to generate the page: 0.02408 seconds