TICPP Task unsolvable?

#include <iostream>

using namespace std;

int main(int argc, char *argv[]){
    const double c_arr[5] = { 1.0 , 10.0 , 1.0, 10.0 , 1.0 };
    volatile double v_arr[5] = { 1.0 , 10.0 , 1.0, 10.0 , 1.0 };
    double *var;
    for(int i=0; i<5;i++){
        var = const_cast<double*>(&c_arr[i]);
        *var=i*10;
        cout << "casted from const: [" << i << "] " << c_arr[i] << endl;
    }
    for(int i=0; i<5 ; i++ ){
        var = const_cast<double*>(&v_arr[i]);
        *var=i*10;
        cout << "casted from volatile: [" << i << "] " << v_arr[i] << endl;
    }
    return 0;
}

/*
Create a const array of double and a volatile array of double. Index through each array and use const_cast to cast each element to non-const and non-volatile, respectively, and assign a value to each element.
*/


The task in comments is from the book "Thinking in C++" 3rd chapter 27th task.
I mean I know that I shouldn't be able to change a const, but I can't let it be uninitialized or that will give me an error (at least the const). So please 4chan explain to me how I am supposed to solve this task?
btw. I am on Linux if that makes a difference which it shouldn't for such a basic Program.

Thinking in C++
Every time I see that book somewhere, I remember the Sapir–Whorf hypothesis and lul just a bit inside.

that does not exactly help me very much

>>3
Okay, now for the helpful part: trash that brain-damaging book and read SICP instead.

>>2
From now on, so will I. Isn't there a "Thinking in Java" too? Lol.

>>1
Maybe the wording is unclear or something.

>>5
Fuck you! You impostor.
Well and could >>4 please tell me how reading SICP will help me learn programming c++.
If you guys don't know the answer or can't post any helpful (as in helping me to answer the question I asked) advice then don't post in this thread.

>>6
Well and could >>4 please tell me how reading SICP will help me learn programming c++.
Yes. It will hugely improve the way you think about programming in general, including programming in C++. You will probably not like C++ a lot anymore after reading it, though.

If you guys don't know the answer or can't post any helpful (as in helping me to answer the question I asked) advice then don't post in this thread.
You don't understand /prog/.

>>3
You're in /prog

>>4
This helps though

>>6
Well and could >>4 please tell me how reading SICP will help me learn programming c++.
Once you read it, you'll understand. You'll never write the same code. You'll also learn to dislike C++.

>>6
Imposter? Maybe that word doesn't mean what you think it means....

>>1
Dear OP,
That example/practise/task is meaningless.
That kind of silly hackery with typecastings and all that is for people that DON'T know C++ (or C).

I suggest you get Stroustrup's book.

(keep in mind all this advice is from a C pedantic faggot that hates C++ zealots.)

>>10
OMG OPTIMIZED!

>>9
You're right english is not my native language and I didn't double check the word.

>>10
that was kinda helpful. Google books allowed me to search the german version of the book but strangely not the english version and on page 441 it states (translated):

It's not possible to cast into a private Type (the context is static and dynamic cast), and to cast away a const you'll need const_cast. Even then the usage of the result is only safe if the type wasn't originally declared as const. So I came up with this code which is indeed meaningless but I have learned something because I was given the task to do it, so it was worth it.


#include <iostream>

using namespace std;

int main(int argc, char *argv[]){
    double arr[5] = { 1.0 , 10.0 , 1.0, 10.0 , 1.0 };
    const double *c_arr = const_cast<const double*>(arr);
    volatile double v_arr[5] = { 1.0 , 10.0 , 1.0, 10.0 , 1.0 };
    double *var;
    for(int i=0; i<5 ; i++ ){
        var = const_cast<double*>(&v_arr[i]);
        *var=i*10;
        cout << "casted from volatile: [" << i << "] " << v_arr[i] << endl;
    }
    for(int i=0; i<5;i++){
        var = const_cast<double*>(&c_arr[i]);
        *var=i*10;
        cout << "casted from const: [" << i << "] " << c_arr[i] << endl;
    }
    return 0;
}

