Home » U++ Library support » U++ Core » NTL and C4251
| NTL and C4251 [message #2752] |
Mon, 24 April 2006 14:26  |
jmansion
Messages: 15
Registered: April 2006
Location: London
|
Promising Member |
|
|
I'm looking at Microsoft's missive on exporting classes that expose STL classes at http://support.microsoft.com/kb/q168958/
It looks like some of the classes can't be instantiated because they have nested classes.
Does NTL suffer from similar problems?
I'm not too committed to STL with the possible exception of wanting to support std::string in some places.
James
BTW is NTL effectively homed here now? The 'obvious' home at http://www.ntllib.org/ looks rather moribund, with 'latest news' stuck in mid 2003.
|
|
|
|
| Re: NTL and C4251 [message #2753 is a reply to message #2752] |
Mon, 24 April 2006 15:26  |
 |
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
Well, I am not sure, for several reasons.
First, article seems to be dealing with vc6.0- issues. U++/NTL does not compile with pre-7.1 compilers anyway.
Second, NTL itself does not support DLLs outside TheIDE. AFAIK TheIDE has specific hacks to compile process that makes those ugly declspec issues for importing/exporting stuff unnecessary (EXPORTS are automatically generated, just like in linux/.so - no explicit export/import declarations are necessary).
Anyway, to tell the truth, U++ is designed to provide standalone executables, no .dlls at all.
And yes, this is the right place for NTL 
Mirek
|
|
|
|
|
|
|
|
| Re: NTL and C4251 [message #2756 is a reply to message #2755] |
Mon, 24 April 2006 16:27 |
|
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| jmansion wrote on Mon, 24 April 2006 10:04 |
>TheIDE has specific hacks to compile process that makes those
>ugly declspec issues for importing/exporting stuff unnecessary
>(EXPORTS are automatically generated, just like in linux/.so -
>no explicit export/import declarations are necessary).
Oh - I'd hardly call the situation on Linux ideal, hence the work the gcc team has been doing to make control of visibility much easier and the performance issues seen in OOo and KDE.
|
I agree that performance sucks with dynamic loading of .so. However, I think this is rather the problem of that specific implementation than the problem of visibility only.
In any case, standalony binary (like one produced by U++) beats them all
| Quote: |
>Anyway, to tell the truth, U++ is designed to provide
>standalone executables, no .dlls at all.
Ouch. That's really a big disadvantage - it cuts out the use of SWIG to help automate subsystem testing etc or to provide services to JNI, P/Invoke or even to dynamically load extensions. I know I've typically released monolithic in-house binaries built static, but I'd not want to be forced to do this.
|
Well, the real meaning of standalone here is that you can ship U++ binary without any aditional .dll and it works on everything since Win95 or on most current Linux 386 distros. Anyway, on Linux, the build in fact is shared (against a limited number of system .so - namely glibc, stdc++, xlib and xft).
You can however use 3rd party .dlls, you can build .dlls (even OLE/COM components), and you can even build in "SO" mode where all library subsystems are build as dll.
| Quote: |
And that's probably answered whether I could move to U++ as my main development env.
|
Well, as always, you cannot satisfy everybody.... The mission goals are low development / maintainance costs. DLL hell does not contribute to either
Mirek
|
|
|
|
| Re: NTL and C4251 [message #2758 is a reply to message #2754] |
Mon, 24 April 2006 19:29 |
|
|
| jmansion wrote on Mon, 24 April 2006 09:34 |
BTW have you considered working with Walter Bright to use Digital Mars C++ under Win32?
|
I tried to build upp libs with dm c++. Unfortunately even with newset beta it fails to compile main upp lib - core (problems with templates).
Hopefuly Walter is fixing his compiler to be able to compile boost so maybe it will help to compile upp too  (main reason I want to use dmc is speed of compilation...)
|
|
|
|
|
|
| Re: NTL and C4251 [message #2760 is a reply to message #2759] |
Mon, 24 April 2006 22:44 |
|
|
| luzr wrote on Mon, 24 April 2006 15:29 |
| unodgs wrote on Mon, 24 April 2006 13:29 |
| jmansion wrote on Mon, 24 April 2006 09:34 |
BTW have you considered working with Walter Bright to use Digital Mars C++ under Win32?
|
I tried to build upp libs with dm c++. Unfortunately even with newset beta it fails to compile main upp lib - core (problems with templates).
Hopefuly Walter is fixing his compiler to be able to compile boost so maybe it will help to compile upp too (main reason I want to use dmc is speed of compilation...)
|
I hope some day we will gather enough resources to resolve this problem forever (I mean, C++ compiler is HARD thing to implement, but that makes it wonderful task to do, does not it?
Mirek
|
Once I had to write something similar to c compiler (using bison and flex) and it even worked (it produced 16-bit asm output for tasm). I remeber that I spent lots of houres working on it..
Probably it would take you about 3 years to implement full C++ compiler (and once you get it you will have to reimplemnt this to be compatabile with new 0x standard... )
Of course I wish you a luck !
PS: Personally I would switch to sth similar to D but without gc and with multiple inheritance (That may seem silly but the worst thing in D for me is that I have to use new syntax to create object..)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: NTL and C4251 [message #2777 is a reply to message #2775] |
Tue, 25 April 2006 10:41 |
|
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| Quote: |
But if the plugin and executable used the same compiler and build options etc. it probably work wouldn't it? - at least with VC++ on Windows?
|
Quite a lot of variables.... (add "VC++ the same version"). However, it would work - that is the SO mode Well, the important thing there is that there are no explicit exports anywhere in U++ code (as mentioned before).
| Quote: |
Would event dispatch work with the dll plugin?? - would the dll need its own thread with an event loop if the plugin had a visual component?
|
All I can say is that it works with U++ based OLE controls .dll used from MFC application. There were things to fix due to crazy MFC design, but it works.
| Quote: |
Would the dll need a different version of GUI_APP_MAIN ?
|
Yes, most likely yes. However, you are not required to use GUI_APP_MAIN, that is more or less a fix to save you platform specific #ifdefs.
BTW, I may agree with "main hijacking" complaints about those APP_MAIN. However, after writing that platform specific initialization for 20th time (in examples), I simply got bored and lazy...
Mirek
|
|
|
|
|
|
| Re: NTL and C4251 [message #2788 is a reply to message #2778] |
Tue, 25 April 2006 13:54 |
|
|
| luzr wrote on Tue, 25 April 2006 04:45 |
| jmansion wrote on Tue, 25 April 2006 04:23 |
.
There are plenty of tools out there that can help out which are a tad better than flex and yacc - consider ragel for scanners, d-parser, lemon etc etc.
|
I never believed in compiler generators. I guess that hand-written parsers are much easier to implement and maintain.
However, syntax parsing is the minor problem (I believe that I can write C++ _syntax_ parser in less than month). The real troubles come with semantics...
Mirek
|
True. That's why gcc team replaced their parsers with hand-written ones.
Semantics... - c++ draft stnadard from 96 in html has over 2mb. Probably more than half of it is about semantic...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: NTL and C4251 [message #2796 is a reply to message #2794] |
Tue, 25 April 2006 15:43 |
|
|
| jmansion wrote on Tue, 25 April 2006 09:19 |
>OK, I believe that it can save some time as long
>as you have description ready before starting the job...
You must type a lot faster than I do then. I think its actually most handy when evolving the grammar. I like to write the grammar, and then write some candidate inputs and see if they feel right, for the things I want to express. And then change things around a bit and try again.
James
|
Notice that grammar for C++ is already definied and approved, so there is no need for expeiments with grammar!
|
|
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Apr 25 14:21:25 GMT+2 2026
Total time taken to generate the page: 0.01205 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
