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 »

That Turkey Story: Mar 30, 2003

It's undefined if you try to call a member function on a NULL pointer whether virtual or not. If you want to check inside the function if the pointer is NULL, make it a static member function or non-member function and pass in a pointer to the object.

# ? Dec 15, 2008 04:56

Adbot: ADBOT LOVES YOU

# ? May 18, 2024 07:48

theg sprank: Feb 3, 2008; pillage your village

Avenging Dentist posted:

Quoth the Standard:

Many thanks, you standard-diver you.

theg sprank fucked around with this message at 04:59 on Dec 15, 2008

# ? Dec 15, 2008 04:56

hexadecimal: Nov 23, 2008; by Fragmaster

theg sprank posted:

I have a question for C++ language nazis.

Clearly it's unacceptable to call a virtual method on a NULL pointer. Is it acceptable to call a non-virtual method on a NULL pointer, from the standpoint of the language definition? It happens to work on g++, but I want to know whether it is required by the standard to work.

many thanks

Do you mean if its a run-time or compile time error to call methods on a NULL pointer? I think in both cases they are run-time error. I believe that virtual methods are contained in some virtual function table list, and compiler links to them at run-time so for a null pointer, it would still have a type, and the address of the function you are trying to call would still be able to be determined at compile time.

So, The answer to your question is that in both cases it would be a run-time error to call methods on a NULL pointer.

# ? Dec 15, 2008 05:16

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

hexadecimal posted:

Do you mean if its a run-time or compile time error to call methods on a NULL pointer? I think in both cases they are run-time error. I believe that virtual methods are contained in some virtual function table list, and compiler links to them at run-time so for a null pointer, it would still have a type, and the address of the function you are trying to call would still be able to be determined at compile time.

So, The answer to your question is that in both cases it would be a run-time error to call methods on a NULL pointer.

I'm not sure what you are attempting to say here, but it is almost certainly wrong.

# ? Dec 15, 2008 05:33

floWenoL: Oct 23, 2002

Avenging Dentist posted:

I'm not sure what you are attempting to say here, but it is almost certainly wrong.

Hexadecimal giving a stupidly wrong answer to a question which someone has already answered? No way!

# ? Dec 15, 2008 07:07

Whilst farting I: Apr 25, 2006

ultra-inquisitor posted:

appendandclear() seems to be the simplest thing to change. First you need to check whether the list you're appending onto is empty. If it is, pop_front_push_elsewhere the first element. Then, just loop through and do the rest normally:

Ahhh, recursion on the brain was killing how I should even done a function normally. :doh:

I had some other problems unrelated to everything I've been posting, but managed to work them out and now it works! Thanks again!

# ? Dec 15, 2008 09:58

hexadecimal: Nov 23, 2008; by Fragmaster

code:

#include <iostream>

using namespace std;

class A
{
      public:
             virtual void a()=0;
};

class foo : public A
{
      int i;
      public:
      foo()
      {
           i=5;
       }
      
      virtual void a()
      {
              cout<<"virtual func"<<endl;
      }
      
      int bar()
      {
          cout<<i<<endl;
      }
};


int main()
{
    foo * f = NULL;
    f->a();
    f->bar();
}

This generates segmentation fault for lines f->a() and f->bar() which is a run time error. This is what i was trying to say. What is wrong about it?

Perhaps I misread or misunderstood the person who asked about this.

vvvvvvvvvvvvvvvv ok, admittedly I am not an expert on how virtual functions are implemented in C++. Thank you for your explanation, and sorry for giving the wrong one to the original person asking about this.

hexadecimal fucked around with this message at 16:25 on Dec 15, 2008

# ? Dec 15, 2008 15:49

Axel Rhodes Scholar: May 12, 2001; Courage Reactor

hexadecimal posted:

What is wrong about it?

quote:

I believe that virtual methods are contained in some virtual function table list, and compiler links to them at run-time so for a null pointer, it would still have a type, and the address of the function you are trying to call would still be able to be determined at compile time.

