Request for Interest in several Modules

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Request for Interest in several Modules

Artyom Beilis
Hello,


I have several modules/libraries I developed and released under Boost License.

- CppDB Sql Connectivity
- Stack Trace
- Shared Object Loading
- Nowide UTF-8 friendly standard C/C++ library API.

----------------------------------

Let's start

Boost.CppDB

   CppDB library:

   Sql Connectivity library currently not Boostified, released and
   actively maintained.

   http://cppcms.sourceforge.net/sql/cppdb/index.html

   How much interest in this library as-is with small obvious

   modifications like using Boost Namespace

Boost.SharedObject:

   Simple Shared Object class for loading DLLs/SO - i.e. cross platfrom
   dlopen/dlclose + naming (libfoo.3.dylib/libfoo.so.3/foo-3.dll)

   http://cppcms.sourceforge.net/cppcms_ref_v0_99/classbooster_1_1shared__object.html

   Any interest in this simple class?
  
Boost.StackTrace

   Collecting stack trace automatically from exception and printing it.

   Very Very useful for debugging.

   http://cppcms.sourceforge.net/cppcms_ref_v0_99/namespacebooster_1_1stack__trace.html
   http://cppcms.sourceforge.net/cppcms_ref_v0_99/backtrace_8h_source.html


   Any interest in this library. It works (collects a trace and prints it) on:
 

   Windows, Solaris, Linux, Mac OS X

 
Boost.NoWide

   Standard C and C++ library UTF-8 friendly API for windows

   classes/functions:

     boost {
      nowide {
            [of]stream    - iostreams with UTF-8 file names
            f(re)open     - FILE * functions with UTF-8 file names
            remove, rename- UTF-8 parameters
            getenv,putenv - UTF-8 environment variables         
            args          - UTF-8 argc, argv
      }
    }

    Under non windows just (using std::...)



These functions (like Boost.Locale) all are parts of CppCMS C++ Web framework.


 
Artyom Beilis
--------------
CppCMS - C++ Web Framework:   http://cppcms.sf.net/
CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Giovanni Piero Deretta
On Tue, Jan 10, 2012 at 3:11 PM, Artyom Beilis <[hidden email]> wrote:
> Hello,
>
>
> I have several modules/libraries I developed and released under Boost License.
>
> - CppDB Sql Connectivity
> - Stack Trace
> - Shared Object Loading
> - Nowide UTF-8 friendly standard C/C++ library API.

Quite interested in all four, especially in the SQL connectivity library.

--
gpd

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Marshall Clow-2
In reply to this post by Artyom Beilis
On Jan 10, 2012, at 7:11 AM, Artyom Beilis wrote:

> Boost.StackTrace
>
>    Collecting stack trace automatically from exception and printing it.
>
>    Very Very useful for debugging.
>
>    http://cppcms.sourceforge.net/cppcms_ref_v0_99/namespacebooster_1_1stack__trace.html
>    http://cppcms.sourceforge.net/cppcms_ref_v0_99/backtrace_8h_source.html
>
>
>    Any interest in this library. It works (collects a trace and prints it) on:
>    Windows, Solaris, Linux, Mac OS X

This would be a great (feature) addition for Boost.Exception; the ability to attach a stack trace to an exception showing where it was thrown.

As you say, very, very useful for debugging


-- Marshall

Marshall Clow     Idio Software   <mailto:[hidden email]>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Brian Ravnsgaard Riis
In reply to this post by Artyom Beilis
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10-01-2012 16:11, Artyom Beilis wrote:
> Hello,
>
>
> I have several modules/libraries I developed and released under
> Boost License.
>
> - CppDB Sql Connectivity

Interested. Actually, I already use this...

> - Stack Trace - Shared Object Loading - Nowide UTF-8 friendly
> standard C/C++ library API.

Interested.

 /Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPDFx/AAoJEKd8gmwzkHPJTbcH/Rn5IskrHhEVaE5+5T6DxzbI
