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 » U++ Library support » U++ Core » NTL and C4251
NTL and C4251 [message #2752] Mon, 24 April 2006 14:26 Go to next message
jmansion is currently offline  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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14105
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 Wink

Mirek
Re: NTL and C4251 [message #2754 is a reply to message #2753] Mon, 24 April 2006 15:34 Go to previous messageGo to next message
jmansion is currently offline  jmansion
Messages: 15
Registered: April 2006
Location: London
Promising Member
Well, I can tell you that the problem is retained in VC2003. Haven't checked 2005 yet.

I'll have to extract NTL and have a look myself, then. I'm looking for something I can bundle into my source tree to remove issues with different STLs anyway (and so I can force it all to use my own memory allocator stuff too).

Thanks anyway.
James

BTW have you considered working with Walter Bright to use Digital Mars C++ under Win32?
Re: NTL and C4251 [message #2755 is a reply to message #2753] Mon, 24 April 2006 16:04 Go to previous messageGo to next message
jmansion is currently offline  jmansion
Messages: 15
Registered: April 2006
Location: London
Promising Member
>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.

>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.

I'll just have to look at NTL and uSTL more closely, I guess. And that's probably answered whether I could move to U++ as my main development env. Still handy for its target GUI apps though I guess.
Re: NTL and C4251 [message #2756 is a reply to message #2755] Mon, 24 April 2006 16:27 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14105
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 Wink

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 Wink

Mirek
Re: NTL and C4251 [message #2758 is a reply to message #2754] Mon, 24 April 2006 19:29 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

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 Smile (main reason I want to use dmc is speed of compilation...)
Re: NTL and C4251 [message #2759 is a reply to message #2758] Mon, 24 April 2006 21:29 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14105
Registered: November 2005
Ultimate Member
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 Smile (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 Smile (I mean, C++ compiler is HARD thing to implement, but that makes it wonderful task to do, does not it? Wink

Mirek

[Updated on: Mon, 24 April 2006 21:29]

Report message to a moderator

Re: NTL and C4251 [message #2760 is a reply to message #2759] Mon, 24 April 2006 22:44 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

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 Smile (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 Smile (I mean, C++ compiler is HARD thing to implement, but that makes it wonderful task to do, does not it? Wink

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... Wink )
Of course I wish you a luck ! Smile

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 #2761 is a reply to message #2760] Mon, 24 April 2006 22:49 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14105
Registered: November 2005
Ultimate Member
Quote:


Probably it would take you about 3 years to implement full C++ compiler



Yes, I guess that estimate is about to be right...

Well, let us finish U++ first Smile

Mirek
Re: NTL and C4251 [message #2765 is a reply to message #2755] Tue, 25 April 2006 06:41 Go to previous messageGo to next message
gprentice is currently offline  gprentice
Messages: 260
Registered: November 2005
Location: New Zealand
Experienced Member
jmansion wrote on Tue, 25 April 2006 02:04

>

>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.





Judging by Mirek's response, it seems he meant U++ is designed to allow you to avoid .dlls, not that you can't use and create them.

There's even a package template for creating a dll but it seems to not be in the latest U++ distribution ...

Graeme
Re: NTL and C4251 [message #2771 is a reply to message #2765] Tue, 25 April 2006 09:45 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14105
Registered: November 2005
Ultimate Member
Actually, thinking about the issue, the real important limitation is that you cannot use U++/C++ interfaces at .dll levels except slightly experimental SO mode. Example would be U++ application with U++ plugins - in practice, while both using U++, each should contain it own copy of the library and comunicate using some C based interface.

Which makes quite a sense to me - C++ interfaces across dll modules are always problematic. Think compiler name mangling differences or object layout problems....

Mirek
Re: NTL and C4251 [message #2773 is a reply to message #2758] Tue, 25 April 2006 10:17 Go to previous messageGo to next message
jmansion is currently offline  jmansion
Messages: 15
Registered: April 2006
Location: London
Promising Member
> (main reason I want to use dmc is speed of compilation...)

Indeed - its the fastest compiler I've ever used by some margin. Haven't tried latest Borland stuff though.
Re: NTL and C4251 [message #2774 is a reply to message #2759] Tue, 25 April 2006 10:23 Go to previous messageGo to next message
jmansion is currently offline  jmansion
Messages: 15
Registered: April 2006
Location: London
Promising Member
> I hope some day we will gather enough resources
> to resolve this problem forever

Perhaps start with LVM, and 'just' replace the front end.

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.

There's a choice of non-GPL free STLs now, and plenty of C library code that's non-GPL free.

James
Re: NTL and C4251 [message #2775 is a reply to message #2771] Tue, 25 April 2006 10:24 Go to previous messageGo to next message
gprentice is currently offline  gprentice
Messages: 260
Registered: November 2005
Location: New Zealand
Experienced Member
luzr wrote on Tue, 25 April 2006 19:45

Actually, thinking about the issue, the real important limitation is that you cannot use U++/C++ interfaces at .dll levels except slightly experimental SO mode. Example would be U++ application with U++ plugins - in practice, while both using U++, each should contain it own copy of the library and comunicate using some C based interface.

Which makes quite a sense to me - C++ interfaces across dll modules are always problematic. Think compiler name mangling differences or object layout problems....

Mirek



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? Getting the plugin to match the executable would be a problem though as you say.

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?

Would the dll need a different version of GUI_APP_MAIN ?


Graeme


Re: NTL and C4251 [message #2776 is a reply to message #2771] Tue, 25 April 2006 10:26 Go to previous messageGo to next message
jmansion is currently offline  jmansion
Messages: 15
Registered: April 2006
Location: London
Promising Member
If anyone is interested in this sort of thing and hasn't yet read 'Imperfect C++' then I recommend it.

See http://synesis.com.au/publishing/imperfect/cpp/.
Re: NTL and C4251 [message #2777 is a reply to message #2775] Tue, 25 April 2006 10:41 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14105
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 Wink 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 #2778 is a reply to message #2774] Tue, 25 April 2006 10:45 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14105
Registered: November 2005
Ultimate Member
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
Re: NTL and C4251 [message #2788 is a reply to message #2778] Tue, 25 April 2006 13:54 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

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 #2789 is a reply to message #2788] Tue, 25 April 2006 14:07 Go to previous messageGo to next message
jmansion is currently offline  jmansion
Messages: 15
Registered: April 2006
Location: London
Promising Member
Well, I agree that you can have more control over error reporting with a roll-your-own, but personally I would still look to a generator for the bits that can be easily automated, so then I can concentrate on building an AST that makes it as easy as possible to build the symbol tables and other structures, and having written compilers by hand before I definitely welcome these tools.

I find CoCo/R the easiest to use for simple tasks but I doubt its really up to C++ unless you you an external scanner. You have to defer a lot of C++ analysis anyway so the grammar isn't going to resolve identifiers to types as you go anyway.

Clearly, modern C++ semantics in practice are hugely dependent on the template and inline handling and getting the type searches right in such cases - and in making sure that error messages are sane and the generators won't help you here, but using LLVM as the back end surely will.
Re: NTL and C4251 [message #2790 is a reply to message #2789] Tue, 25 April 2006 14:20 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 14105
Registered: November 2005
Ultimate Member
jmansion wrote on Tue, 25 April 2006 08:07

I would still look to a generator for the bits that can be easily automated



Actually, I never got that part about "easily automated". With well designed C++ code, it is IME as easy to write descent parser right away as to create syntax description for "code generator" (or even to describe grammar in any formal way).

BTW, when developing Esc interpreter, I have never had any formal grammar for the language - descent parser C++ code is as good as the formal grammar description.

Quote:


AST
CoCo/R



What are these?

Quote:


sane and the generators won't help you here, but using LLVM as the back end surely will.



Yes, I agree about using LVM (if that is what I think: "platform independent assembler-like language"). Yet another option is to produce plain C....

Mirek
Previous Topic: TimeDate.cpp [BUG][FIXED]
Next Topic: Array container does only serialize base classes
Goto Forum:
  


Current Time: Fri Nov 01 00:55:03 CET 2024

Total time taken to generate the page: 0.03004 seconds