This part is pretty wrong. Virtual functions are (er, usually, in almost all implementations of C++) looked up using a vtable pointer which is a part of the actual object itself as opposed to using the type of the pointer. Obviously NULL isn't going to have a vtable pointer (because there's no object there at all).

Also 'links' probably isn't a good word to use there, since it sounds like you're talking about linking like a linker does.

But don't take it to heart, flowenol and AD are horrible trolls (how about being HELPFUL as well as right, jerks????)

# ? Dec 15, 2008 16:07

digibawb: Dec 15, 2004; got moo?

hexadecimal posted:

code:
.. snip
This generates segmentation fault for lines f->a() and f->bar() which is a run time error. This is what i was trying to say. What is wrong about it?

Perhaps I misread or misunderstood the person who asked about this.

vvvvvvvvvvvvvvvv ok, admittedly I am not an expert on how virtual functions are implemented in C++. Thank you for your explanation, and sorry for giving the wrong one to the original person asking about this.

If you didn't dereference this in bar, then on many compilers, you would get away with doing the call with no harm done. However, it's obviously not good practice, as it's compiler specific, but most compilers (read: the 4-5 that I use anyway)behave the same way for this case.

# ? Dec 15, 2008 17:38

hexadecimal: Nov 23, 2008; by Fragmaster

digibawb posted:

If you didn't dereference this in bar, then on many compilers, you would get away with doing the call with no harm done. However, it's obviously not good practice, as it's compiler specific, but most compilers (read: the 4-5 that I use anyway)behave the same way for this case.

I actually tried this, and it worked. That is i just printed something in bar without using any member variables. I am confused though, what object is this being called on when i call it on NULL pointer? Does it just treat it as static method?

# ? Dec 15, 2008 17:44

That Turkey Story: Mar 30, 2003

hexadecimal posted:

I actually tried this, and it worked. That is i just printed something in bar without using any member variables. I am confused though, what object is this being called on when i call it on NULL pointer? Does it just treat it as static method?