/*
Create a const array of double and a volatile array of double. Index through each array and use const_cast to cast each element to non-const and non-volatile, respectively, and assign a value to each element.
*/


This runs without the memory access error but actually really defeats the purpose of declaring c_arr private. But it definitely taught me that a const can be changed if it was casted from a non const

cast
Fail

private
Fail

Type
Fail

static and dynamic cast
Waaaah!

const
Fail

const_cast
What the fuck

declared
Fail

C++ fails sorry sir

>>13
You don't like typecasting and const and declared variables? GTFO
for the rest -- C++ fails indeed.

>>14
Okay, constants have some use in the sense of security, but that's only if you fear your program is subject to code injection, which it shouldn't.

But typecasting is completely useless. What you should have is dynamic evaluation and polymorphism. You simply call functions, e.g. f(x) → x.lol(). When f is actually called, and passed an object, the interpreter/specializer/recompiler/whatever should check if it knows how to lol on that object. If it happens to, it lols, whatever that may be for the given object. This way you avoid shooting your foot by ungeneralizing and wasting time defining types. This also makes typecasting completely useless: even if you could turn an object into another (in Python, you can change an object's class in real time, whatever you'd want to do that for), it would do nothing. Instead of typecasting, just call the fucking function or use the fucking property, and catch exceptions if the object you're passed doesn't have the property you were looking for.

>>15
How do I unmaintainable coded?

>>16
Not really. f = lambda x: x.lol() is actually more maintainable than:
lolresult f(datatype1 x):
    return (lolresult) ((datatype1_with_lol_be_really_sure) f).lol()
First, because it's far more generic code: it requires less maintainance because it works in many more cases. Second, it's much shorter, simpler, and easier to read. Third, it's much easier to take out of the program and test individually with any object that happens to have a lol property that's executable. Fourth, maintaining this function doesn't require knowledge of an insane class tree some enterprise fucktard came up with, nor dealing with three different classes. Fifth, less type handling/bullshitting means less error prone.

A more safe, error catching f could be written as:
def f(x):
    try:
        return x.lol()
    except AttributeError:
        print '''Sorry, you fucked up. You wanted to "f" an object "%s",
but it doesn't know how to "lol". Teach it to "lol" and I'll work,
else use another object. Here's a traceback for you:\n''' % x.__class__
        raise

C++ is a horrible language.

My word!

EVERY SINGLE programming language is bad in the opinion of /prog/ after a few posts in a thread roughly about that language.

to sum up /prog/ some in befores:
ruby sucks
C sucks
python sucks
Java sucks (no really it does)
perl sucks
D sucks
C++ sucks
LISP sucks
php sucks
PROLOG sucks
pascal sucks
delphi sucks even more
fortan sucks
Java script sucks
C# sucks (badly)
Visual Basic sucks (even worse)
and last but not least Assembler for each arch sucks

I know I forgot a lot of em but that's just what came to my mind

>>20
And we're right every single time.

>>21
then why the fuck is it called /prog/ if nobody here actually uses a programming (or scripting for that case) language

oh wait I got it
it's called /prog/ because here people discuss in how many ways each of the programming languages suck

In /prog/ we only program in pseudo code.

>>22
then why the fuck is it called /prog/ if nobody here actually uses a programming (or scripting for that case) language
You're drawing conclusions out of your ass, fuckwit. Not liking a language doesn't mean not using it. On the contrary; the more I use a particular language, the more bad things I can say about it. I just choose my languages to minimize the amount of suck I need to tolerate daily.

>>24
Calm down, sir. The other gentleman was trolling.

>>25
His troll contained a logical fallacy. We can't tolerate such sloppiness.

>>24
no, he was right
nobody on /prog/ actually programs
the obvious indicator is all the lisp talk

>>24
Define "scripting language".

>>28
FUCKING IDIOT. I DIDN'T USE THE WORD. THE FUCKTARD I REPLIED TO DID.

32 Name: Anonymous 2013-01-18 22:57

/prog/ will be spammed continuously until further notice. we apologize for any inconvenience this may cause.