Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Lightningfalcon]

Any sort of criticsm is greatly appreciated.  I can't get better if I don't know what I'm doing wrong.   

[Skyrunner]

None for me? :<

[da_nang]

Brushing up on C++ again. Would the following class remain immutable during its entire lifetime (Assuming passed constuctor parameters are also immutable)?

class Foo {

const A a;

public:
A(const A & a);//Initialized with initializer list

}

The reason I'm wondering is that I figured I can't use pointers since their memory can be freed and I want to avoid copying memory as much as possible.
What if I passed the contents of a pointer then deleted the pointer and freed the memory? What would happen to the reference? Or do I simply have to copy the memory (by removing the &) to be sure?

[cerapa]

I don't think I understand the question...

const A a;
means that the class contains an A, which won't change, ever. It doesn't matter where the value comes from, as the class has it's own A, not a pointer or a reference.

[da_nang]

I don't think I understand the question...

const A a;
means that the class contains an A, which won't change, ever. It doesn't matter where the value comes from, as the class has it's own A, not a pointer or a reference.

True. However, if A is large then is there a way to avoid copying a large block of memory and still retain immutability? IIRC, one of the points of passing references was to avoid copying large blocks of memory.

EDIT: That is, const A is open to change if said change retains immutability and is more efficient.

[ECrownofFire]

Use a std::unique_ptr so that you guarantee the memory will not be freed and that no outside access will occur.

[da_nang]

Use a std::unique_ptr so that you guarantee the memory will not be freed and that no outside access will occur.

Reading the documentation suggests that this is a bit too limiting in that it is a one-to-one relationship between pointer and object. I think std::shared_ptr might be better for a many-to-one relationship. If the object being pointed to is immutable, then the Foo class should also retain immutability and no memory is wasted.

[alway]

Or just do things the right way. http://en.wikipedia.org/wiki/Const-correctness#Pointers_and_references

Typename const * instanceName;

const Typename thingBeingPointedTo = stuff;

instanceName = &thingBeingPointedTo;

You can thus put your thingBeingPointedTo wherever you want in memory, and have a pointer to it in your class. That pointer can be redirected to point at other things, but the things themselves cannot be changed. If you don't want it to redirect either, use

Typename const * const instanceName;

[da_nang]

Or just do things the right way. http://en.wikipedia.org/wiki/Const-correctness#Pointers_and_references

Typename const * instanceName;

const Typename thingBeingPointedTo = stuff;

instanceName = &thingBeingPointedTo;

You can thus put your thingBeingPointedTo wherever you want in memory, and have a pointer to it in your class. That pointer can be redirected to point at other things, but the things themselves cannot be changed. If you don't want it to redirect either, use

Typename const * const instanceName;

Wouldn't this force copying the Typename instance?
See here's what I'm trying to do. I have a immutable class A that in some way needs to access an instance of an immutable class B injected at A's construction. Let's also say class B is rather large. The problem is how would I construct A such that the instance of B is not created within A (but only exists outside A as little as possible) and no memory is duplicated needlessly since said instance of B can be shared by different A:s? Think in terms of normalized databases.

[Maklak]

I have a lot of trouble understanding you and it is about as frustrating as talking to a java programmer.

By "B is immutable" I assume you mean "It has some private variables and getters, but no setters and everything is set by a public multi-parameter constructor".

I think you want something like this:

class B;

class A
{
private: 
  B *bptr;

public:
  A(B *abptr) {bptr = abptr;}

  // methods
};

Then just do:
// Allocate a new object of type B on the heap;
B b = new B(<params>);

A a1(b);
A a2(b);
// Both a1 and a2 point to the same object b. No memory is copied, but make sure to not free b (prematutrely).
// Also feel free to inject const where applicable.

One way to clean up unused Bs would be to remember pointers to all instances of class B in a vector, then have a static method that cleans it when needed. Or if you're only using a few Bs and they exist for the entire lifetime of your program, you can leak memory.
It is even better to use shared_Ptr<B>;


> > Typename const * instanceName;
> > const Typename thingBeingPointedTo = stuff;
> > instanceName = &thingBeingPointedTo;
> Wouldn't this force copying the Typename instance?
Hmm.
The first line declares a pointer to const Typename.
The second line looks like a copy constructor call, but it is OK to just use normal constructor here. Anyway, if B is big and is supposed to have log lifetime, it's place is on the heap, not on stack.
Third line just takes an address and stores it in a pointer, so it doesn't copy anything.


My question: What good are immutable strings? To me they sound like an idea so bad as to rival null-terminated strings. In normal programming languages I can just grab a string and go to town on it: replace parts of it, convert to lowercase, append something at the end and so on. Yet java, C# and a few other languages force me to use workarounds, like StringBuilder. Why?

[MagmaMcFry]

My question: What good are immutable strings? To me they sound like an idea so bad as to rival null-terminated strings. In normal programming languages I can just grab a string and go to town on it: replace parts of it, convert to lowercase, append something at the end and so on. Yet java, C# and a few other languages force me to use workarounds, like StringBuilder. Why?

That's easy to answer. It's because Java and C# don't support constant objects. Consider the following Java code:

Code: [Select]

public final static String IMPORTANT_SYSTEM_VALUE = "foo";
public static void main(String[] args) {
  IMPORTANT_SYSTEM_VALUE.append("bar"); // shit
  runOtherCode();
}
If Java strings were modifiable by "append", then that code would go all kinds of wrong. If Java or C# supported const objects, or passing objects by value, or made strings simple types, then this wouldn't be any kind of issue. But Java and C# did none of those things, so you'll have to deal with immutable strings.
There is actually a motivation behind not being able to do that kind of stuff, namely that this implementation makes execution faster and safer, even though this makes working with strings so much more annoying. But Java and C# were both developed for professional software development companies, and if you ever so much as looked at a software engineering course, you'll know that ease of use is generally the very last thing that those companies worry about when choosing their tools.

