soft and program: comp.lang.c++ - 14 new messages in 6 topics

comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en

comp.lang.c++@googlegroups.com

Today's topics:

* Memory contents mysteriously changing - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/d3d7f50cba06cf27?hl=en
* casting from void* to const char * - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/13e7eac70fd0d709?hl=en
* Object (de)serialization - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/9fc67e8f28fe4918?hl=en
* How to get all possible substrings - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/308df61293b64874?hl=en
* bounded buffer - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/89e05f4408614915?hl=en
* memory leaks - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/d9b20823062f2cb3?hl=en

==============================================================================
TOPIC: Memory contents mysteriously changing
http://groups.google.com/group/comp.lang.c++/t/d3d7f50cba06cf27?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 25 2010 2:39 pm
From: Pete Becker

Mark wrote:
> On Jan 23, 2:36 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
>> If you comment out all calls to the library (so that you don't even have
>> to link it in), does the corruption happen? If not, it's the library
>> and you need to look into getting a different one. If yes, then the
>> library has nothing to do with it and you need to start looking at other
>> places in your code.
>
> The answer to your question is: yes, when I comment out all calls to
> the SILO library, the problem goes away. I guess that's pretty strong
> evidence in favor of the library having problems, huh?
>

No, it's not.

> BTW, for that reason I tried upgrading to the most recent release of
> SILO, but I still have the problem.

See? <g>

Memory management problems show up at places that have nothing to do
with the spot where the error actually occurred. And since a memory
management problem typically means that code ends up stomping on memory
that it shouldn't be touching, the effects can seem random. Swapping two
lines of code can make the symptoms disappear; commenting out large
chunks of code can do the same. But often that's just symptoms. The
underlying problem is still there.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

== 2 of 2 ==
Date: Mon, Jan 25 2010 3:33 pm
From: Kaz Kylheku

On 2010-01-21, Mark <markcbaumann@gmail.com> wrote:
> Hello, I've run into a strange bug and I'm not sure how to proceed
> with fixing it. Any suggestions would be most appreciated.

If you're on Linux, run your program using

valgrind --tool=memcheck <yourprog> <args>

Debugging memory corruption problems the hard way is a valuable exercise,
but after you've done it N times, for a sufficiently educational value of N,
you want to UTTL.

Use The Tools, Luke.

==============================================================================
TOPIC: casting from void* to const char *
http://groups.google.com/group/comp.lang.c++/t/13e7eac70fd0d709?hl=en
==============================================================================

== 1 of 5 ==
Date: Mon, Jan 25 2010 3:44 pm
From: "Larry"

Hi!

I have the following struct:

struct cBuffer
{
char data[1024];
int bytesRecorded;
bool flag;
cBuffer(char * data_, int bytesRecorded_, bool flag_) :
bytesRecorded(bytesRecorded_), flag(flag_)
{
memcpy(static_cast<void *>(data), static_cast<void *>(data_),
bytesRecorded);
}
};

I would like to turn char data[1024] to const char data[1024], the same goes
for the constructor:

cBuffer(const char * data_, int bytesRecorded_, bool flag_)...

But then I fail using the memcpy() function because of the wrong cast.

how could I sort that out?

thanks

== 2 of 5 ==
Date: Mon, Jan 25 2010 4:48 pm
From: "Eric Pruneau"

"Larry" <dontmewithme@got.it> a écrit dans le message de news:
4b5e2ccd$0$1144$4fafbaef@reader1.news.tin.it...
> Hi!
>
> I have the following struct:
>
> struct cBuffer
> {
> char data[1024];
> int bytesRecorded;
> bool flag;
> cBuffer(char * data_, int bytesRecorded_, bool flag_) :
> bytesRecorded(bytesRecorded_), flag(flag_)
> {
> memcpy(static_cast<void *>(data), static_cast<void *>(data_),
> bytesRecorded);
> }
> };
>
> I would like to turn char data[1024] to const char data[1024], the same
> goes for the constructor:
>
> cBuffer(const char * data_, int bytesRecorded_, bool flag_)...
>
> But then I fail using the memcpy() function because of the wrong cast.
>
> how could I sort that out?
>

Well your example compile and run fine... what is failling exactly?

Eric Pruneau

== 3 of 5 ==
Date: Mon, Jan 25 2010 5:57 pm
From: Yu Han

> bytesRecorded);
> }
> };
>
> I would like to turn char data[1024] to const char data[1024], the same
> goes for the constructor:
>
> cBuffer(const char * data_, int bytesRecorded_, bool flag_)...
>
> But then I fail using the memcpy() function because of the wrong cast.
>
> how could I sort that out?
>
> thanks
>

--
Yu Han

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

== 4 of 5 ==
Date: Mon, Jan 25 2010 5:59 pm
From: Yu Han

On 01/26/2010 07:44 AM, Larry wrote:
> Hi!
>
> I have the following struct:
>
> struct cBuffer
> {
> char data[1024];
> int bytesRecorded;
> bool flag;
> cBuffer(char * data_, int bytesRecorded_, bool flag_) :
> bytesRecorded(bytesRecorded_), flag(flag_)
> {
> memcpy(static_cast<void *>(data), static_cast<void *>(data_),
See my last post; static_cast<void const*>
> bytesRecorded);
> }
> };
>
> I would like to turn char data[1024] to const char data[1024], the same
> goes for the constructor:
>
> cBuffer(const char * data_, int bytesRecorded_, bool flag_)...
>
> But then I fail using the memcpy() function because of the wrong cast.
static_cast could not cast const to non-const
>
> how could I sort that out?
>
> thanks
>

--
Yu Han

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

== 5 of 5 ==
Date: Mon, Jan 25 2010 6:42 pm
From: "Larry"

"Larry" <dontmewithme@got.it> ha scritto nel messaggio
news:4b5e2ccd$0$1144$4fafbaef@reader1.news.tin.it...

> I have the following struct:

no problem anymore. I have changed to this:

#include <algorithm>

struct buffer
{
char data[1024];
int bytesRecorded;
bool flag;
buffer(const char * data_, const int bytesRecorded_, const bool flag_) :
bytesRecorded(bytesRecorded_), flag(flag_)
{
std::copy(data_, data_ + (bytesRecorded_ * sizeof(char)), data);
}
};

thanks

==============================================================================
TOPIC: Object (de)serialization
http://groups.google.com/group/comp.lang.c++/t/9fc67e8f28fe4918?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 25 2010 3:56 pm
From: Philip Pemberton

On Mon, 25 Jan 2010 12:23:31 -0800, Brian wrote:

> On Jan 25, 1:31 pm, Philip Pemberton <usene...@philpem.me.uk> wrote:
>> Chunk::Serialise calls this->SerialisePayload() to get the payload
>> data, then outputs the header and payload into a vector and returns it.
>> The idea being that the headers are common to all chunks, but payload
>> data depends on the specific class being serialised.
>>
> The above sounds somewhat similar to how I do it, but you've got
> different terminology. I talk about messages, message IDs and message
> lengths. Typically a message id is embedded first into the stream, then
> a message length and then the message/payload.

That's pretty much what I'm doing. Four bytes to tell you what the chunk
is, eight more to specify its length, then a <length>-sized block of data
(the Payload).

Same concept, different terminology.

== 2 of 2 ==
Date: Mon, Jan 25 2010 4:19 pm
From: Philip Pemberton

On Mon, 25 Jan 2010 21:31:55 +0100, Thomas J. Gritzan wrote:

>> At this point I haven't even managed to get an example implementation
>> of the C++FAQ deserialiser working -- the static ctors aren't being
>> called, so the std::map doesn't contain anything, thus the code bombs
>> (current version throws an exception, the one I posted segfaults)...
>
> The map isn't filled because you don't create triangle, so the line
> creationMap["triangle"] = new Triangle();
> isn't executed. You have to move this line somewhere else so that it's
> invoked before you use creationMap, like a registerShape function
> that'll be called from main.

I've actually shuffled it into a "TriangleInitialiser" class --

static class TriangleInitialiser {
public:
TriangleInitialiser() {
cerr<<"ctor: TriangleInitialiser\n";
if (Shape::creationMap.count("triangle") == 0) {
Shape::creationMap["triangle"] = new
Triangle();
}
}
} _x_Initialiser_Triangle;

(Obviously this is a test, and any real code would be hiding the map
behind a couple of functions -- RegisterPrototype and FreePrototypes)

This stays in Triangle.cpp and isn't referenced by (or even accessible
by, thanks to the static prefix). That leaves the problem of deallocating
the memory (admittedly only a few bytes, but it's still more fluff to
wade through in the Valgrind log). Adding a destructor to Shape deals
with that:

~Shape() {
// dealloc the prototypes
while (!creationMap.empty()) {
std::map<std::string, Shape *>::iterator
i = creationMap.begin();
Shape *x = (*i).second;
creationMap.erase(i);
delete x;
}
};

The catch being that the "delete x" invokes ~Shape again, thus (AIUI) it
will consume one stack level for each prototype in the map... I've had a
quick play, but it doesn't seem to be possible to specify that a
destructor applies to the base class, but not any derived classes.

I didn't use an iterator loop because AIUI calling erase() on a container
or map invalidates any iterators active against it. The "Shape *x" is
there for a similar reason.

> But instead using this prototype based meachanism, I suggest using a
> factory functor and storing a boost::function in creationMap, if you
> have access to Boost (std::tr1::function is the same). Example:
(snip code)

That looks better than my solution, but I'm not keen on adding Boost to
my application's build dependencies. As nice as it is, it's an utter pig
to build on Win32 (IIRC last time I did it, I had to build Cmake, which
was great fun). Dead easy on *nix, but unfortunately this code has to
work in the Evil Empire too...

The only other thing I'm not keen on is having to hack around with main()
to add new chunks, although that's probably solvable by putting the
registration stuff in a static class's ctor or a global
RegisterChunkDeserialisers() function.

Still not as nice as just being able to create a module with two classes,
and have that module auto-initialise and register on startup (see
TriangleInitialiser above). But that said, I'm still concerned about what
happens if the TriangleInitialiser object gets initialised before
Shape... unless the compiler is clever enough to figure out that Shape
needs setting up first (probably not, even though it is gcc).

Thanks,
Phil.

==============================================================================
TOPIC: How to get all possible substrings
http://groups.google.com/group/comp.lang.c++/t/308df61293b64874?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Jan 25 2010 4:14 pm
From: Robert Reno

Hello,

I've been searching for some way to get all possible substrings out of
an input string. I've found information and scripts on suffix trees,
but the examples I found only return an array of suffixes (hence the
name I guess)...that is, substrings from progressively splitting off
an initial letter from the string. Has anyone run across a C++
implementation of perl's String::Splitter function? That's the kind
of functionality that I'm looking for.

Thanks,

Robert

== 2 of 3 ==
Date: Tues, Jan 26 2010 12:04 am
From: "crimaniak@googlemail.com"

On 26 янв, 03:14, Robert Reno <nebnetjeru...@gmail.com> wrote:
> Hello,
>
> I've been searching for some way to get all possible substrings out of
> an input string.

Something like this:

$fullLength=strlen($string);
for($begin=0;$begin<$fullLength;++$begin)
for($l=$fullLength-$begin;$l>0;--$l)
echo substr($string,$begin,$l)."\n";

== 3 of 3 ==
Date: Tues, Jan 26 2010 12:08 am
From: "crimaniak@googlemail.com"

On 26 янв, 11:04, "criman...@googlemail.com"
<criman...@googlemail.com> wrote:
> Something like this:
>
> $fullLength=strlen($string);
> for($begin=0;$begin<$fullLength;++$begin)
> for($l=$fullLength-$begin;$l>0;--$l)
> echo substr($string,$begin,$l)."\n";

Oh, no! I was in PHP conference now and this is result. %-)

==============================================================================
TOPIC: bounded buffer
http://groups.google.com/group/comp.lang.c++/t/89e05f4408614915?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 5:26 pm
From: Yu Han

On 01/25/2010 11:00 PM, Larry wrote:
> "Yu Han" <hanjunyu@163.com> ha scritto nel messaggio
> news:hjhjus$1ddr$1@adenine.netfront.net...
>
>> Maybe a circular buffer is better, maybe...
>
> Do you think the following could be fine approach?
>
> // declare
> typedef unsigned int regkey;
> typedef struct {...} buffer;
could you show the body?
>
> // global buffer
> std::map<regkey, buffer> clients
Why not a buffer*?
In your case, buffer must be well defined...

>
> // a client connect (add consumer)
> clients.insert(makepair(regkey, buffer));
>
> // a client disconnect (remove comsumer)
> clients.remove(regkey);
>
> // Producer writes to every element in the map(clients)
> (...)
>
> thanks

--
Yu Han

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

==============================================================================
TOPIC: memory leaks
http://groups.google.com/group/comp.lang.c++/t/d9b20823062f2cb3?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 9:41 pm
From: Rolf Magnus

Larry wrote:

>> Yes. In this case it's fairly easy to determine: You used the "new"-
>> operator three times but never the "delete"-operator and never passed
>> on the responsibility for managing the object life times to other
>> functions or objects.
>
> Ok! do you think the following may still lead to memory leaks?

Since that code doesn't allocate memory anymore, it can't leak memory. But
you are making other severe memory access errors.

> #include <windows.h>
> #include <vector>
> #include <cstdlib>
> #include <ctime>
> #include <cstdio>
> #include <boost/circular_buffer.hpp>
> using namespace std;
> using namespace boost;
>
> void getDateTime(char * szTime);
> const int numbuff = 5;
> const int buflen = 30;
>
> struct Buffer
> {
> public:
> char * payload;
> int bufferLength;
> int bytesRecorded;
> int user;
> Buffer() : bytesRecorded(0), bufferLength(0), user(0), payload(NULL) { };
> };
>
> int main()
> {
> circular_buffer<Buffer> cb(numbuff);
>
> // Insert elements
> for(int i = 0; i<10; i++)
> {
> // Get time
> char szTime[30]; getDateTime(szTime);
>
> // Init Buff
> Buffer buff;
> buff.user = i;
> buff.payload = szTime;

Note that szTime is local to the loop. It stops existing once the current
loop iteration is done.

> buff.bufferLength = buflen;
> buff.bytesRecorded = buflen;
>
> cb.push_back(buff);
> }
>
> // Show elements:
> for(int i = 0; i<(int)cb.size(); i++)
> {
> printf("%d, %d, %s\n", cb[i].user, cb[i].bufferLength, cb[i].payload);

Here you're accessing objects that don't exist anymore. Anything can happen
here. Why are you using raw arrays of char instead of std::string?
Memory allocation is an advanced topic, so avoid doing it yourself and let
the standard classes handle it for you. That will make it a lot easier.

> }
>
> system("pause");
> return EXIT_SUCCESS;
> }
>
> // getDateTime (Fri, 10 Oct 2008 14:41:59 GMT)
> void getDateTime(char * szTime)
> {
> time_t rawtime = time(NULL);
> struct tm timeinfo;
> gmtime_s(&timeinfo, &rawtime);
> strftime(szTime, 30, "%a, %d %b %Y %X GMT", &timeinfo);
> }
>
> thanks

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en

To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

soft and program

Tuesday, January 26, 2010

comp.lang.c++ - 14 new messages in 6 topics - digest

No comments:

Blog Archive

About Me