C/C++ Programming Questions Not Worth Their Own Thread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›640 »

Zerf: Dec 17, 2004; I miss you, sandman

shrughes posted:

How would you destroy the objects you've constructed in the region?

Write a macro that initializes a wrapper class instance with the alloca'd memory(since you can't alloca in the constructor of the class since the memory is deallocated when current function returns). Then just to trigger placement new/delete as needed on the memory buffer, preferably in the class constructor/destructor so you get RAII behaviour.

# ? Mar 30, 2014 11:56

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 20:11

shrughes: Oct 11, 2008; (call/cc call/cc)

I loled at this bug report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19131

# ? Mar 30, 2014 12:04

pepperoni and keys: Sep 7, 2011; _{I think about food literally all day every day. It's a thing.}

I have a beginner question that I can't figure out. It has to do with either inheritance or vectors I guess?

I have two classes like this:

code:

class Parent
{
    public:
        Parent(){};
        virtual void a();
};

class Child: public Parent
{
    public:
        Child(){};
        virtual void a();
};

I want the Child::a to override Parent::a.

It works like I want it to when I do it like this:

code:

Parent *c = new Child();
c->a();

or like this:

code:

Child ch;
Parent& c = ch;
c.a();

Both of those examples calls Child::a, just like I want them to. Which would be fine if I want just a single object, but I want a vector or some other kind of array of them.

I tried

code:

vector<Parent> vec;
vec.push_back( Child() );

and even

code:

vector<Parent> vec;
Parent *c = new Child();
vec.push_back(*c);

but in both cases

code:

vec[0].a();

calls Parent::a, and not Child::a. I can obvious make a vector<Child> and have it work, but since I intend to have different flavors of Parent, I want an array which can store all of them. Is there a way to do this or do I have to find a workaround?

# ? Mar 30, 2014 12:09

Qwertycoatl: Dec 31, 2008

Zaito posted:

I can obvious make a vector<Child> and have it work, but since I intend to have different flavors of Parent, I want an array which can store all of them. Is there a way to do this or do I have to find a workaround?

You can't put a Child in a vector<Parent> - when you try, all the Child parts of the object are cut off and it becomes a Parent.

What you can do, is put a pointer to a Child into a vector<Parent*>. That will then do what you want.

# ? Mar 30, 2014 12:20

Xerophyte: Mar 17, 2008; This space intentionally left blank

Qwertycoatl posted:

You can't put a Child in a vector<Parent> - when you try, all the Child parts of the object are cut off and it becomes a Parent.

To slightly expand on what's going on here, vector<Parent> stores objects "by value". It'll allocates precisely the memory space required to store all the stuff that goes into a Parent at each position and no more, it has no idea how much space a Child takes and cannot store one.

When you then do vec.push_back( Child() ); you're not storing the Child you just constructed directly but actually trying to do a copy insertion of it into the vector. The vector is taking the Child() and passing it to the (implicit but still present) copy-constructor Parent(const Parent &other); when it's constructing the Parent that it stores. This is a perfectly valid parameter -- a Child is a Parent and it can be passed to the copy-constructor, creating a Parent in that spot in the vector.

# ? Mar 30, 2014 12:35

seiken: Feb 7, 2005; hah ha ha

Also, if you can use C++11 and you want to use pointers in a vector and not have to manage the memory yourself somewhere else, you can use something like std::vector<std::unique_ptr<Parent>>.

# ? Mar 30, 2014 13:30

pepperoni and keys: Sep 7, 2011; _{I think about food literally all day every day. It's a thing.}

Qwertycoatl posted:

You can't put a Child in a vector<Parent> - when you try, all the Child parts of the object are cut off and it becomes a Parent.

What you can do, is put a pointer to a Child into a vector<Parent*>. That will then do what you want.

This does indeed do what I want, thanks!

# ? Mar 30, 2014 14:49

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

shrughes posted:

I loled at this bug report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19131

heh

# ? Mar 31, 2014 04:04

FAT32 SHAMER: Aug 16, 2012

I'm trying to build a constructor and when I set a boolean variable equal to another boolean variable Xcode gives me error "Expected Expressions"

C++ code:

class Truck: public Vehicle
{
public:
    Truck( string mfg, double cost, double capacity, bool auto )
    {
        mfgName = mfg;
        dealerCost = cost;
        haulCap = capacity;
        isAuto = auto;
    }
    ~Truck() { }

How would I set this up correctly?

# ? Mar 31, 2014 05:43

pseudorandom name: May 6, 2007

auto is a C/C++ keyword

# ? Mar 31, 2014 05:49

FAT32 SHAMER: Aug 16, 2012

pseudorandom name posted:

auto is a C/C++ keyword

Well that will do it, cheers.

# ? Mar 31, 2014 05:52

FAT32 SHAMER: Aug 16, 2012

I'm back with another hopefully obvious yet stupid question: I'm supposed to Use inheritance to derive two new classes Car and Truck from the base class Vehicle, which is available behind (Vehicle.h). I'm getting the error "C++ constructor must explicitly initialize the base class which does not have a default constructor" for the following code:

C++ code:

//vehTypes.h

#ifndef Cars_vehtypes_h
#define Cars_vehtypes_h
#include "vehicle.h"

#include <iostream>
#include <iomanip>
#include <string>

class Car : public Vehicle
{
public:
    Car( string mfg, double cost, string model, bool sunroof )
    {
        mfgName = mfg;
        dealerCost = cost;
        modelName = model;
        sroof = sunroof;
    }
    ~Car() { }
    double retailPrice(void) { return dealerCost * 1.25; }
    
    void showVehicle(void)
    {   cout << "Manufacturer: " << mfgName << endl
        << "Model" << modelName
        << "Sunroof?: " << sroof
        << "Customer price: "
        << fixed << showpoint << setprecision(2)
        << retailPrice() << endl;
        
    }
    
private:
    string mfgName;
    double dealerCost;
    string modelName;
    bool sroof;
};

class Truck: public Vehicle
{
public:
    Truck( string mfg, double cost, double capacity, bool automatic )
    {
        mfgName = mfg;
        dealerCost = cost;
        haulCap = capacity;
        isAuto = automatic;
    }
    ~Truck() { }
    double retailPrice(void) { return dealerCost * 1.25; }
    
    void showVehicle(void)
    {   cout << "Manufacturer: " << mfgName << endl
        << "Customer price: "
        << fixed << showpoint << setprecision(2)
        << retailPrice() << endl
        << "Towing Capacity (in tons): " << haulCap
        << "Automatic Transmission?: " << isAuto;
        
    }
private:
    string mfgName;
    double dealerCost;
    double haulCap;
    bool isAuto;
};

#endif

The errors are at the constructors for Car and Truck. Here's the base class for reference:

C++ code:

//Vehicle.h

#ifndef __Cars__vehicle__
#define __Cars__vehicle__

#include <iostream>

#endif /* defined(__Cars__vehicle__) */
#ifndef _VEHICLE
#define _VEHICLE

#include <iostream>
#include <iomanip>
#include <string>
using namespace std;

class Vehicle
{
public:
    Vehicle( string mfg, double cost )
    {
        mfgName = mfg;
        dealerCost = cost;
    }
    ~Vehicle() { }
    
    double retailPrice(void) { return dealerCost * 1.25; }
    
    void showVehicle(void)
    {   cout << "Manufacturer: " << mfgName << endl
        << "Customer price: "
        << fixed << showpoint << setprecision(2)
        << retailPrice() << endl;
    }
private:
    string mfgName;
    double dealerCost;
};
#endif

and the Client code:

C++ code:

//vClient.cpp

#include "vClient.h"
/* vClient.cpp
 * Main program to test Vehicle classes
 */

#include <iostream>
#include <cstdlib>
using namespace std;

#include "vehtypes.h"

int main()
{
    Car c1( "Ford", 10000, "Mustang", false ),c2( "Chevy", 15000, "Camaro", true );
    Truck t1( "Ford", 12000, 1.5, true ), t2( "Dodge", 14000, 2.0, false );
    
    cout << "Dealer inventory:" << endl << endl;
    c1.showVehicle();
    c2.showVehicle();
    t1.showVehicle();
    t2.showVehicle();
    
    system("PAUSE");
    return 0; 
}

(Vehicles and vClient were both given as part of the assignment)

I have really been struggling with C++ because it's so wildly different from Java, and Inheritance at one point was similar to Java but now it's just not making any sense to me :saddowns:

# ? Mar 31, 2014 21:18

raminasi: Jan 25, 2005; a last drink with no ice

Because Vehicle has a defined constructor with arguments and no constructor without (non-default) arguments, you need to explicitly call one of its constructors before any derived class's constructor runs. The syntax for doing that is

C++ code:

Car( string mfg, double cost, string model, bool sunroof )
    : Vehicle(mfg, cost)
{
    mfgName = mfg;
    dealerCost = cost;
    modelName = model;
    sroof = sunroof;
}

The stuff after the : is called an "initialization list" and this is one of the things you use them for.

Now my question for you: why do your derived classes keep additional track of information that's already stored in the base class?

e: Vehicle's destructor isn't virtual. Tsk, tsk, instructor.

raminasi fucked around with this message at 21:34 on Mar 31, 2014

# ? Mar 31, 2014 21:31

Star War Sex Parrot: Oct 2, 2003

He should be using initialization lists instead of assignment inside of the constructors anyway, but then there are a ton of "best practices" issues with that code so I probably shouldn't open a can of worms of nitpicking.

# ? Mar 31, 2014 21:35

FAT32 SHAMER: Aug 16, 2012

GrumpyDoctor posted:

Because Vehicle has a defined constructor with arguments and no constructor without (non-default) arguments, you need to explicitly call one of its constructors before any derived class's constructor runs. The syntax for doing that is
C++ code:
Car( string mfg, double cost, string model, bool sunroof )
    : Vehicle(mfg, cost)
{
    mfgName = mfg;
    dealerCost = cost;
    modelName = model;
    sroof = sunroof;
}
The stuff after the : is called an "initialization list" and this is one of the things you use them for.

Now my question for you: why do your derived classes keep additional track of information that's already stored in the base class?

e: Vehicle's destructor isn't virtual. Tsk, tsk, instructor.

do you mean mfgName = mfg and dealerCost = cost?

Star War Sex Parrot posted:

He should be using initialization lists instead of assignment inside of the constructors anyway, but then there are a ton of "best practices" issues with that code so I probably shouldn't open a can of worms of nitpicking.

# ? Mar 31, 2014 21:40

raminasi: Jan 25, 2005; a last drink with no ice

Tusen Takk posted:

do you mean mfgName = mfg and dealerCost = cost?

Well, yeah, but not just the assignment itself. I should probably take a step back and ask what exactly your derived classes are supposed to do, because there's almost assuredly a better way. (And if not, your instructor is a complete idiot.)

# ? Mar 31, 2014 21:46

FAT32 SHAMER: Aug 16, 2012

GrumpyDoctor posted:

Well, yeah, but not just the assignment itself. I should probably take a step back and ask what exactly your derived classes are supposed to do, because there's almost assuredly a better way. (And if not, your instructor is a complete idiot.)

He definitely is an idiot, half of his code in the lecture slides is completely hosed up or lacking tiny little things like quotation marks around Vehicles.h in #include "Vehicles.h" so I spent half an hour trying to figure out what was going on with that.

The classes are supposed to

quote:

The Car class adds two private data members, a string that contains a model name (like "Camaro") and a bool that is true if the car has a sunroof. Car should also have an appropriate constructor, and a member function showVehicle that displays its manufacturer, retail price, model name and whether or not it has a sunroof.

The Truck class adds two private data members, a double that indicates the truck's capacity in tons, and a bool that is true if the truck has an automatic transmission. Truck should also have an appropriate constructor, and a member function showVehicle that displays its manufacturer, retail price, capacity, and whether or not it has an automatic transmission.
Combine the definition of all classes in a single file vehtypes.h.

I don't understand why you wouldn't just write one class without inheritance to do all of those things but I guess the point of the exercise is less about making sense and more about showing you how inheritance is supposed to work.

# ? Mar 31, 2014 21:51

Star War Sex Parrot: Oct 2, 2003

Tusen Takk posted:

do you mean mfgName = mfg and dealerCost = cost?

I'm pretty sure he means: why are you declaring duplicate member variables in your derived classes (mfgName, dealerCost) when they already exist in the base class? If you're going to declare the same members all over again, it defeats one of the biggest reasons for inheritance -- the other being polymorphism.

edit: Also I can tell you right now that this instructor sucks. It looks like he's teaching you bad C++98 with no regard for more recent standards or best practices.

Star War Sex Parrot fucked around with this message at 21:53 on Mar 31, 2014

# ? Mar 31, 2014 21:51

FAT32 SHAMER: Aug 16, 2012

Star War Sex Parrot posted:

I'm pretty sure he means: why are you declaring duplicate member variables in your derived classes (mfgName, dealerCost) when they already exist in the base class? If you're going to declare the same members all over again, it defeats one of the biggest reasons for inheritance -- the other being polymorphism.

edit: Also I can tell you right now that this instructor sucks. It looks like he's teaching you bad C++98 with no regard for more recent standards or best practices.

He basically is, when I used the latest C++ stuff in my code not only would it not compile on the server but he refused to accept it if it didn't work on the server.

I should have never taken this elective :saddowns:

as for your question: l have no idea, I was kind of just plodding along hoping to get it to work so that I can submit it then worry about other homework

# ? Mar 31, 2014 22:12

raminasi: Jan 25, 2005; a last drink with no ice

Tusen Takk posted:

He definitely is an idiot, half of his code in the lecture slides is completely hosed up or lacking tiny little things like quotation marks around Vehicles.h in #include "Vehicles.h" so I spent half an hour trying to figure out what was going on with that.

The classes are supposed to

I don't understand why you wouldn't just write one class without inheritance to do all of those things but I guess the point of the exercise is less about making sense and more about showing you how inheritance is supposed to work.

Yeah. SWSP was right about my question, but what I hadn't noticed at the time was that those fields on Vehicle are private, so your derived classes have to re-store them. Which is really stupid.

Keep your head down, turn in poo poo that barely works, and don't think for a second that you're learning any kind of proper C++ here.

# ? Mar 31, 2014 22:29

Xerophyte: Mar 17, 2008; This space intentionally left blank

GrumpyDoctor posted:

Yeah. SWSP was right about my question, but what I hadn't noticed at the time was that those fields on Vehicle are private, so your derived classes have to re-store them. Which is really stupid.

I assume that they're private by intent and the students should implement Car::showVehicle by calling Vehicle::showVehicle rather than reimplementing its functionality in Car, in order to demonstrate how to encapsulate common functionality in the base class and all that jazz. As the exercise is written it can be done without re-storing anything in the derived classes. It's not a fantastically chosen example of when to do this and not having a virtual destructor is pretty much inexcusable when teaching inheritance in C++ but the idea itself is not a horror.

# ? Mar 31, 2014 22:58

FAT32 SHAMER: Aug 16, 2012

Sweet I got it working, thanks guys!

# ? Mar 31, 2014 23:42

xgalaxy: Jan 27, 2004; i write code

To give the benefit of the doubt to the professor, the example code as it is shown here doesn't require a virtual destructor to exist. And he may not have gotten to the part of explaining them or polymorphism yet, hence the lack of a virtual.

# ? Apr 1, 2014 03:24

raminasi: Jan 25, 2005; a last drink with no ice

If the C++-based curriculum introduces inheritance before even mentioning polymorphism it is really bad curriculum. (Honestly, I think that using C++ to teach anything except C++ is a bad idea, but this is definitely not how you make the most of it.)

# ? Apr 1, 2014 03:39

xgalaxy: Jan 27, 2004; i write code

GrumpyDoctor posted:

If the C++-based curriculum introduces inheritance before even mentioning polymorphism it is really bad curriculum. (Honestly, I think that using C++ to teach anything except C++ is a bad idea, but this is definitely not how you make the most of it.)

You have to teach what inheritance and encapsulation are before you can teach polymorphism. Every single book on C++ I have ever read introduces these concepts in that order.

# ? Apr 1, 2014 03:43

OctaviusBeaver: Apr 30, 2009; Say what now?

I'm pretty familiar with C but just now starting a project with C++. I want to do some simple 2d graphics in Windows, and must of what I see suggests that GDI+ is the best API for doing this. Is that the way to go or would I be better off looking into DirectX? All I want to do is draw simple vector graphics like lines and circles, and maybe a .bmp or two eventually. My main focus is finding something easy to get started in so simpler is better.

# ? Apr 1, 2014 04:47

xgalaxy: Jan 27, 2004; i write code

OctaviusBeaver posted:

I'm pretty familiar with C but just now starting a project with C++. I want to do some simple 2d graphics in Windows, and must of what I see suggests that GDI+ is the best API for doing this. Is that the way to go or would I be better off looking into DirectX? All I want to do is draw simple vector graphics like lines and circles, and maybe a .bmp or two eventually. My main focus is finding something easy to get started in so simpler is better.

You can use GDI+ but its pretty ancient these days. If you are on a Vista or higher I would recommend Direct2D.

# ? Apr 1, 2014 05:20

ephphatha: Dec 18, 2009

There are a whole bunch of different libraries you could use for that. Personally I'd go with Qt, but that's because it's familiar to me. SFML is a nice simple interface for 2d graphics as well. You could also look at SDL or glut. They all provide cross platform window management/initialization boilerplate which is nice unless you really want to learn raw win32 calls.

I find QML to be fairly easy to get started with, but actually integrating it with a complex c++ program is a bit of a challenge at first.

# ? Apr 1, 2014 05:30

raminasi: Jan 25, 2005; a last drink with no ice

xgalaxy posted:

You have to teach what inheritance and encapsulation are before you can teach polymorphism. Every single book on C++ I have ever read introduces these concepts in that order.

But how on earth do you effectively motivate inheritance without polymorphism? Every attempt I've seen has resulted in these idiotic "Car extends Vehicle" examples that have absolutely no resemblance to the problems you'd have to solve in a real application or the ways in which you would solve them.

# ? Apr 1, 2014 18:57

nebby: Dec 21, 2000; resident mog

GrumpyDoctor posted:

But how on earth do you effectively motivate inheritance without polymorphism? Every attempt I've seen has resulted in these idiotic "Car extends Vehicle" examples that have absolutely no resemblance to the problems you'd have to solve in a real application or the ways in which you would solve them.

Eh, you can motivate inheritance just as a code reuse mechanism before introducing polymorphism. It's a bit contrived but for teaching purposes it works. This is the approach taken by Accelerated C++ iirc which I just finished working through.

trying to pick up C++ "again", the last time I seriously read a C++ book was this one more than 20 years ago so needless to say a lot has changed

though I have done some ad hoc hacking, ie not understanding wtf I was doing, since then.

# ? Apr 2, 2014 00:57

raminasi: Jan 25, 2005; a last drink with no ice

nebby posted:

Eh, you can motivate inheritance just as a code reuse mechanism before introducing polymorphism. It's a bit contrived but for teaching purposes it works. This is the approach taken by Accelerated C++ iirc which I just finished working through.

[public] inheritance for code reuse is both a coding and curricular horror.

# ? Apr 2, 2014 02:02

nebby: Dec 21, 2000; resident mog

GrumpyDoctor posted:

[public] inheritance for code reuse is both a coding and curricular horror.

Anytime you have a base class with a non-virtual function, or a non-pure virtual one at that, aren't you leveraging inheritance for code reuse? Composition or generic programming are probably better approaches if you are not using polymorphism etc, but it seems a bit odd to say that inheritance isn't a tool for code reuse. In other words, like I said, for the purposes of bootstrapping someone's knowledge, introducing inheritance before polymorphism is possible if you provide a simple example where a base class has a non-virtual function that provides some generally useful functionality for subclasses. From there you can immediately move onto polymorphism without a catch-22. This is different than saying that a professional programmer would use inheritance in the same situation given their knowledge of alternative designs.

edit: re: public vs private (ie interface vs implementation motivated) the distinction seems irrelevant when first introducing someone to the concept of inheritance with the goal literally being to provide enough foundational knowledge to explain polymorphism. the alternative is you teach them template based polymorphism before virtual functions (or choose another programming language) -- good luck bootstrapping that one!

nebby fucked around with this message at 03:08 on Apr 2, 2014

# ? Apr 2, 2014 02:48

shrughes: Oct 11, 2008; (call/cc call/cc)

nebby posted:

Anytime you have a base class with a non-virtual function, or a non-pure virtual one at that, aren't you leveraging inheritance for code reuse?

Not when the method is called using the base class type. Then it's the same as if you have a function on the outside of the class, using it (except for visibility).

I don't think purity has anything to do with this -- you mean constness or functional purity, right?

# ? Apr 2, 2014 05:25

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

shrughes posted:

I don't think purity has anything to do with this -- you mean constness or functional purity, right?

"Pure virtual" functions in C++ are another name for what are called "abstract" functions in other languages - they provide a declaration of what the function is, but no definition (requiring it to be implemented by subclasses).

# ? Apr 2, 2014 06:10

nebby: Dec 21, 2000; resident mog

Yeah, if I have a non-pure virtual function on a base class, I am providing a default implementation for a virtual function. Ie, this is letting me re-use that code in subclasses that do not need to override the virtual.

Anyway the point is just that I don't see any way to teach polymorphism in C++ without an intentionally simplified exposition on inheritance as a preface, unless you want to teach templates first or think overloading is a sufficient demonstration (it's probably not.) If you want to avoid OOP and teach polymorphism then you probably need to use a language with alternative approaches to dynamic dispatch like multimethods. Julia is a cool one.

nebby fucked around with this message at 06:29 on Apr 2, 2014

# ? Apr 2, 2014 06:25

shrughes: Oct 11, 2008; (call/cc call/cc)

I don't think a non-pure virtual function, or any other function in a base class, is any more an example of code reuse than any other function is. The non-pure virtual function is the same as having a pure virtual function with a "helper" providing a default implementation for any implementers that would want to use it. So it saves you from having to write some vacuous callers to the helper function. I don't think that's code reuse, it's more like a distinct notion, boilerplate elimination.

# ? Apr 2, 2014 09:01

Sulla Faex: May 14, 2010; No man ever did me so much good, or enemy so much harm, but I repaid him with ENDLESS SHITPOSTING

I'm trying to learn C and I'm struggling with pointers and strings (duh).

I'm trying to convert a pointer address into a long unsigned int just for curiosity's sake, but it's not working at all. I figure the issue is with getting actually getting the dereferenced pointer to be used as a string.

I can't do:

code:

char otherval[8] = "testing";
char *ptr = otherval;
char *ptrval = &ptr;

because it throws an error "warning: initialisation from incompatible pointer type", and I also can't do:

code:

char otherval[8] = "testing";
char *ptr = otherval;
long unsigned *ptrval;
ptrval = strtol(ptr, NULL, 0); // 16 also doesn't work.

because it always shows '0' when I printf it out.

What's my fundamental failure here?

# ? Apr 2, 2014 12:09

nielsm: Jun 1, 2009

Sulla-Marius 88 posted:

What's my fundamental failure here?

Part of it seems to be a misunderstanding between the relationships between pointers, integers and strings.
A string in C is a pointer to some memory that contains a series of characters, ending with a "nul" character. Note that the "nul" character is not the same as a NULL pointer, it's just a character with a special value that gets treated specially. (A "sentinel" value.) A pointer, on the machine level, is an integer value, but if you depend on treating pointers as integers in regular software, chance is you're on the way to shoot yourself in the foot. An integer is a number value. A single character is also a number value, but the computer system happens to have a way to produce a printed character based on looking up characters' number values in a table.
A string of characters can happen to contain only characters whose values are decided to represent digits in human language, so when you print that string you see it as a number. That doesn't make the string a number, it's still just a string. However a function such as strtol() will attempt to parse a string that contains a number and produce an integer value from it. That value is from the sequence of characters stored at the location the string is a pointer to, not from the value of the string pointer or something else.

Now, if you wanted to take a pointer value, treat it as a numeric integer value, and produce a string that contains a human-readable representation of that integer value, you will have to do two things: First, typecast the pointer value to an integer value. (This is on the machine level a no-op, nothing actually gets converted, the typecast here only tells the C compiler that you want to treat the value as a different type, but the distinction typically doesn't exist for the CPU.) Now that you have an integer value, you can then use a function such as sprintf() to produce a string representation from the integer. Of course that requires you to have some a writable string (character array) for the function to write into.

C++ code:

#include <stdio.h>

int main()
{
  /* Allocate an empty array of 50 characters that can be written to */
  char print_buffer[50];
  /* Have a variable pointing to a static (fixed) string, the pointed-to characters can't be written to */
  const char *somestring = "test"; 
  /* Have an intermediate integer, for exposition
   * Technically not needed, the cast can be done right in the sprintf() operation */
  unsigned long int foo;

  /* Cast the static string pointer into an integer */
  foo = (unsigned long int)somestring;

  /* Print the integer value to a decimal number string.
   * The %lu format specifier indicates an _u_nsigned _l_ong int */
  sprintf(print_buffer, "%lu", foo);

  /* Put it onto stdout */
  printf("%s\n", print_buffer);
}

# ? Apr 2, 2014 12:45

Dicky B: Mar 23, 2004

Also if you want a signed or unsigned integer which is guaranteed to be big enough to hold a pointer, you can use intpr_t and uintpr_t respectively.

# ? Apr 2, 2014 13:00

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 20:11

Sulla Faex: May 14, 2010; No man ever did me so much good, or enemy so much harm, but I repaid him with ENDLESS SHITPOSTING

Thank you so much. I can't imagine why I'd need to use the pointer address as an integer, I was just struggling because I was trying to do it as a curiosity, it wasn't working, and I couldn't figure out why. It conflicted with my knowledge of the pointer value and of numerical conversion. It turned out, as per your code, that the final step I was missing was the explicit cast to treat the pointer as an unsigned long int when grabbing its value rather than pushing the pointer itself into an existing unsigned long int... if that makes sense.

So this:

code:

unsigned long int ptrval = ptr

should have been this:

code:

unsigned long int ptrval = (unsigned long int)ptr

And now I'm getting the numbers I'm expecting.

For clarity, I didn't want the pointer address as an integer for any particular reason, I just wanted to iterate through a string and see how the addresses in memory increased as well, but it just wasn't working and I couldn't figure out why.

# ? Apr 2, 2014 13:24

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›640 »