[da_nang]

-snip-

AFAIK, an immutable class is a class whose state never changes throughout its lifetime. A state is defined as a tuple which is an element of the cartesian product of the domains of each field in the class.

So if class C has fields int a and std::string b, with domains S_a and S_b, then the state of C is an element of S_a x S_b .
So if C is immutable, that state never changes throughout its lifetime.

And while the easiest way of doing it is just to let C's fields copy the values at construction, this leads to data duplication. This isn't that bad if the fields only take up a small amount of memory as is the case with primitives. However, if the fields take up a large amount of memory, then memory is wasted through data duplication.

Note though, this matters mostly when the relationship between the class and the field is many-to-one i.e. many instances of the class are sharing the same data in their fields. In this case, I figured shared pointers are best suited for the job.

Of course, one could argue about its relevance today when memory is cheap.

> > Typename const * instanceName;
> > const Typename thingBeingPointedTo = stuff;
> > instanceName = &thingBeingPointedTo;
> Wouldn't this force copying the Typename instance?
Hmm.
The first line declares a pointer to const Typename.
The second line looks like a copy constructor call, but it is OK to just use normal constructor here. Anyway, if B is big and is supposed to have log lifetime, it's place is on the heap, not on stack.
Third line just takes an address and stores it in a pointer, so it doesn't copy anything.

Maybe I'm misinterpreting but as far as I can tell, if I supply the "stuff" through the constructor of the class then the parameters are copied.

Code: [Select]

class Foo {
A const * instanceName;
const A thingBeingPointedTo;

Foo(const A &bar) : thingBeingPointedTo(bar){instanceName = &thingBeingPointedTo;} //Note I want to inject the field.

}If I now create bar with as a pointer to A and inject it to Foo, then after deleting the pointer and freeing the memory either:

• The reference is invalidated since its now pointing to freed memory and thus Foo is not immutable, or
• The field must copy its content and thus not efficient for large fields.

My question: What good are immutable strings? To me they sound like an idea so bad as to rival null-terminated strings. In normal programming languages I can just grab a string and go to town on it: replace parts of it, convert to lowercase, append something at the end and so on. Yet java, C# and a few other languages force me to use workarounds, like StringBuilder. Why?

The main reason for immutability I believe comes from functional programming. It makes it easy to write testable, thread-safe code since the state can never change. Yes, it takes a performance hit but not much.

[Maklak]

> immutable class
So it is pretty much what I thought: construct once and never change internal state after that.

> Of course, one could argue about its relevance today when memory is cheap.
Nah, having pointers to common data rather than multiple copies is viable. Cache is limited and copying objects in memory takes time.

> Maybe I'm misinterpreting but as far as I can tell, if I supply the "stuff" through the constructor of the class then the parameters are copied.
If you use non-pointers, then they get copied. If you use pointers, then they don't. References confuse me to this day, so just read up on them, I guess.

> If I now create bar with as a pointer to A and inject it to Foo, then after deleting the pointer and freeing the memory either [...]
It took me a while to wrap my head around what you're trying to accomplish here. I still don't understand why you insist on using references instead of pointers like God commanded it. Here's what I'd do:

class Foo
{
private:
  shared_ptr<A> instanceName;  // TODO: Put const in a few random places and see if it still compiles.
  // stuff

public:
  Foo(const shared_ptr<A> &aptr) : instanceName(aptr) { }  // Definietely OK to pass aptr by value and probably OK to pass by reference.
  // stuff
}

Then
std::shared_ptr<int> ap (new A(...));
 
Then just use ap as need, for example:
Foo f1(ap);
Foo f2(ap);

For this to work object A must be on the heap of course (well, unless you create it on the stack in a place that will assure it exists for as long as needed), but it is still one operator new and no copying after that and lifetime of object pointed to by ap is taken care of. 

The way you're trying to accomplish it, namely "thingBeingPointedTo(bar)" in initialiser list is a call to copy constructor and that's most likely going to copy memory. On top of that class Foo would also need to waste enough memory to fit an A object inside, which you don't even want to use. If you create an object, pass it by reference, take the address of it and finally delete the thing, you'll get a dangling pointer. Yep, I think you're a java programmer.

> if you ever so much as looked at a software engineering course, you'll know that ease of use is generally the very last thing that those companies worry about when choosing their tools.
What? Software engineering courses teach some maths, basic programming, algorithms, space-time complexity and things like that. They aren't concerned with "what the company will want".
On the other hand, when I went to my third job, my colleagues are complaining about their clients wanting Sharepoint and other frameworks and how horrible those tools are for anything beyond prototyping.

[MagmaMcFry]

if you ever so much as looked at a software engineering course, you'll know that ease of use is generally the very last thing that those companies worry about when choosing their tools.

What? Software engineering courses teach some maths, basic programming, algorithms, space-time complexity and things like that. They aren't concerned with "what the company will want".

No, you're thinking of computer science. Computer science is what you just described, software engineering is the theory of developing software.

[da_nang]

Yep, I think you're a java programmer.

I think I've broadcasted that in this thread before.

if you ever so much as looked at a software engineering course, you'll know that ease of use is generally the very last thing that those companies worry about when choosing their tools.

What? Software engineering courses teach some maths, basic programming, algorithms, space-time complexity and things like that. They aren't concerned with "what the company will want".

No, you're thinking of computer science. Computer science is what you just described, software engineering is the theory of developing software.

Aye, there you're more concerned with software design.