/jEBtLmfWYJyz/vbfZvCw0k3vRFpXJtaZOY5/0z66tBX+V/V1bgOge9q1Xlgybk7
Ism07X1pq/jyZLMfQuwli0TsNEZMVxyKpde/uvoovlHwi+hW5o32HSjNbtn4TrZH
zvskCc611P8BuesL1OD3eqUPJ3y1qqzGbeV6ZxjUm5T9VWSEe1ln5Y7bAiT02bVn
nDgdbScPIlZXVJ2LnajPaoKa8vzVj8EwBYdRetXt7LqHMbDKfZ+nlPbdNhblZ/I1
AGqla8iH///1dR+Tzju078Hh7Gg7NAlziWoDc58giOratKUddcuWR886XTdQZ+k=
=+dJd
-----END PGP SIGNATURE-----

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Christof Donat
In reply to this post by Artyom Beilis
Hi,

> I have several modules/libraries I developed and released under Boost
> License.
>
> - CppDB Sql Connectivity
> - Stack Trace
> - Shared Object Loading
> - Nowide UTF-8 friendly standard C/C++ library API.

Yes, all of those would be interesting. I am especially interested in
the DB connectivity and the shared objects. The UTF-8 friendly standard
library is also very interesting and the stack trace could be useful for
debugging in some situations.

For the DB connectivity I wondered, why your result objects don't
provide the input iterator interface, but next() and fetch() instead. I
guess, there is a good reason, but I'd like to know it.


I already had a look into your cppcms a while ago, which I mostly
liked. Sadly I did not really get around to try and write an application
with it. The biggest drawback for me is the use of "booster" instead of
boost. I know that there might me situations where a stable ABI is
important, but for me it is not. So I'd prefer to simply use boost
there. Do you think, there might be a compile time option to chose
either?

Christof

--
okunah gmbh                                  Software nach Maß

Werner-Haas-Str. 8                               www.okunah.de
86153 Augsburg                                    [hidden email]

                                       Registergericht Augsburg
Geschäftsführer                             Augsburg HRB 21896
Christof Donat                           UStID: DE 248 815 055

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Artyom Beilis
>

> For the DB connectivity I wondered, why your result
> objects don't provide the input iterator interface,
> but next() and fetch() instead. I guess, there is a
> good reason, but I'd like to know it.
>

There are several reasons.

When *result_iterator would return? Who owns it? If I change
it what it does.

Basically I had seem several SQL libraries with iterator interface
and it felt unnatural and abused, on the other hand in some
other libraries (like for example JDBC, I know... I know Java/Ugly)
it was much more intuitive.
Finally cppdb::result is much more complex then JUST iterator.

In this case next more clear operation with more clear semantics
without any "temporary object" and various copy semantics etc.

Now fetch has even bigger differences, it is not iterator and it
has multiple parameters (under the hood it is fetch(int col,Type &))


So between the choice of creating unnatural API with side effects
or clear but less "modern-C++-style-API" I had chosen the second.



>
> I already had a look into your cppcms a while ago, which I mostly liked.
> Sadly I did not really get around to try and write an application with it.
> The biggest drawback for me is the use of "booster" instead of boost.
> I know that there might me situations where a stable ABI is important,
> but for me it is not. So I'd prefer to simply use boost there.
> Do you think, there might be a compile time option to chose either?

First of all Booster is very far from Boost. It has **some** boost like
classes and many others with different semantics. So it is not

"copy-paste" replaceable especially parts like Booster.AIO that
shared general ideas with ASIO but solves some very critical
problems that exist in ASIO from my point of view.


Finally you don't use almost any of them most of the with some very special
exceptions... And nothing prevents from you to use Boost whatever
version and type you like.


>
>Christof
>
>-- okunah gmbh                                  Software nach Maß
>
>Werner-Haas-Str. 8                              www.okunah.de
>86153 Augsburg                                    [hidden email]
>
>                                      Registergericht Augsburg
>Geschäftsführer                             Augsburg HRB 21896
>Christof Donat                           UStID: DE 248 815 055
>
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

fpelliccioni
In reply to this post by Christof Donat
Hello,

On Tue, Jan 10, 2012 at 1:12 PM, Christof Donat <[hidden email]> wrote:

>
> I have several modules/libraries I developed and released under Boost
>> License.
>>
>> - CppDB Sql Connectivity
>> - Stack Trace
>> - Shared Object Loading
>> - Nowide UTF-8 friendly standard C/C++ library API.
>>
>
>
I am interested in the four libraries.