Calling a non-virtual member function is functionally no different from calling a nonmember function that takes a pointer to the type as a parameter. If you aren't dereferencing it, realistically no harm will come. It's still technically undefined behavior, however (by authority of the standard, not because it can't be forced to work reliably).

# ? Dec 15, 2008 17:55

Lexical Unit: Sep 16, 2003

Bah, nevermind. I had misinterpreted a compiler error.

Lexical Unit fucked around with this message at 20:55 on Dec 15, 2008

# ? Dec 15, 2008 19:31

Painless: Jan 9, 2005; Turn ons: frogs, small mammals, piles of compost
Turn offs: large birds, pitchforks
See you at the beach!

That Turkey Story posted:

If you aren't dereferencing it, realistically no harm will come.

I had a weird crash once on Visual C++ calling a function that was something like this:

code:

void foo( int& bar, int baz )
{
  if ( baz ) bar += baz;
}

with baz as 0 and bar as a null reference (dereferred from a null pointer). This taught me that it is pessimism, not realism, that really gives results.

# ? Dec 15, 2008 20:38

floWenoL: Oct 23, 2002

Painless posted:

I had a weird crash once on Visual C++ calling a function that was something like this:
code:
void foo( int& bar, int baz )
{
  if ( baz ) bar += baz;
}
with baz as 0 and bar as a null reference (dereferred from a null pointer). This taught me that it is pessimism, not realism, that really gives results.

Well that's explained as simply that the "real" dereference in the code Visual C++ generates happens on the "bar += baz" expression, although the behavior is undefined as soon as you dereferenced the null pointer to get the "null reference".

# ? Dec 15, 2008 20:45

That Turkey Story: Mar 30, 2003

floWenoL posted:

Well that's explained as simply that the "real" dereference in the code Visual C++ generates happens on the "bar += baz" expression, although the behavior is undefined as soon as you dereferenced the null pointer to get the "null reference".

Quoted for truth. Dereferencing and assigning to a reference has undefined results if the pointer's value is NULL (just like all NULL pointer deferences), but internally, it's generally just copying the pointer value so you're probably not going to get a crash until you actually read from or write to your reference.

# ? Dec 15, 2008 20:47

hexadecimal: Nov 23, 2008; by Fragmaster

That Turkey Story posted:

Calling a non-virtual member function is functionally no different from calling a nonmember function that takes a pointer to the type as a parameter. If you aren't dereferencing it, realistically no harm will come. It's still technically undefined behavior, however (by authority of the standard, not because it can't be forced to work reliably).

What exactly do you mean by a "function that takes a pointer to the type as a parameter".

Is it something like this?

code:

struct foo
{
     void bar(){}
};

versus

code:

void bar( foo * obj ){}

# ? Dec 15, 2008 22:23

That Turkey Story: Mar 30, 2003

hexadecimal posted:

What exactly do you mean by a "function that takes a pointer to the type as a parameter".

Is it something like this?
code:
struct foo
{
     void bar(){}
};
versus
code:
void bar( foo * obj ){}

Yes, where obj is like this and where the pointer is const.

# ? Dec 15, 2008 22:28

hexadecimal: Nov 23, 2008; by Fragmaster

That Turkey Story posted:

Yes, where obj is like this and where the pointer is const.

Why does the pointer have to be const? Would it only have to be const if the function itself is const?

# ? Dec 15, 2008 22:34

That Turkey Story: Mar 30, 2003

hexadecimal posted:

Why does the pointer have to be const? Would it only have to be const if the function itself is const?

I mean the pointer itself is const, not that it's pointing to const. In other words, you can't ever modify "this" in a member function call, only what "this" points to.

# ? Dec 15, 2008 22:36

Bitruder: Nov 29, 2003; Majoring in connect the dots and colouring

Say I have a void pointer that points to some random object. If I do the following, will it free up the right amount of memory?

code:

void *p;
p = new myClass();
delete static_cast<myClass*>(p);

# ? Dec 17, 2008 18:42

That Turkey Story: Mar 30, 2003

Bitruder posted:

Say I have a void pointer that points to some random object. If I do the following, will it free up the right amount of memory?
code:
void *p;
p = new myClass();
delete static_cast<myClass*>(p);

Yes.

# ? Dec 17, 2008 18:58

csammis: Aug 26, 2003; Mental Institution

The answer is probably "no," but I thought I'd ask anyway: Is there a way to tell Visual Studio's linker, when it encounters a multiply defined symbol, which one is the "right" one?

The scenario is sort of asinine. Our company's application is MFC-based, v2.5 I believe, and we're having trouble throwing exceptions through it. Most of the time this is handled by a redefined AfxWinMain that handles our application's exception class - which is not derived from CException. We're getting some odd activation context exceptions in certain scenarios when an exception is thrown from a window's OnCreate handler. The architect working with me on this thinks the band-aid solution is to redeclare AfxCallWndProc to be able to handle our exceptions as well as CExceptions, but that is proving difficult because AfxCallWndProc isn't declared as extern by MFC. AfxWinMain is one of only a handful of externs in MFC, as far as I can tell, and none of the others have dick to do with the problem.

So yeah, any way to force the linker to accept a specific location of a symbol as The Symbol? :sigh:

# ? Dec 17, 2008 19:46

ehnus: Apr 16, 2003; Now you're thinking with portals!

csammis posted:

The answer is probably "no," but I thought I'd ask anyway: Is there a way to tell Visual Studio's linker, when it encounters a multiply defined symbol, which one is the "right" one?

The scenario is sort of asinine. Our company's application is MFC-based, v2.5 I believe, and we're having trouble throwing exceptions through it. Most of the time this is handled by a redefined AfxWinMain that handles our application's exception class - which is not derived from CException. We're getting some odd activation context exceptions in certain scenarios when an exception is thrown from a window's OnCreate handler. The architect working with me on this thinks the band-aid solution is to redeclare AfxCallWndProc to be able to handle our exceptions as well as CExceptions, but that is proving difficult because AfxCallWndProc isn't declared as extern by MFC. AfxWinMain is one of only a handful of externs in MFC, as far as I can tell, and none of the others have dick to do with the problem.

So yeah, any way to force the linker to accept a specific location of a symbol as The Symbol?

Have you tried decorating the symbol with __declspec(selectany)?

# ? Dec 17, 2008 19:57

csammis: Aug 26, 2003; Mental Institution

ehnus posted:

Have you tried decorating the symbol with __declspec(selectany)?

The symbol here is a method, AfxCallWndProc(CWnd*, HWND, UINT, WPARAM, LPARAM). selectany seems to only apply to data - trying it, I get "'selectany' can only be applied to data items with external linkage"

# ? Dec 17, 2008 20:11

almostkorean: Jul 9, 2001; eeeeeeeee

What's the best cross-platform software for C++ development besides Eclipse?

# ? Dec 17, 2008 20:43

Ari: Jun 18, 2002; Ask me about who Jewish girls should not marry!

almostkorean posted:

What's the best cross-platform software for C++ development besides Eclipse?

Depends what you want to do. A lot of people swear by vim or emacs, and a lot of people swear by Visual Studio (of course, that's not cross-platform). Eclipse is good stuff too - you should just try a bunch of different things until you're comfortable with your editor.

You should be careful asking a question like that around here too - may start a war.

# ? Dec 17, 2008 21:14

Mustach: Mar 2, 2003; In this long line, there's been some real strange genes. You've got 'em all, with some extras thrown in.

Ari posted:

You should be careful asking a question like that around here too - may start a war.

That's more the fault of "around here" than almostkorean, though.

# ? Dec 17, 2008 21:27

litghost: May 26, 2004; Builder

csammis posted:

The answer is probably "no," but I thought I'd ask anyway: Is there a way to tell Visual Studio's linker, when it encounters a multiply defined symbol, which one is the "right" one?

The scenario is sort of asinine. Our company's application is MFC-based, v2.5 I believe, and we're having trouble throwing exceptions through it. Most of the time this is handled by a redefined AfxWinMain that handles our application's exception class - which is not derived from CException. We're getting some odd activation context exceptions in certain scenarios when an exception is thrown from a window's OnCreate handler. The architect working with me on this thinks the band-aid solution is to redeclare AfxCallWndProc to be able to handle our exceptions as well as CExceptions, but that is proving difficult because AfxCallWndProc isn't declared as extern by MFC. AfxWinMain is one of only a handful of externs in MFC, as far as I can tell, and none of the others have dick to do with the problem.

So yeah, any way to force the linker to accept a specific location of a symbol as The Symbol?

This may or may not work for, but here goes:

1. Make a .lib from a .def file with only AfxCallWndProc in it. The name of the .def will determine the name of the DLL it will link with.

Example:

code:

test.def:

LIBRARY
EXPORTS
  test_func

The lib tool can do this. Use the /def flag.

2. Make a DLL that exports a symbol named AfxCallWndProc, but declare the wrapper function as something else, and use the module definition file to redefine the symbol name.

Example:

code:

LIBRARY
EXPORTS
  test_func = test_func_wrapper

By using the library generated in step one, your program will search for a DLL with the symbol name, satisfying the link problem. Then you provide a DLL that wraps the real call, tada! Problem solved, maybe!

# ? Dec 18, 2008 04:47

theg sprank: Feb 3, 2008; pillage your village

Is there a way to (quasi-)portably detect how many cores the machine has, either at runtime or compile time?

If this has been asked before, I apologize.

# ? Dec 18, 2008 06:45

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

theg sprank posted:

Is there a way to (quasi-)portably detect how many cores the machine has, either at runtime or compile time?

No.

# ? Dec 18, 2008 06:52

csammis: Aug 26, 2003; Mental Institution

rjmccall posted:

No.

Indeed. Ever notice how top doesn't show the number of cores? :v:

# ? Dec 18, 2008 06:56

litghost: May 26, 2004; Builder

theg sprank posted:

Is there a way to (quasi-)portably detect how many cores the machine has, either at runtime or compile time?

If this has been asked before, I apologize.

Yes, if your compiler supports OpenMP. Specifically omp_get_num_procs, as specified in the OpenMP specification. Of course that assumes you don't care about the difference between "core" and "processor".

# ? Dec 18, 2008 07:07

TSDK: Nov 24, 2003; I got a wooden uploading this one

almostkorean posted:

What's the best cross-platform software for C++ development besides Eclipse?

I've been meaning to try out Code::Blocks for a while, because it looks pretty neat. Might be worth giving a go.

(Although the best option is to use Visual Studio and cross-compile instead

)

# ? Dec 18, 2008 10:42

fischtick: Jul 9, 2001; CORGO, THE DESTROYER; Fun Shoe

csammis posted:

Ever notice how top doesn't show the number of cores?

Press '1'.

csammis posted:

Indeed. Ever notice how top doesn't show the number of cores?

This probably horrible, but: Count the number of entries in /proc/cpuinfo

. I noticed that when I ran the POV-Ray 1.37 benchmark script on two different machines, it launched, by default, 4 and 8 threads, respective of the number of cores on each machine (this was in linux). I don't know what it did to figure that out though.

Question of my own:
Does g++ 4.3.2 treat func(const string var); differently from func(const string &var);? Since it's const, I think it might pass by reference anyway?

Thanks

# ? Dec 18, 2008 16:44

TSDK: Nov 24, 2003; I got a wooden uploading this one

Bitruder posted:

Question of my own:
Does g++ 4.3.2 treat func(const string var); differently from func(const string &var);? Since it's const, I think it might pass by reference anyway?

Thanks

It should do. Since classes may have mutable member variables, then the compiler cannot assume that it's safe to pass a reference rather than a copy.

# ? Dec 18, 2008 16:58

That Turkey Story: Mar 30, 2003

Bitruder posted:

Question of my own:
Does g++ 4.3.2 treat func(const string var); differently from func(const string &var);? Since it's const, I think it might pass by reference anyway?

Almost definitely it will always pass by value if you say to pass by value unless it can determine that based on the implementation of the function they are functionally the same. The standard is very strict about this.

# ? Dec 18, 2008 17:52

theg sprank: Feb 3, 2008; pillage your village

if anybody is interested (you probably aren't), you can get the number of cores available quasi-portably among unixes with sysconf(_SC_NPROCESSORS_ONLN) (both function and macro from unistd.h)

# ? Dec 18, 2008 23:16

Bitruder: Nov 29, 2003; Majoring in connect the dots and colouring

I need to create a temporary file and I would highly prefer to use streams on it. Does boost offer anything in this way? There's mkstemp but that doesn't use streams. I only really need this to work on Linux so it doesn't have to be 100% portable.

# ? Dec 19, 2008 17:17

Adbot: ADBOT LOVES YOU

# ? May 18, 2024 07:48

Vanadium: Jan 8, 2005

Bitruder posted:

I only really need this to work on Linux so it doesn't have to be 100% portable.

libstdc++ has an extension that might help you out there, if you are willing to take that total loss in portability: http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch38.html

# ? Dec 19, 2008 17:58

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

«‹›640 »

Avenging Dentist posted:

theg sprank posted:

hexadecimal posted:

Avenging Dentist posted:

ultra-inquisitor posted:

code:

hexadecimal posted:

quote:

hexadecimal posted:

code:

digibawb posted:

hexadecimal posted:

That Turkey Story posted:

code:

Painless posted:

code:

floWenoL posted:

That Turkey Story posted:

code:

code:

hexadecimal posted:

code:

code:

That Turkey Story posted:

hexadecimal posted:

code:

Bitruder posted:

code:

csammis posted:

ehnus posted:

almostkorean posted:

Ari posted:

csammis posted:

code:

code:

theg sprank posted:

rjmccall posted:

theg sprank posted:

almostkorean posted:

csammis posted:

top man page posted:

csammis posted:

Bitruder posted:

Bitruder posted:

Bitruder posted: