how to copy a structure to a cstring

[rout....@gmail.com]

I am working on a project to form a clustering algorithm. Actually I have created a struct which I have to copy to constant char* so that to pass it as a string. I am trying like this below to setWsmData as a cstring in the below function "sendMessage" and to receive the sent value in getWsmData in the function "onData" :

File:- pedcluster.h
====================
class PedCluster:: public BaseWaveApplayer {
...
protected:
void sendMessage(std::string blockedRoadId) ;

struct cluster{
int clustNum;
std::string messageName;
....
};
}

File:- pedcluster.cc
====================
void PedCluster::sendMessage(std::string blockedRoadId) {
sentMessage = true;

t_channel channel = dataOnSch ? type_SCH : type_CCH;

cluster *form = new cluster{2, "invite"};

const char* hello;
memcpy(hello, form, sizeof(form));
blockedRoadId = std::string (hello);

WaveShortMessage* wsm = prepareWSM("data", dataLengthBits, channel, dataPriority, -1, 2);

wsm->setWsmData(blockedRoadId.c_str()); // Output gives garbage value

sendWSM(wsm);
}

void PedCluster::onData(WaveShortMessage* wsm) {

if (!sentMessage) sendMessage(wsm->getWsmData());

const char* hello = {wsm->getWsmData()};

const cluster *form = reinterpret_cast <const cluster*>(hello);

}

File:- WaveShortMessage.cc
===========================
const char * WaveShortMessage::getWsmData() const
{
return wsmData_var.c_str();
}

void WaveShortMessage::setWsmData(const char * wsmData)
{
this->wsmData_var = wsmData;
}

I think there is a mistake in these lines below, which I have written above:

const char* hello;
memcpy(hello, form, sizeof(form));
blockedRoadId = std::string (hello);

Could you please help me to solve this,so that pass the data of the struct in setWsmData.

Thanks

[Öö Tiib]

On Thursday, 20 October 2016 21:36:50 UTC+3, rout....@gmail.com wrote:
>
> I am working on a project to form a clustering algorithm. Actually I
> have created a struct which I have to copy to constant char* so that to
> pass it as a string. I am trying like this below to setWsmData as a
> cstring in the below function "sendMessage" and to receive the sent value
> in getWsmData in the function "onData" :

Huh? Passing contents of structs around as strings is something that
is needed for nothing I can imagine in "clustering algorithm".

> I think there is a mistake in these lines below, which I have written above:
>
> const char* hello;
> memcpy(hello, form, sizeof(form));
> blockedRoadId = std::string (hello);

You are correct. That slice of code is worse than a bad joke, sorry.

>
> Could you please help me to solve this,so that pass the data of the struct in setWsmData.

You seemingly underestimate complexity of task of passing data around
as texts.

You likely should first read FAQ on serialization.
https://isocpp.org/wiki/faq/serialization

Then most simple for you is perhaps to learn to use stream I/O and
'std::stringstream' class.

However most beneficial for you is perhaps to learn to use some library
that serializes/deserializes into JSON. http://www.json.org/ contains
links to some such C++ libraries.

Pick your poison!

[Shivu]

Thanks Tiib for your suggestions.
I am very new to c++.

[Vir Campestris]

On 20/10/2016 19:35, rout....@gmail.com wrote:
> const char* hello;
> memcpy(hello, form, sizeof(form));

Those two lines, in English are:

1) Here is a pointer to some memory. It's not set up to point to any
particular memory, it's just to a random location in the system.

2) Copy the contents of "form" into the random location.

FWIW I always feel that in C++ if you're using a raw pointer you're
probably doing it wrong. Not always, but usually. And read about JSON
like Öö says!

Andy

[Shivu]

On Thursday, October 20, 2016 at 10:49:23 PM UTC+2, Vir Campestris wrote:

Thanks Andy.

[Barry Schwarz]

On Thu, 20 Oct 2016 21:49:11 +0100, Vir Campestris
<vir.cam...@invalid.invalid> wrote:

>On 20/10/2016 19:35, rout....@gmail.com wrote:
>> const char* hello;
>> memcpy(hello, form, sizeof(form));
>
>Those two lines, in English are:
>
>1) Here is a pointer to some memory. It's not set up to point to any
>particular memory, it's just to a random location in the system.