>
> I already had a look into your cppcms a while ago, which I mostly liked.
> Sadly I did not really get around to try and write an application with it.
> The biggest drawback for me is the use of "booster" instead of boost. I
> know that there might me situations where a stable ABI is important, but
> for me it is not. So I'd prefer to simply use boost there. Do you think,
> there might be a compile time option to chose either?


I share the thought of Christof about Booster versus Boost.

Regards,
Fernando.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Mathias Gaunard-2
In reply to this post by Marshall Clow-2
On 01/10/2012 04:29 PM, Marshall Clow wrote:

> On Jan 10, 2012, at 7:11 AM, Artyom Beilis wrote:
>
>> Boost.StackTrace
>>
>>     Collecting stack trace automatically from exception and printing it.
>>
>>     Very Very useful for debugging.
>>
>>     http://cppcms.sourceforge.net/cppcms_ref_v0_99/namespacebooster_1_1stack__trace.html
>>     http://cppcms.sourceforge.net/cppcms_ref_v0_99/backtrace_8h_source.html
>>
>>
>>     Any interest in this library. It works (collects a trace and prints it) on:
>>     Windows, Solaris, Linux, Mac OS X
>
> This would be a great (feature) addition for Boost.Exception; the ability to attach a stack trace to an exception showing where it was thrown.
>
> As you say, very, very useful for debugging

Why not just use a debugger?
They can give backtraces as well.

While we're speaking of it, Boost.Exception adds a massive amount of
bloat. I'm considering scrapping it for that reason.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Klaim - Joël Lamotte
In reply to this post by fpelliccioni
Hi,

I'm also interested in those libraries, in particular in cppdb but more by
shared_object.
Looking at it's interface documentation I'd like to ask some minor
questions:

 1. The boost::extension author reported (when i asked him) a lack in the
C++11 standard (without precision) that makes it hard to implement
correctly this library on all platforms/compilers (unfortunately he didn't
say which ones).
Do you have any information about that?

 2. booster::shared_object::shared_object(std::string const & file_name )

    Here file_name is a path, right?
    I'm guessing it's relative to the way the OS will look for modules?

 3. Is there a specific reason that there isn't a provided abstraction
(template "helper" function) that will call resolve_symbol() and try
(dynamic or not) to cast it for you to the provided type? My understanding
is that you wanted to let the user do as he wish but I was asking myself if
common usage could be identified and provided by default.

Thanks!

Joël Lamotte

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Christof Donat
In reply to this post by Artyom Beilis
Hi,

>> For the DB connectivity I wondered, why your result
>> objects don't provide the input iterator interface,
>> but next() and fetch() instead. I guess, there is a
>> good reason, but I'd like to know it.
>>
>
> There are several reasons.
>
> [...]
> Basically I had seem several SQL libraries with iterator interface
> and it felt unnatural and abused,

OK, I have not tried, it would just have been my first idea for an
interface there. The good thing about using iterators is, that you could
also use STL and boost algorithms and with C++11 range based for loops
on it, but maybe that is less of an advantage when you have SQL at hand.

> So between the choice of creating unnatural API with side effects
> or clear but less "modern-C++-style-API" I had chosen the second.

OK. I did not want to question your choice, but to understand your
reasons. Thanks for your explanation.

>> I already had a look into your cppcms a while ago, which I mostly
>> liked.
>> Sadly I did not really get around to try and write an application
>> with it.
>> The biggest drawback for me is the use of "booster" instead of
>> boost.
>> I know that there might me situations where a stable ABI is
>> important,
>> but for me it is not. So I'd prefer to simply use boost there.
>> Do you think, there might be a compile time option to chose either?
>
> First of all Booster is very far from Boost. It has **some** boost
> like
> classes and many others with different semantics. So it is not

OK, I understood the documentation, that booster is very similar to
boost, but with the ABI as stable as possible. Seems like I
misunderstood it there.

> "copy-paste" replaceable especially parts like Booster.AIO that
> shared general ideas with ASIO but solves some very critical
> problems that exist in ASIO from my point of view.

Of course I'd like to learn about these problems. Eventually there ist
also a way to improve boost accordingly.

> Finally you don't use almost any of them most of the with some very
> special
> exceptions... And nothing prevents from you to use Boost whatever
> version and type you like.

Sure. I just think, that using two different libraries that serve
almost the same purpose in one application is a little bit suboptimal.
So maybe my judgement was based on the - as I have learned now - wrong
assumption that booster is mostly a copy of some boost libraries.

