Nabble - Gnu - Common C++

Problem with commoncpp serial

2009-12-11T04:37:27Z

Hello,

For a project I'm using Commoncpp and its Serial support. But I'm seeing some weird behavior when reading from a serial device (modem).
Sometimes after a while, isPending(pendingInput) gives back true and then using uflow for reading one character, results in a EOF. (and this results in a loop) How is this possible? (The device did not send anything). Is it an error on the serial port?

How is this possible? Do I something wrong, is it a bug or is it some problem with my system?

My system:
Linux Ubuntu 9.04
Commoncpp 1.7.3
GCC 4.3.3
Onboard serial port and usb to serialconverter.
Siemens and Wavecom modem.

Output of the test program:
43 - +
67 - C
82 - R
69 - E
71 - G
58 - :
32 -
49 - 1
13 -
10 -

13 -
10 -

43 - +
87 - W
73 - I
78 - N
68 - D
58 - :
32 -
52 - 4
13 -
10 -

-1 - �
-1 - �
-1 - � <-------- how is this possible??
-1 - �
-1 - �

I have made a little example to demonstrate the problem.

main.cc
#include <stdlib.h>
#include "Modem.h"

/*
*
*/
int main(int argc, char** argv)
{

    Modem modem("/dev/ttyS0");
    modem.run();

    return (EXIT_SUCCESS);
}

Modem.h
#ifndef _MODEM_H
#define    _MODEM_H

#include <cc++/serial.h>

class Modem : ost::ttystream {
public:
    Modem(std::string device);
    virtual ~Modem();

    void run();
private:

};

#endif    /* _MODEM_H */

Modem.cc
#include "Modem.h"

Modem::Modem(std::string device) : ost::ttystream((char*)device.c_str())
{
    interactive(true);
    if (setSpeed(9600)) std::cout << getErrorString() <<std:: endl;
    if (setCharBits(8)) std::cout << getErrorString() << std::endl;
    if (setParity(ost::Serial::parityNone)) std::cout << getErrorString() << std::endl;
    if (setStopBits(1)) std::cout << getErrorString() << std::endl;
    if (setFlowControl(ost::Serial::flowHard)) std::cout << getErrorString() << std::endl;
}

Modem::~Modem()
{
}

void Modem::run()
{
    while(1){
        while(isPending(ost::Serial::pendingInput)){
            int ch = uflow();
            std::cout << (int)ch << " - " << (char)ch << std::endl;
        }
        sleep(1);
    }
}

Met vriendelijke groet,
Mark Ebbers

I-Real
Postbus 593
7000 AN Doetinchem
T: +31 (0)314 366600
F: +31 (0)314 363410
E: m.ebbers@...
I: www.i-real.nl

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

gcc/g++ on Cygwin in Windows 7. I installed cygwin on windows 7,

2009-11-28T15:11:16Z

The current cygwin intall uses gcc/g++ 3.4.5, and on Windows 7 the stream out to console via cout and printf do not print anything to the console. Does anyone know why?

Thanks-

-Steve Farris

URLStream timeout problem

2009-09-02T08:44:29Z

hi,

When I use setTimeout() to URLStream object
it do not performing a non-blocking connect().
Unless I also set TCPStream::timeout be non zero.

in URLStream.hpp line 403

inline void setTimeout(timeout_t to)
{
timeout = to;
TCPStream::timeout = to;
};

The timeout value in URLStream seems only workable for readline().
Could you make it non-blocking in the next release?

thanks

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

Re: TCPtream bug

2009-09-02T06:24:13Z

Probably instead, connect methods should actually do this if the so is
invalid when they are called. If we do fail to connect, we should
release the resource as we do now. If we decide to close/delete the
object on a connect failure, then we would not be waisting resources
acquiring a brand new socket we may never use. Part of this is also
tied to the use of connect as a constructor method, where the object is
then in a clean state with no socket held if the connect failed at
initialization. But either way, I will look at resolving this for the
next release.

Vincent Chen wrote:

> hi,
>
> I recently found TCPStream bug when performing TCPStream::open().
> here is my code:
>
> TCPStream client;
> client.setTimeout(5000); //this will let connect() function be non-block
> while(1)
> {
> client.connect(IPV4Host, port, buffer);
> if(!client.isConnected())
> {
> ::usleep(1000000*3);
> continue;
> }
> }
>
> Once the first run in connect() failed, it will keep connecting to
> indicated IP and port
> but the 2nd time it connect, will cause the socket error (I print out
> the errno)
>
> I found the socket do not re-initialize when connect() failed.
> if add the code in line 3125
>
> so = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
>
> it will work well
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Bug-commoncpp mailing list
> Bug-commoncpp@...
> http://lists.gnu.org/mailman/listinfo/bug-commoncpp

[dyfet.vcf]

begin:vcard fn:David Sugar n:Sugar;David org:GNU Telephony email;internet:dyfet@... tel;work:+1 609 465 5336 url:http://www.gnutelephony.org version:2.1 end:vcard

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

TCPtream bug

2009-08-29T01:27:13Z

hi,

I recently found TCPStream bug when performing TCPStream::open().
here is my code:

TCPStream client;
client.setTimeout(5000); //this will let connect() function be non-block
while(1)
{
client.connect(IPV4Host, port, buffer);
if(!client.isConnected())
{
::usleep(1000000*3);
continue;
}
}

Once the first run in connect() failed, it will keep connecting to indicated IP and port
but the 2nd time it connect, will cause the socket error (I print out the errno)

I found the socket do not re-initialize when connect() failed.
if add the code in line 3125

so = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

it will work well

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

Linker error msg

2009-07-22T12:40:28Z

I am using g++ 4.0 on a MacBook Pro via Apple's Xcode 3.0 development
interface. Originally I had tried to compile and link this code
directly but generated a huge list of compiler errors. Obviously I was
not setting appropriate parameters despite experimentation

Now I get clean compilations but get Link error msgs saying "Duplicate
symbol _p in main and another routine". I am not using this symbol
anywhere in my code

Any recommendations would be appreciated. This is a fairly large sized
bit of code. I'm successfully running some related code under g++ and
welcome the performance improvement. The errant code runs fine under
Visual C++ 5.0 and with Microsoft's Visual C++ 2008 Express Edition

I've searched Apple's knowledge base without any meaningful result

--
David

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

usage information

2009-04-27T11:24:27Z

Hi, I am a novice in C++ programming, so be patient with me. Is there a specific location where the usage notes and all classes/functions are explained in detail (especially threads)? I am on fedora 11 beta, using netbeans IDE for development.
Thx
Bernhard Schuster

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

Open source my OIOIC, a completely new object-oriented mechanism for the C.

2009-03-11T22:37:43Z

OIOIC is a completely new object-oriented mechanism for the C programming language.
Please download the "OIOIC-Primer-2nd-Edition-English.tar.gz". (the English version of << OIOIC Primer >> )
http://code.google.com/p/oioic/downloads/list

Welcome your advice!

Using OIOIC, you can describe the flower, birds, grass, insects, trees, houses ...
Using OIOIC, you can describe the elements, atoms, protons, electrons ...
Using OIOIC, you can describe the earth, the sun, the Milky Way galaxy, collapsar ...
Using OIOIC, you can describe ...

1. OIOIC perfectly supplies the gap of object-oriented technology for the C programming language;
2. OIOIC perfectly solved the multiple inheritance problem in the Software World;
3. OIOIC perfectly objectivizes multithreading access control of object;
4. OIOIC unifies the norm of components in the Software World;
5. OIOIC unifies the structure of code tree in the Software World;
6. OIOIC unifies the thinking of object-oriented programming in the Software World;
7. OIOIC unifies all advanced programming languages in the Software World, to make the C programming language as the preferred.

Error compiling commoncpp2 1.7.0 on RHEL5

2009-01-28T15:35:21Z

I ran into the following error message trying to compile commoncpp2 version 1.7.0 under RedHatEnterpriseLinux 5.2.0:

nat.cpp: In function "char* ost::natErrorString(ost::natResult)":

nat.cpp:365: error: new declaration "char* ost::natErrorString(ost::natResult)"

nat.h:89: error: ambiguates old declaration "const char* ost::natErrorString(ost::natResult)"

There appears to be a missing "const " at the beginning of line 365 of nat.cpp. Adding that I can compile without problem.

Hopefully this isn't rehashing a known problem, but a search for natErrorString turned up only an old thread from 2004 relating to missing files in a Windows distribution.

Cheers,

Malcolm Davis

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

parser project needs c++ programmer

2009-01-21T12:57:02Z

I'd like to know if anyone of you would be interested in being payed ($$$)
to program a BNF like parser.
Intermediate to advanced programmer skills required because the project
deals allot with pointers and memory updates and
inter-mixes c/c++/perl code. Anyone interested visit
http://cppcode.angelfire.com/blog/ for futher details

cvv3@...

--
View this message in context: http://www.nabble.com/parser-project-needs-c%2B%2B-programmer-tp21592003p21592003.html
Sent from the Gnu - Common C++ mailing list archive at Nabble.com.

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

Commoncpp2-1.6.3

2008-11-26T05:05:38Z

Hello. Is there any one that work with commoncpp2? I'm trying to run the demo file tcp.cpp, but it doesn't work. I need help.
I'm trying to study the socket api to do a future contribution using dccp protocol.

--
Felipe Leal Coutinho
http://felipelcoutinho.googlepages.com/

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

correction: bug report: gcount() returns 0 when socket is read into contents successfully and then enters half-closed state

2008-09-08T10:10:41Z

The problematic line for the specific case is actually 2910:

Error(errInput, “Could not read from socket”, socket_error);

Regards,

Howell

From: Howell Chen
Sent: Monday, September 08, 2008 10:33 AM
To: 'bug-commoncpp@...'
Subject: bug report: gcount() returns 0 when socket is read into contents successfully and then enters half-closed state

Hi Commoncpp developer,

Playing around commoncpp 1.6.3 code, I met some behavior under following scenario, which I believe as buggy:

1. Peer A and peer B enter a tcp session

2. A sends some contents to B; if no error is reported (tcp subsystem agree to take over whatever needs to be done to deliver), A closes and exit

3. meanwhile, in a loop, peer B receive byte streams through the TCPStream::read, after which follows a call of TCPStream::gcount() to know how many bytes the previous read() has read in – a exit condition for the loop is gcound() returns 0, indicating tcp stream has nothing to read and should be closed to release this tcp resource.

Here comes the bug: the last TCPStrteam::read() actually reads some bytes before its underlying (socket) read returns 0. The 0 return value would immediately call clear(ios::failbit | rdstate() ) (line 2911, src/csocket.cpp, commoncpp-1.6.3), which in turn resets gcount internal data structure _M_gcount to 0, causing the subsequent TCPStream::gcount() returns the incorrect 0.

For a socket read to return 0 is quite normal and legitimate when the peer send FIN and enters the so-called half-close state. TCPStream::read() actually reads correctly all the byte stream that might be queued, but the TCPStream::gcount returning 0 subsequently is definitely conflicting what is expected from a read/gcound with an istream object.

Hope this description serves its purpose well.

Regards,

Howell Chen

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

bug report: gcount() returns 0 when socket is read into contents successfully and then enters half-closed state

2008-09-08T07:33:19Z

Hi Commoncpp developer,

Playing around commoncpp 1.6.3 code, I met some behavior under following scenario, which I believe as buggy:

1. Peer A and peer B enter a tcp session

2. A sends some contents to B; if no error is reported (tcp subsystem agree to take over whatever needs to be done to deliver), A closes and exit

Hope this description serves its purpose well.

Regards,

Howell Chen

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

gcc-4.2.3: unordered_map implementation causes Insure++ PARSE_ERROR

2008-08-06T08:19:50Z

I use Parasoft's Insure++ memory usage analysis tool to detect invalid memory accesses and memory leaks. This tool performs both static and dynamic memory usage analysis by instrumenting the code during the compilation and link phases. Due to a PARSE_ERROR, Insure++ fails to compile code that uses unordered_map:

[hashtable:181] **PARSE_ERROR**

Parse error.
>> template<typename _Key2, typename _Pair, typename _Hashtable>
too few template parameters -- does not match previous declaration

The parse error occurs at line 181 of hashtable [i.e. /usr/include/c++/4.2.3/tr1/hashtable]:

181 template<typename _Key2, typename _Pair, typename _Hashtable>
182 friend struct __detail::_Map_base;

where there appears to be an invalid friend declaration. The specified parameterized struct, __detail::_Map_base, was defined with five parameters in hashtable_policy.h as:

615 template<typename _Key, typename _Value, typename _Ex, bool __unique,
616 typename _Hashtable>
617 struct _Map_base { };

so it seems entirely reasonable that the friendship declaration should also employ five parameters.

I modified the friendship declaration to conform with my expectations as follows (NOTE: there are five parameters):

181 template<typename _Key2, typename _Pair, typename _Ex, bool __unique,
182 typename _Hashtable>
183 friend struct __detail::_Map_base;

and now Insure++ successfully parses the code, gcc successfully parses the code, and my application continues to behave correctly.

QUESTION: Does anyone (with authority on the subject) agree that the current friendship declaration is incorrect? If so, need I do more than I have to realize a fix in a future release of gcc?

... Dave

Re: commoncpp2-1.6.2 vs. Sparc Solaris (9/10)

2008-07-20T16:30:18Z

Maybe this can be wrapped in a configure library test to make sure there
really is a "clock_nanosleep()" to link with? I should see if this is
relevant to ucommon as well...

Reinhard Drube wrote:

> for Solaris one need a change in
>
> src/timer.cpp:
>
> 130,131c130
> < // ::clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &ts, NULL);
> < ::nanosleep(&ts, NULL);
> ---
>> ::clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &ts, NULL);
>
> regards,
> Reinhard
>
>
> _______________________________________________
> Bug-commoncpp mailing list
> Bug-commoncpp@...
> http://lists.gnu.org/mailman/listinfo/bug-commoncpp

[dyfet.vcf]

begin:vcard fn:David Sugar n:Sugar;David org:GNU Telephony email;internet:dyfet@... tel;work:+1 201 215 2609 url:http://www.gnutelephony.org version:2.1 end:vcard

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

commoncpp2-1.6.2 vs. Sparc Solaris (9/10)

2008-07-15T04:30:37Z

for Solaris one need a change in

src/timer.cpp:

130,131c130
< // ::clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &ts, NULL);
< ::nanosleep(&ts, NULL);
---
> ::clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &ts, NULL);

regards,
Reinhard

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

Connecting to TCPSocket as client

2008-06-11T11:15:22Z

Hey everyone,

I'm having a hard time trying to learn how to do this. I can create a TCPSocket and connect to it from a console window using telnet. But how can I connect to it using a C++ program; specifically, I want a thread that connects to a TCP server within the program so it can then send/receive text. It should be something simple that I'm missing (sorry stupid college student here).

tcp example

2008-05-23T13:22:55Z

Hi,
does anyone know why this [1] example don't compile ?
I've tried on Ubuntu 8.04 and Mac Os X. Seens there's a problem with
tcpstream class.

Sory for asking in the wrong place, but I couldn't find help anywhere.

thanks in advance.

[1] http://www.gnu.org/software/commoncpp/docs/refman/html/tcpstr1_8cpp-example.html

---

$ g++ main.cpp -lgnucpp2 -I /opt/local/include/ -L /opt/local/lib
main.cpp: In member function ‘virtual void ThreadOut::run()’:
main.cpp:20: error: ‘tcpstream’ was not declared in this scope
main.cpp:20: error: expected `;' before ‘tcp’
main.cpp:21: error: ‘tcp’ was not declared in this scope
main.cpp: In function ‘int main(int, char**)’:
main.cpp:36: error: ‘tcpstream’ was not declared in this scope
main.cpp:36: error: expected `;' before ‘tcp’
main.cpp:37: error: ‘tcp’ was not declared in this scope

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

Common C++

2008-05-13T20:46:46Z

Common C++

Common C++ is a C++ class library that abstracts various system services in a portable manner, thereby making the creation of portable applications much easier. It is portable code, with very low runtime overhead, that works well on a very wide range of target platforms and C++ compilers in everyday use. It includes the 'ape' project, which was formerly a separate package.

Common C++ manages threads, synchronization, and network sockets by offering portable C++ classes that abstract these services, as well as supporting "serial" I/O, daemon specific event logging, object serialization (persistence), block/record/page/ oriented file I/O, and configuration file parsing. It also provides an inheritable class architecture for your application that exploits C++ as needed.

There are two source trees: one for "POSIX" systems such as GNU/LINUX and the Hurd, the other for the Win 32 API. This makes Common C++ portable at the source level, as the two trees implement a functionally similar class interface.

Msdes
Fexon
Asia

[Fwd: GNU SIP Witch 0.1.0 released (finally), GNU uCommon release candidate also]

2008-04-16T18:43:50Z

I had been largely away the last few months, and I have also been at
times off-grid, working with various American Indian groups, two of whom
have now formally withdrawn, and others who are in the process of
formally withdrawing, from treaty with the governments of the United
States and Canada. I had also been kept occupied full time with other
projects. However, rather than waiting any longer, I have decided this
was a good time to introduce the very first release of GNU SIP Witch and
the first "official release candidate" for GNU uCommmon/GNU Common C++ 2
2.0, and see if we can return to releasing early and often.

GNU SIP Witch is intended to become a pure SIP based office telephone
call server supporting generic phone system features like call
forwarding, hunt groups and call distribution, call coverage and ring
groups, holding and call transfer, as well as offering SIP specific
capabilities such as presence and messaging. GNU SIP Witch supports
using secure telephone extensions, for placing and receiving b2b calls
directly over the internet, and intercept/decrypt-free peer-to-peer
audio and video extensions.

GNU SIP Witch is not a SIP proxy, a multi-protocol telephone server, or
a IP-PBX, and does not try to address the same things like asterisk,
freeswitch, yate, all of which make use of direct media processing.
Instead, GNU SIP Witch focuses on doing one thing as a pure SIP call
server, and will try to do that one thing very well. My goal is to
focus on achieving a network scalable telephone architecture that can be
deeply embedded, which can support secure calling nodes, and that can
integrate well with other SIP based/standards compliant components.

The initial release of GNU SIP Witch offers support of SIP registration,
multi-target registration, authentication peering over SIP, and
registration querying of user agents, basic call processing between
registered user agents only, but including call distribution for
multi-target registrations, and basic SIP instant messaging.

After some discussion, the GNU Project has decided that the uCommon
package, and starting with 1.9.0, is also to be known a release
candidate for what will be the merged GNU Common C++/uCommon which will
effectivily become GNU uCommon 2.0. The original GNU Common C++ 2 1.x
codebase will continue to be maintained with bug fixes, but no new major
features are planned. uCommon has a cleaner model for IPV6 support and
CIDR policy processing, which are critical to the project moving
forward, as well as better ability to integrate with other third party
libraries, and the ability to build very tight embedded profiles in C++.

GNU SIP Witch development has revealed some issues in the original GNU
Bayonne2 SIP module including proper SIP ack handling, the need to
support diversion headers for distinctive greetings on call forwarding
to voice mail, and proper separation between request and to uri's.
These will all be addressed in GNU Bayonne2 release 2.4.0. There will
also be a new release of GNU Bayonne classic (?1.4?) much later this
year built around GNU uCommon and this will include a new SIP driver
based on GNU SIP Witch & GNU Bayonne2 development. This will be used to
offer media application services to embedded GNU SIP Witch nodes.

_______________________________________________
Bayonne-devel mailing list
Bayonne-devel@...
http://lists.gnu.org/mailman/listinfo/bayonne-devel

[dyfet.vcf]

begin:vcard fn:David Sugar n:Sugar;David org:GNU Telephony email;internet:dyfet@... tel;work:+1 201 215 2609 url:http://www.gnutelephony.org version:2.1 end:vcard

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

Missing #ifndef #define

2008-03-23T06:44:12Z

Hello all, I just wanted to let you know that in versions 1.6.1 and 1.5.9 of CommonC++2 the header file located in inc/cc++/pointer.h seems to be missing the following:

#ifndef CCXX_POINTER_H_
#define CCXX_POINTER_H_
....
....
#endif

The addition of these lines to your packages would be much appreciated. FYI I downloaded the tarballs from http://www.gnutelephony.org/dist/tarballs/

-Alan Meekins
Rochester Institute of Technology
Robotics Club

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

Re: Common c++ Thread::notify implementation question.

2008-03-04T12:49:20Z

When a new thread is created, it records the thread instance it was
created from, and this becomes the "parent" reference. However, using
notify requires that the parent does not dissapear (get deleted) before
it's child, and requires tracking of thread meta data. For these
reasons, I actually removed the concept entirely in ucommon. For what
you want to do, the safest way would be to rendezvous on a semaphore or
event object, or use a signaled conditional.

Jim wrote:

> I'm a bit hazy as to what exactly one would do with this method. I'm in
> need of kicking off a detached thread and somehow being able to tell
> when it finishes. Since a detached thread is self deleting, it's
> dangerous to attempt to call any methods after the detach or you risk a
> segfault.
>
> So I see the parameter to the notify method is the thread that as
> terminated. I'm not sure of what can be done with it at this point. Is
> this the same thing you would obtain with a call to the static get method?
>
> The documentation says it "sends a notification to the parent". Can
> someone explain how this might work? A simple example might be nice.
>
> Thanks,
> Jim.
>
>
> _______________________________________________
> Bug-commoncpp mailing list
> Bug-commoncpp@...
> http://lists.gnu.org/mailman/listinfo/bug-commoncpp

[dyfet.vcf]

begin:vcard fn:David Sugar n:Sugar;David org:GNU Telephony email;internet:dyfet@... tel;work:+1 201 215 2609 url:http://www.gnutelephony.org version:2.1 end:vcard

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

Common c++ Thread::notify implementation question.

2008-03-04T06:29:33Z

I'm a bit hazy as to what exactly one would do with this method. I'm in
need of kicking off a detached thread and somehow being able to tell
when it finishes. Since a detached thread is self deleting, it's
dangerous to attempt to call any methods after the detach or you risk a
segfault.

So I see the parameter to the notify method is the thread that as
terminated. I'm not sure of what can be done with it at this point. Is
this the same thing you would obtain with a call to the static get method?

The documentation says it "sends a notification to the parent". Can
someone explain how this might work? A simple example might be nice.

Thanks,
Jim.

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

Re: Where to go to ask questions?

2008-03-02T18:46:59Z

At the moment I am working on merging the ucommon & gnu common c++
codebases into a single core library which has the advantages of both,
as well as greatly reducing complexity for IPV6 addressing support, and
this is anticipated to become GNU Common C++ 2 "2.0" perhaps as early as
June.

Conrad T. Pino wrote:

> The project's founder David Sugar http://savannah.gnu.org/users/dyfet
> has migrated the project's home from time to time which means you'll
> find it and the code in multiple locations; for example:
>
> http://sourceforge.net/projects/cplusplus/
>
> http://www.gnutelephony.org/index.php?title=GNU_Common_C%2B%2B&oldid=224
> http://www.gnu.org/software/commoncpp/
>
> http://savannah.gnu.org/projects/commoncpp/
>
> IMO (but I could be wrong) the latter seems the most recent and complete
> (has a working download page).
>
> David's been active on this list as recently as 24 Nov 2007 so this
> http://lists.gnu.org/archive/html/bug-commoncpp/2007-11/msg00006.html
> mailing list is probably a good place to state your question.
>
> Conrad Pino
>
>> -----Original Message-----
>> From: bug-commoncpp-bounces+conrad=pino.com@...
>> [mailto:bug-commoncpp-bounces+conrad=pino.com@...]On Behalf Of Jim
>> Sent: Friday, February 29, 2008 05:42
>> To: bug-commoncpp@...
>> Subject: Where to go to ask questions?
>>
>>
>> I've been unable to find a forum or mailing list associated with
>> commoncpp. I have a couple of questions about usage.
>>
>> Thanks,
>> Jim.
>
>
>
> _______________________________________________
> Bug-commoncpp mailing list
> Bug-commoncpp@...
> http://lists.gnu.org/mailman/listinfo/bug-commoncpp

[dyfet.vcf]

begin:vcard fn:David Sugar n:Sugar;David org:GNU Telephony email;internet:dyfet@... tel;work:+1 201 215 2609 url:http://www.gnutelephony.org version:2.1 end:vcard

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

RE: Where to go to ask questions?

2008-03-02T08:38:08Z

The project's founder David Sugar http://savannah.gnu.org/users/dyfet
has migrated the project's home from time to time which means you'll
find it and the code in multiple locations; for example:

http://sourceforge.net/projects/cplusplus/

http://www.gnutelephony.org/index.php?title=GNU_Common_C%2B%2B&oldid=224
http://www.gnu.org/software/commoncpp/

http://savannah.gnu.org/projects/commoncpp/

IMO (but I could be wrong) the latter seems the most recent and complete
(has a working download page).

David's been active on this list as recently as 24 Nov 2007 so this
http://lists.gnu.org/archive/html/bug-commoncpp/2007-11/msg00006.html
mailing list is probably a good place to state your question.

Conrad Pino

> -----Original Message-----
> From: bug-commoncpp-bounces+conrad=pino.com@...
> [mailto:bug-commoncpp-bounces+conrad=pino.com@...]On Behalf Of Jim
> Sent: Friday, February 29, 2008 05:42
> To: bug-commoncpp@...
> Subject: Where to go to ask questions?
>
>
> I've been unable to find a forum or mailing list associated with
> commoncpp. I have a couple of questions about usage.
>
> Thanks,
> Jim.

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

Where to go to ask questions?

2008-02-29T05:42:13Z

I've been unable to find a forum or mailing list associated with
commoncpp. I have a couple of questions about usage.

Thanks,
Jim.

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

Patch to fix detection of {bits,ext}/atomicity.h with gcc >=4.2.0

2007-12-24T01:40:29Z

Hi there,

Since the bits/atomicity.h has been moved to ext/atomicity.h for gcc
>=4.2.0, a couple applications depending on commoncpp2 show build errors
>when building.
One part of the patch updates m4/ost_pthread.m4 to check for
ext/atomicity.h as well, the other part adds HAVE_EXT_ATOMICITY.H to
config.h.in and adds a define switch to include the right header-file.

I'd not hardcode either bits/atomicity.h or ext/atomicity.h depending on
the configure-results in the config.h since someone might build/have
built commoncpp with gcc-4.1.0 and then build the app with gcc-4.2.2
(or vice versa).

Cheers,
Tiziano

--
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility: Samba, PostgreSQL, cpp, Python
E-Mail : dev-zero@...
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30

diff -Naur commoncpp2-1.6.1.orig/config.h.in commoncpp2-1.6.1/config.h.in
--- commoncpp2-1.6.1.orig/config.h.in 2007-12-24 09:45:11.000000000 +0100
+++ commoncpp2-1.6.1/config.h.in 2007-12-24 10:25:43.000000000 +0100
@@ -239,6 +239,9 @@
/* Define to 1 if you have the <bits/atomicity.h> header file. */
#undef HAVE_BITS_ATOMICITY_H

+/* Define to 1 if you have the <ext/atomicity.h> header file. */
+#undef HAVE_EXT_ATOMICITY_H
+
/* Define to 1 if you have the <bits/wordsize.h> header file. */
#undef HAVE_BITS_WORDSIZE_H

@@ -1088,7 +1091,11 @@

#if defined(__cplusplus)
#if defined(HAVE_GCC_BITS_ATOMIC) || defined(HAVE_GCC_CXX_BITS_ATOMIC)
+#if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 2))
+#include <ext/atomicity.h>
+#else
#include <bits/atomicity.h>
+#endif
#define HAVE_ATOMIC
#endif
#endif
diff -Naur commoncpp2-1.6.1.orig/m4/ost_pthread.m4 commoncpp2-1.6.1/m4/ost_pthread.m4
--- commoncpp2-1.6.1.orig/m4/ost_pthread.m4 2007-12-24 09:45:11.000000000 +0100
+++ commoncpp2-1.6.1/m4/ost_pthread.m4 2007-12-24 10:12:24.000000000 +0100
@@ -92,7 +92,9 @@
dnl check for gcc's bits/atomicity and the atomic functions therein
AC_CHECK_HEADERS([bits/atomicity.h],
ost_cv_bits_atomicity=yes,
- ost_cv_bits_atomicity=no)
+ [AC_CHECK_HEADERS([ext/atomicity.h],
+ ost_cv_bits_atomicity=yes,
+ ost_cv_bits_atomicity=no)])
if test $ost_cv_bits_atomicity = yes ; then
AC_MSG_CHECKING([for _Atomic_word])
AC_TRY_COMPILE([#include <bits/atomicity.h>],
@@ -103,7 +105,15 @@
],
[ost_cv_gcc_atomic=yes
AC_DEFINE(HAVE_GCC_BITS_ATOMIC, [1], [has gcc atomic functions])],
- [ost_cv_gcc_atomic=no])
+ [AC_TRY_COMPILE([#include <ext/atomicity.h>],
+ [
+ _Atomic_word i = 0;
+ __atomic_add(&i, 1);
+ __exchange_and_add(&i, 1);
+ ],
+ [ost_cv_gcc_atomic=yes
+ AC_DEFINE(HAVE_GCC_BITS_ATOMIC, [1], [has gcc atomic functions])],
+ [ost_cv_gcc_atomic=no])])
AC_MSG_RESULT($ost_cv_gcc_atomic)

AC_MSG_CHECKING([for __gnu_cxx::_Atomic_word])
@@ -117,7 +127,17 @@
[ost_cv_gcc_cxx_atomic=yes
AC_DEFINE(HAVE_GCC_CXX_BITS_ATOMIC, [1],
[has __gnu_cxx atomic functions])],
- [ost_cv_gcc_cxx_atomic=no])
+ [AC_TRY_COMPILE([#include <ext/atomicity.h>],
+ [
+ using namespace __gnu_cxx;
+ _Atomic_word i = 0;
+ __atomic_add(&i, 1);
+ __exchange_and_add(&i, 1);
+ ],
+ [ost_cv_gcc_cxx_atomic=yes
+ AC_DEFINE(HAVE_GCC_CXX_BITS_ATOMIC, [1],
+ [has __gnu_cxx atomic functions])],
+ [ost_cv_gcc_cxx_atomic=no])])
AC_MSG_RESULT($ost_cv_gcc_cxx_atomic)
fi

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

attachment0 (196 bytes) Download Attachment

problem about TCPStream