And perhaps more importantly, any data it eventually points to should
be treated as constant.

>2) Copy the contents of "form" into the random location.

And even when hello points to valid memory, attempting to update this
memory via a pointer to const causes undefined behavior.

>FWIW I always feel that in C++ if you're using a raw pointer you're
>probably doing it wrong. Not always, but usually. And read about JSON

>like 嘱 says!
>
>Andy

--
Remove del for email

[woodb...@gmail.com]

I disagree with that. I use std::unique_ptr some, but raw pointers
work well in a lot of cases. I have an archive on this page:

http://webEbenezer.net/build_integration.html

that shows limited use of smart pointers and liberal use of
raw pointers.

> And read about JSON
> like Öö says!
>

I work on an alternative to JSON.


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Öö Tiib]

On Friday, 21 October 2016 07:43:45 UTC+3, woodb...@gmail.com wrote:
> On Thursday, October 20, 2016 at 3:49:23 PM UTC-5, Vir Campestris wrote:
> > On 20/10/2016 19:35, rout....@gmail.com wrote:
> > > const char* hello;
> > > memcpy(hello, form, sizeof(form));
> >
> > Those two lines, in English are:
> >
> > 1) Here is a pointer to some memory. It's not set up to point to any
> > particular memory, it's just to a random location in the system.
> >
> > 2) Copy the contents of "form" into the random location.
> >
> > FWIW I always feel that in C++ if you're using a raw pointer you're
> > probably doing it wrong. Not always, but usually.
>
> I disagree with that. I use std::unique_ptr some, but raw pointers
> work well in a lot of cases.

Smart pointers are not the only replacement to raw pointer in C++.
There are references, containers, indexes, iterators etc. As result
I know only few cases where I have to declare something to be
of type raw pointer to something else.

> I have an archive on this page:
>
> http://webEbenezer.net/build_integration.html
>
> that shows limited use of smart pointers and liberal use of
> raw pointers.

Please name at least 3 different cases where you need raw pointer and
why. Making people to dig in your poorly documented code base to try to
find it out themselves is fruitless, they don't have time for that.

>
> > And read about JSON
> > like Öö says!
> >
>
> I work on an alternative to JSON.

JSON is language neutral, so your C++ code generator can not replace its
main use-cases.

[woodb...@gmail.com]

On Friday, October 21, 2016 at 1:33:10 AM UTC-5, Öö Tiib wrote:
> On Friday, 21 October 2016 07:43:45 UTC+3, woodb...@gmail.com wrote:
> > On Thursday, October 20, 2016 at 3:49:23 PM UTC-5, Vir Campestris wrote:
> > > On 20/10/2016 19:35, rout....@gmail.com wrote:
> > > > const char* hello;
> > > > memcpy(hello, form, sizeof(form));
> > >
> > > Those two lines, in English are:
> > >
> > > 1) Here is a pointer to some memory. It's not set up to point to any
> > > particular memory, it's just to a random location in the system.
> > >
> > > 2) Copy the contents of "form" into the random location.
> > >
> > > FWIW I always feel that in C++ if you're using a raw pointer you're
> > > probably doing it wrong. Not always, but usually.
> >
> > I disagree with that. I use std::unique_ptr some, but raw pointers
> > work well in a lot of cases.
>
> Smart pointers are not the only replacement to raw pointer in C++.
> There are references, containers, indexes, iterators etc. As result
> I know only few cases where I have to declare something to be
> of type raw pointer to something else.
>

I use references and containers also. The pointers that
remain after that are what I'm talking about.

> > I have an archive on this page:
> >
> > http://webEbenezer.net/build_integration.html
> >
> > that shows limited use of smart pointers and liberal use of
> > raw pointers.
>
> Please name at least 3 different cases where you need raw pointer and
> why. Making people to dig in your poorly documented code base to try to
> find it out themselves is fruitless, they don't have time for that.

The documentation isn't very good, but people are free to
take a look a look as you did in a recent thread about std::deque.

> > I work on an alternative to JSON.
>
> JSON is language neutral, so your C++ code generator can not replace its
> main use-cases.

Did the OP say he needs support for multiple languages?

I'm open to adding support for other languages, but I'm
waiting to see how things shake out. C++ is a sure thing.
Other languages aren't as obvious to me.

[Mr Flibble]

He didn't mean that; he meant you don't have to compile JSON because
JSON is just text not a programming language.

/Flibble

[Öö Tiib]

Yes, CMW code generator of Brian can not compete with JSON because JSON
is not in same niche of Brian's CMW. The issues solved are orthogonal.
Most of the systems producing JSON are not even written in C++.
Therefore we can't replace JSON with CMW even if we wan't to.
Brian however can offer JSON as an optional alternative to his custom
binary format that his generated code transfers. That can make his CMW
stand somewhat stronger.
Brian does not seemingly recognize that cooperation and compatibility
are strengths but alienating and competition are waste of time.

[Chris Vine]

On Fri, 21 Oct 2016 15:06:44 -0700 (PDT)
woodb...@gmail.com wrote:
> On Friday, October 21, 2016 at 1:33:10 AM UTC-5, Öö Tiib wrote:
> > Please name at least 3 different cases where you need raw pointer
> > and why. Making people to dig in your poorly documented code base
> > to try to find it out themselves is fruitless, they don't have time
> > for that.
>
> The documentation isn't very good, but people are free to
> take a look a look as you did in a recent thread about std::deque.

You haven't answered the question. Please name at least 3 different
cases where you need raw pointers and why. (Actually, I would be
satisfied by 2, provided they didn't amount to evading the issue, but I
cannot speak for your interlocutor).

[JiiPee]

On 21/10/2016 07:32, Öö Tiib wrote:
> I know only few cases where I have to declare something to be
> of type raw pointer to something else.

You need a raw pointer if you want a polymorhism and you dont want to
own the object.


like:

class Player

{

public:

private:

Renderer* m_renderer; // draws the object

};


now m_renderer can be used as polymorhic pointer to call whatever we
want to have the renderer. And we can live change the renderer...

[Mr Flibble]

Just because you are lacking the experience to know where to use a raw
pointer doesn't mean you can demand that information from someone else.

Three use cases for raw pointers immediately come to mind:
1) Pointers to array elements (preferable to using indices)
2) Non-owning pointer to a polymorphic type the value of which can be
changed at runtime to point to different objects.
3) Opaque raw pointer used as a handle (type erasure or interfacing with
C API)

I am sure there are plenty of others.

/Flibble

[Öö Tiib]

On Saturday, 22 October 2016 03:32:44 UTC+3, Mr Flibble wrote:
> On 22/10/2016 00:22, Chris Vine wrote:
> > On Fri, 21 Oct 2016 15:06:44 -0700 (PDT)
> > woodb...@gmail.com wrote:
> >> On Friday, October 21, 2016 at 1:33:10 AM UTC-5, Öö Tiib wrote:
> >>> Please name at least 3 different cases where you need raw pointer
> >>> and why. Making people to dig in your poorly documented code base
> >>> to try to find it out themselves is fruitless, they don't have time
> >>> for that.
> >>
> >> The documentation isn't very good, but people are free to
> >> take a look a look as you did in a recent thread about std::deque.
> >
> > You haven't answered the question. Please name at least 3 different
> > cases where you need raw pointers and why. (Actually, I would be
> > satisfied by 2, provided they didn't amount to evading the issue, but I
> > cannot speak for your interlocutor).
>
> Just because you are lacking the experience to know where to use a raw
> pointer doesn't mean you can demand that information from someone else.

Why to be so pointlessly patronizing? It smells like Jerry
Stuckle or Rick C. Hodgin and so is good to avoid.

>
> Three use cases for raw pointers immediately come to mind:
> 1) Pointers to array elements (preferable to using indices)

One strong reason why to use raw array is that string literal
is raw array and other is that array dimensions can be deduced from
initializers. Both cases matter about static immutable arrays.
AFAIK the plans about C++17 are to add 'std::array_view' and
'std::string_view' to remove or to reduce those reasons, but I am
not too hopeful about it.

> 2) Non-owning pointer to a polymorphic type the value of which can be
> changed at runtime to point to different objects.

Again it is unclear where we *must* use raw pointer as mutable reference
to non-owned object. What owns it and how? We likely can use raw pointer
but usually other things (like 'std::reference_wrapper', 'std::weak_ptr'
or some iterator) are more suitable.

> 3) Opaque raw pointer used as a handle (type erasure or interfacing with
> C API)

Both the 'std::shared_ptr' and 'std::unique_ptr' can be to opaque type
(unlike 'std::auto_ptr'). There just are some constraints.

For example on case of class with unique-to-opaque member there is
little constraint that rule of zero causes compiler errors and so
developer has to use rule of five.

The smart pointers are useful for wrapping opaque pointers from C API:

using unique_file_ptr = std::unique_ptr<std::FILE, int (*)(std::FILE*)>;

static
unique_file_ptr make_file(const char* filename, const char* flags)
{
return unique_file_ptr(std::fopen(filename, flags), std::fclose);
}

Again if we need a *shared* file pointer then there is little constraint
that we need to make it so that shared_ptr does not call fclose to null
pointer, unique_ptr is smart enough on its own so above works.

>
> I am sure there are plenty of others.

There may be few. For example we need raw pointer as covariant return
type (on the rare case when we need it).

However I wanted to hear some from WoodBrian because he claimed that his
code base is full of such usages where raw pointer is best. Like Chris
pointed out he failed to name any.

[Öö Tiib]

All smart pointers I know of have been designed to be useful for
dynamically polymorphic pointers. Actually most of the "weight"
of smart pointers is (somewhat invisibly to users) in support of
such polymorphism.

class Player
{
public:
// ...
private:
// ...
std::unique_ptr<Renderer> renderer_; // draws the object
};

[Gareth Owen]

Öö Tiib <oot...@hot.ee> writes:

> The smart pointers are useful for wrapping opaque pointers from C API:
>
> using unique_file_ptr = std::unique_ptr<std::FILE, int (*)(std::FILE*)>;
>
> static
> unique_file_ptr make_file(const char* filename, const char* flags)
> {
> return unique_file_ptr(std::fopen(filename, flags), std::fclose);
> }

You have to be careful with the latter, as fclose(NULL) is UB.

[Chris M. Thomasson]

FWIW, I use raw pointers when implementing synchronization primitives.

Structures like:
__________________________________
struct node
{
std::atomic<node*> next;
};

struct stack
{
std::atomic<node*> head;
};
__________________________________

are fairly common.

Also, you will probably see raw pointers in implementations of
std::malloc, operator new and friends.

[Öö Tiib]

I am. Why you erased next sentence of mine that already addressed it?:

"Again if we need a *shared* file pointer then there is little constraint
that we need to make it so that shared_ptr does not call fclose to null
pointer, unique_ptr is smart enough on its own so above works."

If you wanted same function for 'shared_ptr' then I can try to make one:

using shared_file_ptr = std::shared_ptr<std::FILE>;

static
shared_file_ptr open_shared_file(const char* filename, const char* flags)
{
auto fp = std::fopen(filename, flags);
return fp != n ? shared_file_ptr(fp, std::fclose) : shared_file_ptr();
}

[JiiPee]

mutta unique pointer defines who owns the renderer. If this player does
not own it it would be wrong to use unique pointer but rather a raw
pointer. I know Bjarne has said similar thing (like: "if its not about
ownership, you can use old raw pointer ..." )


But if the player owns the renderer, then unique pointer would be best.
but obviously here it does not...

[Öö Tiib]

Yes. In implementations of all the primitives like containers or
smart pointers. ;) These things are what remove raw pointers from
usual abstraction level we work at. Most of the time we are not
implementing yet another smart pointer or container but we use
one from *HUGE* pile of already existing, well designed and well
tested ones.

[Öö Tiib]

"Mutta" means "but"?

> If this player does
> not own it it would be wrong to use unique pointer but rather a raw
> pointer. I know Bjarne has said similar thing (like: "if its not about
> ownership, you can use old raw pointer ..." )

Sure, we still may use raw pointers for whatever we want to. Pointers are
part of language. I indeed *may* but if I choose some alternative then
all is usually even better. For example for non-owning relations I
prefer references, non-owning smart pointers (like weak_ptr) or iterators
(when real owner is collection).