Christof

--
okunah gmbh                                  Software nach Maß

Werner-Haas-Str. 8                               www.okunah.de
86153 Augsburg                                    [hidden email]

                                       Registergericht Augsburg
Geschäftsführer                             Augsburg HRB 21896
Christof Donat                           UStID: DE 248 815 055

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Nathan Ridge
In reply to this post by Artyom Beilis

> Boost.StackTrace
>
>    Collecting stack trace automatically from exception and printing it.
>
>    Very Very useful for debugging.
>
>    http://cppcms.sourceforge.net/cppcms_ref_v0_99/namespacebooster_1_1stack__trace.html
>    http://cppcms.sourceforge.net/cppcms_ref_v0_99/backtrace_8h_source.html
>
>
>    Any interest in this library. It works (collects a trace and prints it) on:
>
>
>    Windows, Solaris, Linux, Mac OS X

Very interested. How does this work?

Thanks,
Nate
     

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Christian Holmquist
In reply to this post by Mathias Gaunard-2
On 10 January 2012 11:16, Mathias Gaunard <[hidden email]>wrote:

> On 01/10/2012 04:29 PM, Marshall Clow wrote:
>
>> On Jan 10, 2012, at 7:11 AM, Artyom Beilis wrote:
>>
>>  Boost.StackTrace
>>>
>>>    Collecting stack trace automatically from exception and printing it.
>>>
>>>    Very Very useful for debugging.
>>>
>>>    http://cppcms.sourceforge.net/**cppcms_ref_v0_99/**
>>> namespacebooster_1_1stack__**trace.html<http://cppcms.sourceforge.net/cppcms_ref_v0_99/namespacebooster_1_1stack__trace.html>
>>>    http://cppcms.sourceforge.net/**cppcms_ref_v0_99/backtrace_8h_**
>>> source.html<http://cppcms.sourceforge.net/cppcms_ref_v0_99/backtrace_8h_source.html>
>>>
>>>
>>>    Any interest in this library. It works (collects a trace and prints
>>> it) on:
>>>    Windows, Solaris, Linux, Mac OS X
>>>
>>
>> This would be a great (feature) addition for Boost.Exception; the ability
>> to attach a stack trace to an exception showing where it was thrown.
>>
>>
Extremely useful. We make extensive use of in house 'developed' (i.e.
assembled from myriads small snippets on the web) stacktrace classes.


> As you say, very, very useful for debugging
>>
>
> Why not just use a debugger?

They can give backtraces as well.
>

It's for when you don't have a debugger attached, or don't want to stop
your program from continued execution:
* To log callstacks from a running program doesn't infer (very much) with
its execution, such as would halting it. For large systems more powerful
than debugging.
* Production (server) environments can't be halted and debugged due to an
exception, but retrieving the stacktrace will aid in later error analysis.


- Christian

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Artyom Beilis
In reply to this post by Klaim - Joël Lamotte


> 1. The boost::extension author reported (when i asked him) a lack in the
> C++11 standard (without precision) that makes it hard to implement
> correctly this library on all platforms/compilers (unfortunately he didn't
> say which ones).
> Do you have any information about that?


I don't exactly understand what is the problem.


You create an entry factory point like

extern "C" {
   foo* bar();
}

Resolve bar withing shared object/dll and it works 100%


As long as you don't mix runtimes i.e. dll and main program uses

different heaps and so on there is no problems I'm aware of.


> 2. booster::shared_object::shared_object(std::string const & file_name )
>
>     Here file_name is a path, right?
>     I'm guessing it's relative to the way the OS will look for modules?


Actually it is quite same on Unix and Windows.

A name without "path" like "foo.so" it searches withing general path,
on windows .:$PATH and on Unix under predefined set
of locations + LD_LIBRARY_PATH.

If full/relative path provided it searches according to it.

>
> 3. Is there a specific reason that there isn't a provided abstraction
> (template "helper" function) that will call resolve_symbol() and try
> (dynamic or not) to cast it for you to the provided type? My understanding
> is that you wanted to let the user do as he wish but I was asking myself if
> common usage could be identified and provided by default.

There is a helper function that helps to cast void * to 
function pointer.

Genrally any plugin/so/dll should have its entry point like
shown above and implement some known interface.
What would do the job.

It is more abstraction of dlopen/dlsym rather then generic
interface to map anything you want need dynamically.


>
> Thanks!
>
> Joël Lamotte
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Artyom Beilis
In reply to this post by Christof Donat


 
> OK, I understood the documentation, that booster is very similar to boost, but
> with the ABI as stable as possible. Seems like I misunderstood it there.
>

Booster is a boost-like API for functionality required in public interface:

- callbacks: booster::function and booster::callback (same as function
  but reference counted)
- regular expressions
- event loop
- mutexes
- some smart pointers (shared/intrusive - copied from boost)

And some more. It is not boost and it does not replace it.


The biggest shared part is obviously Boost.Locale :-)
 
>>  "copy-paste" replaceable especially parts like Booster.AIO that
>>  shared general ideas with ASIO but solves some very critical
>>  problems that exist in ASIO from my point of view.
>
> Of course I'd like to learn about these problems. Eventually there ist also
> a way to improve boost accordingly.


Several problems.

ASIO uses templates were I don't think they should be, there is
no reason for stream_socket for TCP and Unix domain socket
to be different class...

For example if I implement FastCGI over Unix socket
and TCP socket, under ASIO it must be 2 different classes
as under ASIO it is two different classes.

It is matter of design. But when CppCMS has 5-6 such classes
it becomes painful.

Another thing. ASIO uses IOCP, IOCP does not
provide:

- Reactor like functionality
- Does not allow detach socket from IOCP

Thus some functionality is just missing under ASIO because
it is impossible to both use IOCP for best beformance
and have reactor like functionality.

This is the design. I have different needs.

Just don't get wrong ASIO is absolutely great library

and I use it on daily basis, but it does not fit
CppCMS's project needs.


>>  Finally you don't use almost any of them most of the with some very
> special
>>  exceptions... And nothing prevents from you to use Boost whatever
>>  version and type you like.
>
> Sure. I just think, that using two different libraries that serve almost the
> same purpose in one application is a little bit suboptimal. So maybe my
> judgement was based on the - as I have learned now - wrong assumption that
> booster is mostly a copy of some boost libraries.
>
> Christof

Some stuff is copied, (mostly smart pointers) some stuff provide simplified
interface and some stuff is very different.

Artyom


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Artyom Beilis
In reply to this post by Nathan Ridge


----- Original Message -----

> From: Nathan Ridge <[hidden email]>
>
>>  Boost.StackTrace
>>
>>     Collecting stack trace automatically from exception and printing it.
>>
>>     Very Very useful for debugging.
>>
>>    
> http://cppcms.sourceforge.net/cppcms_ref_v0_99/namespacebooster_1_1stack__trace.html
>>     http://cppcms.sourceforge.net/cppcms_ref_v0_99/backtrace_8h_source.html
>>
>>
>>     Any interest in this library. It works (collects a trace and prints it)
> on:
>>
>>
>>     Windows, Solaris, Linux, Mac OS X
>
> Very interested. How does this work?


Very simple:

http://cppcms.svn.sourceforge.net/viewvc/cppcms/framework/trunk/booster/lib/backtrace/src/backtrace.cpp?revision=2052&view=markup


In short.

Linux, Solaris, Mac OS X:

- execinfo.h
  backtrace+backtrace_symbols/dladdr

Windows

  - RtlCaptureStackBackTrace

  - SymFromAddr (for MSVC)

 

Artyom Beilis
--------------
CppCMS - C++ Web Framework: http://cppcms.sf.net/
CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Klaim - Joël Lamotte
In reply to this post by Artyom Beilis
On Tue, Jan 10, 2012 at 21:15, Artyom Beilis <[hidden email]> wrote:

> >
>
> > 1. The boost::extension author reported (when i asked him) a lack in the
> > C++11 standard (without precision) that makes it hard to implement
> > correctly this library on all platforms/compilers (unfortunately he
> didn't
> > say which ones).
> > Do you have any information about that?
> >
>
> I don't exactly understand what is the problem.
>
> Unfortunately I don't have the details of the problems he reported, but I
sent a mail asking for details. Didn't get an answer yet.
Anyway Boost.Extension is find with most cases it seems so I guess that he
was speaking about runtime mixes.