2007-12-13T05:36:50Z

hi,

I'm using ost:TCPStream to develop a client-server application and i
have a problem when in my server. When i try to receive message from
client using operator >>, it work fine only if there is no space
character in my message.

my class SERVER inherit from ost:TCPStream. And when i received a msg a
method using the code below is called.

string msg;

while( this->isPending(Socket::pendingInput, 1000) && ( !this->eof() ) )
{
*(this) >> msg;
}

For example, if i send "hello world", the server will only receive"hello".

Please can you help me?

thanks

--
Philippe

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

UCommon 1.0 released

2007-11-24T13:21:03Z

The 1.0 release of UCommon was distributed this afternoon. This release
includes full doxygen generated interface documentation, which may be
viewed online at http://www.gnutelephony.org/doxy/ucommon. The
distribution tarball may be found at
http://www.gnutelephony.org/dist/archive/ucommon-1.0.0.tar.gz.

This release includes support for merging existing GNU Common C++
classes into the UCommon codebase to construct a potential GNU Common
C++ 2.0. As such it may be both the first and last complete stand-alone
"release" of UCommon as I intend to merge the two. The 1.0 UCommon
release is hence also intended as a preview and base library set for
developing GNU Common C++ 2.0.

Some classes I plan to retain from the existing GNU Common C++ codebase
include serialization and TCP streaming classes. I am considering doing
a simplified keydata class. Merging of other existing GNU Common C++
classes will be based on user feedback.

Some principle differences between the UCommon codebase and current GNU
Common C++ is simplified but more consistent threading model, clean
unification of IPV4/IPV6 addressing, and a much greater focus on design
patterns. The merged codebase will support targetting both deeply
embedded targets and standard C++ use with other class frameworks. The
build level will be controlled by configure options, and code which
requires C++ standard library support will use either the OLD_STDCPP or
NEWS_STDCPP defines. Otherwise code can be constructed that supports
both generic and deeply embedded build targets.

I may try for a GNU Common C++ 2.0 release candidate before the end of
December. Most likely it will use a ${prefix}/include/gnucommon header
directory for includes and libgnucommon.a library name so it can safely
coexist with earlier versions of GNU Common C++ which used include/cc++
and a libccgnu2/libccext2 library set.

[dyfet.vcf]

begin:vcard fn:David Sugar n:Sugar;David org:GNU Telephony email;internet:dyfet@... tel;work:+1 201 215 2609 url:http://www.gnutelephony.org version:2.1 end:vcard

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

Re: Is anyone still there?

2007-11-15T23:32:03Z

Conrad T. Pino schreef:

You can see if your original message was processed by
visiting the bug-commoncpp mailing list archive page:
http://lists.gnu.org/archive/html/bug-commoncpp/
and following one or more monthly links depending on
when sent.

If it's archived then resending it is pointless.

Thanks, but I did and it wasn't there (still isn't). So that's why I asked.

But since yours isn't there either, I am not sure if this means anything yet.

However, isn't anyone else receiving these messages? Because I just got one again.

Anyway, since you reply, at least some of my messages must be getting through. So I'll hold of on resending for now.

Just so maybe someone else can identify what is going on and can actually do something about it, here's the message I keep getting when I mail to bug-commoncpp@....

Hello

Please get my new email address at

  http://www.drzoom.ch/email.html

Sorry for this, bye...

The site points to someone whose address is something like tobias.???@.... ??? because he says that's where his lastname is supposed to go, yet he doesn't say what it is.

Sorry about the inconvenience,
regards,
Erik

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

bug-commoncpp list - automatic responder messages

2007-11-15T15:40:02Z

From time to time a public mailing list subscriber
may setup automatic responder for sending vacation,
email address change or other notices.

The automatic responder sends to the indicated from
address which the mailing has rewritten to reflect
back into the list and is seen by all subscribers.

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

RE: Is anyone still there?

2007-11-15T15:28:34Z

You can see if your original message was processed by
visiting the bug-commoncpp mailing list archive page:
http://lists.gnu.org/archive/html/bug-commoncpp/
and following one or more monthly links depending on
when sent.

If it's archived then resending it is pointless.

-----Original Message-----
From: bug-commoncpp-bounces+conrad=pino.com@...
[mailto:bug-commoncpp-bounces+conrad=pino.com@...]On Behalf Of E.
van Linstee
Sent: Thursday, November 15, 2007 10:46
To: bug-commoncpp@...
Subject: Is anyone still there?

Because my previous message seems to have elicited a rather unusual
reply. If this one succeeds, I'll retry my previous question.

regards,
Erik

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

Is anyone still there?

2007-11-15T10:45:42Z

Because my previous message seems to have elicited a rather unusual
reply. If this one succeeds, I'll retry my previous question.

regards,
Erik

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

Re: Please don't use the address Bug-commoncpp@gnu.org, please change your addressbook.

2007-11-15T10:43:29Z

Hi,

Are you by any chance the one who is responsible for the message below?
Because it directs me to a site telling me to send mail to someones
first name dot lastname. The site is signed Tobias, but nowhere does it
say what his lastname is. I found yours by searching for Tobias at
profzone.ch.

Sorry for the inconvenience if it is not you.

Regards,
Erik

Bug-commoncpp@... schreef:

> Hello
>
> Please get my new email address at
>
> http://www.drzoom.ch/email.html
>
> Sorry for this, bye...
>
> ------ This is a copy of the message, including all the headers. ------
>
> Received: from mail01.solnet.ch ([212.101.4.135])
> by mail.profzone.ch with esmtp (Exim 3.36 #1)
> id 1IsjXy-000BeY-00
> for te@...; Thu, 15 Nov 2007 19:34:38 +0100
> X-Virus-Scanned: by amavisd-new at mail01.solnet.ch
> Received: from mail01.solnet.ch ([127.0.0.1])
> by localhost (mail01.solnet.ch [127.0.0.1]) (amavisd-new, port 10024)
> with LMTP id AX+hWaq7tf9o for <te@...>;
> Thu, 15 Nov 2007 18:34:32 +0000 (UTC)
> Received: from lists.gnu.org (lists.gnu.org [199.232.76.165])
> (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
> (No client certificate requested)
> by mail01.solnet.ch (Postfix) with ESMTP id 968672FD513
> for <te@...>; Thu, 15 Nov 2007 18:34:32 +0000 (UTC)
> Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
> id 1IsjXh-0001s1-Ou
> for bug-commoncpp@...; Thu, 15 Nov 2007 13:34:21 -0500
> Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
> id 1IsjXf-0001oH-S3
> for Bug-commoncpp@...; Thu, 15 Nov 2007 13:34:21 -0500
> Received: from [199.232.76.173] (helo=monty-python.gnu.org)
> by lists.gnu.org with esmtp (Exim 4.43) id 1IsjXf-0001o2-OJ
> for Bug-commoncpp@...; Thu, 15 Nov 2007 13:34:19 -0500
> Received: from kuber.nabble.com ([216.139.236.158])
> by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
> (Exim 4.60) (envelope-from <bounces@...>) id 1IsjXf-0006AC-4M
> for Bug-commoncpp@...; Thu, 15 Nov 2007 13:34:19 -0500
> Received: from isper.nabble.com ([192.168.236.156])
> by kuber.nabble.com with esmtp (Exim 4.63)
> (envelope-from <bounces@...>) id 1IsjXd-0007TB-Si
> for Bug-commoncpp@...; Thu, 15 Nov 2007 10:34:17 -0800
> Message-ID: <13774032.post@...>
> Date: Thu, 15 Nov 2007 10:34:17 -0800 (PST)
> From: manmach <commoncpp@...>
> To: Bug-commoncpp@...
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> X-Nabble-From: commoncpp@...
> X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3)
> Cc:
> Subject: Mutex does not work on win32/mingw
> X-BeenThere: bug-commoncpp@...
> X-Mailman-Version: 2.1.5
> Precedence: list
> List-Id: Bug reports for Common C++ <bug-commoncpp.gnu.org>
> List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/bug-commoncpp>,
> <mailto:bug-commoncpp-request@...?subject=unsubscribe>
> List-Archive: <http://lists.gnu.org/pipermail/bug-commoncpp>
> List-Post: <mailto:bug-commoncpp@...>
> List-Help: <mailto:bug-commoncpp-request@...?subject=help>
> List-Subscribe: <http://lists.gnu.org/mailman/listinfo/bug-commoncpp>,
> <mailto:bug-commoncpp-request@...?subject=subscribe>
> Sender: bug-commoncpp-bounces+te=profzone.ch@...
> Errors-To: bug-commoncpp-bounces+te=profzone.ch@...
> X-ProfZone-Rcpt: te@...
> X-Envelope-To: te@...
>
>
> It appears that I can enter a mutex from two different threads at the same
> time, which should of course be impossible.
>
> I have made a very simple program to test this. It consists of a test class
> derived from Thread, which in simply enters and leaves the mutex once every
> second.
>
> At the same time the main thread does the same, but twice per second.
>
> As you can see from this little excerpt of the programs output, neither
> thread blocks when it should:
>
> main(): entering test
> 2092: entering test
> main(): leavingtest
> main(): entering test
> 2092: leavingtest
> main(): leavingtest
>
>
>
> This is with version 1.5.7, as 1.5.9 won't even compile.
>
> I am using gcc 3.4.2 mingw to compile.
>
> I have built ccgnu2 1.5.7 by running ./configure, make, make install from
> inside the msys environment.
>
> The exact same code works as expected on Linux (ccgnu 1.5.6 on Ubuntu).
>
>

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp

Mutex does not work on win32/mingw

2007-11-15T08:01:09Z

It appears that I can enter a mutex from two different threads at the same time, which should of course be impossible.

I have made a very simple program to test this. It consists of a test class derived from Thread, which in simply enters and leaves the mutex once every second.

At the same time the main thread does the same, but twice per second.

As you can see from this little excerpt of the programs output, neither thread blocks when it should:

main(): entering test
2092: entering test
main(): leavingtest
main(): entering test
2092: leavingtest
main(): leavingtest

This is with version 1.5.7, as 1.5.9 won't even compile.

I am using gcc 3.4.2 mingw to compile.

I have built ccgnu2 1.5.7 by running ./configure, make, make install from inside the msys environment.

The exact same code works as expected on Linux (ccgnu 1.5.6 on Ubuntu).