>
> You create an entry factory point like
>
> extern "C" {
>    foo* bar();
> }
>
> Resolve bar withing shared object/dll and it works 100%
>
>
That always was my understanding too.


>
> As long as you don't mix runtimes i.e. dll and main program uses
>  different heaps and so on there is no problems I'm aware of.


It might be the problem, as C++ standard don't define anything about all
this, obviously.

Anyway I like the simplicity of your solution, it seems easy to build on.

Another minor question : what is the rational in choosing std::string in
the interface instead of const char* ?

Joël Lamotte.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Nathan Ridge
In reply to this post by Artyom Beilis

> >> Boost.StackTrace
> >>
> >>     Collecting stack trace automatically from exception and printing it.
>
> > How does this work?
> >
>
> Very simple:
>
> http://cppcms.svn.sourceforge.net/viewvc/cppcms/framework/trunk/booster/lib/backtrace/src/backtrace.cpp?revision=2052&view=markup
>
>
> In short.
>
> Linux, Solaris, Mac OS X:
>
> - execinfo.h
>   backtrace+backtrace_symbols/dladdr
>
> Windows
>
>   - RtlCaptureStackBackTrace
>
>   - SymFromAddr (for MSVC)

So where does the symbol information come from? From the debug information
compiled into the program? If so, what happens if I compile the program
without debug info? What happens if I use an optimized build?

Thanks,
Nate
     

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Artyom Beilis



>________________________________
> From: Nathan Ridge <[hidden email]>
>To: Boost Developers Mailing List <[hidden email]>
>Sent: Tuesday, January 10, 2012 11:48 PM
>Subject: Re: [boost] Request for Interest in several Modules
>
>
>> >> Boost.StackTrace
>> >>
>> >>     Collecting stack trace automatically from exception and printing it.
>>
>> > How does this work?
>> >
>>
>> Very simple:
>>
>> [snip]
>>
>> In short.
>>
>> Linux, Solaris, Mac OS X:
>>
>> - execinfo.h
>>   backtrace+backtrace_symbols/dladdr
>>
>> Windows
>>
>>   - RtlCaptureStackBackTrace
>>
>>   - SymFromAddr (for MSVC)
>
>So where does the symbol information come from?

Under ELF platforms (Linux, Solaris, Mac OS X)
it uses linking symbols, they are built in

in shared objects and can be added by using
-rdynamic flag (which is recommended flag

to use in any case)

They are usually resolved using dladdr library call.


Under Windows/MSVC it uses debug information.


> From the debug information
> compiled into the program?

Using MSVC it does not have to be compiled to
the program, it may be external files (PDB files)


> If so, what happens if I compile the program
> without debug info?

You would not get resolved symbol names under Visual Studio


> What happens if I use an optimized build?
>

Optimization does not prevent generation of debug
information. For example CMake's flag RelWithDebInfo
does this automatically and perfectly for you,
of course you can set your own flags in VS projects
to make this work.


If I remember correctly using /Zi would
happily generate debug information (PDB files)
for release builds


>Thanks,
>Nate
>                



Best,
  Artyom


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

Artyom Beilis
In reply to this post by Klaim - Joël Lamotte


>
>>
>>  As long as you don't mix runtimes i.e. dll and main program uses
>>   different heaps and so on there is no problems I'm aware of.
>
>
> It might be the problem, as C++ standard don't define anything about all
> this, obviously.
>

C++ does not say anything on shared object and dlls :-)

But we relay on OS for such stuff...

> Anyway I like the simplicity of your solution, it seems easy to build on.
>
> Another minor question : what is the rational in choosing std::string in
> the interface instead of const char* ?
>

Why not? std::string is convertable from char const * also "creating string"
price is quite negligible in comparison to loading library...

Artyom

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Request for Interest in several Modules

thorsten.ottosen
In reply to this post by Artyom Beilis
Den 10-01-2012 16:11, Artyom Beilis skrev:
> Hello,
>
>
> I have several modules/libraries I developed and released under Boost License.
>
> - CppDB Sql Connectivity
> - Stack Trace
> - Shared Object Loading
> - Nowide UTF-8 friendly standard C/C++ library API.


I'm very interested in the first three. So please go ahead and find
a review manager and start boosty-fying.

The fourth I don't know about. Can't Boost.FileSystem do all that?

-Thorsten

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123