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 »

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

The_Franz posted:

I don't think so. Even if the void* types of the inline function parameters are discarded, he is still casting the pointer types to int* and then dereferencing the value, not casting the values directly. That shouldn't do any conversions or rounding.

He was talking about time_t potentially being a float, not OneEightHundred's question.

# ? Aug 21, 2013 14:40

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 11:34

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Continuing on my time management woes, if I want to zero out a tm struct (or any other POD object for that matter), should I do memset(&tmObj, 0, sizeof(tm)) or memset(&tmObj, 0, sizeof(tmObj)), or does it actually matter? (or am I doing it wrong and am about to get my dick bitten off?)

Ciaphas fucked around with this message at 22:52 on Aug 22, 2013

# ? Aug 22, 2013 22:47

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Ciaphas posted:

Continuing on my time management woes, if I want to zero out a tm struct (or any other POD object for that matter), should I do memset(&tmObj, 0, sizeof(tm)) or memset(&tmObj, 0, sizeof(tmObj)), or does it actually matter? (or am I doing it wrong and am about to get my dick bitten off?)

Would be "sizeof(struct tm)" for the former example, which works fine.
Between that and sizeof(tmObj) it doesn't matter, but sizeof(tmObj) is generally preferred in that then if something gets refactored in future such that now it's a different kind of object, and you still want to zero it, you don't have to change the code. On the other hand, if you later extended struct tm into some sort of child class, and tmObj is now of that extended class, and you only wanted to zero the struct tm part of it, then sizeof(struct tm) would be the better way.

But in practice the answer is mostly it doesn't matter.

# ? Aug 22, 2013 22:59

Combat Pretzel: Jun 23, 2004; No, seriously... what kurds?!

Any reason why some simple integer math goes randomly sideways? The code's more or less this:

code:

void DoStuff(float *samples, int lenSamples)
{
    auto finalBuffer = ref new Array<float>(lenSamples);
    memcpy(finalBuffer->Data, samples, lenSamples * sizeof(float));
    ...
}

I had the application failing randomly with memory access violations. I've tracked it down to the memcpy function. Being stumped what the hell was wrong, I wrote a proxy to memcpy that tracks the pointers and size argument and compares them to the previous call. Whenever the memcpy fails, the size argument passed to it is double of that on the last call, even tho lenSamples is still the same value (I'm tracking this, too). sizeof(float) is probably converted to a constant by the compiler, so what the hell could be going on here?

The actual bits if anyone cares:

code:

void fdebug(const wchar_t *format, ...)
{
		wchar_t buf[4096];
		va_list args;
		va_start(args, format);
		_vsnwprintf_s(buf, 4096, format, args);
		OutputDebugStringW(buf);
		va_end(args);
}

int prevsrc = 0, prevdst = 0, prevsize = 0;
bool memcpy_proxy(void *dst, const void *src, size_t s, int line)
{
	bool doh = false;
	__try
	{
		memcpy(dst, src, s);
		prevsrc = (int)src;
		prevdst = (int)dst;
		prevsize = (int)s;
	}
	__except(EXCEPTION_EXECUTE_HANDLER)
	{
		fdebug(L"memcpy gently caress up! Line no(%d): src = %x, dst = %x, s = %d, psrc = %x, pdst = %x, ps = %d\n",
				line, (int)src, (int)dst, (int)s, prevsrc, prevdst, prevsize);
		doh = true;
	}
	return doh;
}

...
finalBuf = ref new Platform::Array<float>(lenTempbuf * requestedChannels);
if(memcpy_proxy(finalBuf->Data, tempbuf, lenTempbuf * requestedChannels * sizeof(float), __LINE__))
{
	fdebug(L"Samples in this buffer (%d), compared to last buffer (%d)\n", samples, prevsamples);
	fdebug(L"Current lenTempbuf (%d), compared to last lenTempbuf (%d)\n", lenTempbuf, prevlen);
	fdebug(L"Current finalBuf length (%d), compared to last length (%d)\n", finalBuf->Length, prevfinal);
	fdebug(L"Current requested channels (%d), compared to last channels (%d)\n", requestedChannels, prevchan);
	throw ref new Exception(0xDEADF00D);
}
...
prevsamples = samples;
prevlen = lenTempbuf;
prevfinal = finalBuf->Length;
prevchan = requestedChannels;
...

code:

First-chance exception at 0x5688108E (msvcr110d.dll) in TomServo.AudioAnalyzer.exe: 0xC0000005: Access violation reading location 0x0830A000.

memcpy gently caress up! Line no(400): src = 83056c0, dst = 82c0f38, s = 35280, psrc = 81c5168, pdst = 83056c0, ps = 17640
Samples in this buffer (2205), compared to last buffer (2205)
Current lenTempbuf (4410), compared to last lenTempbuf (4410)
Current finalBuf length (8820), compared to last length (8820)
Current requested channels (2), compared to last channels (2)

First-chance exception at 0x777F4B32 in TomServo.AudioAnalyzer.exe: Microsoft C++ exception:
Platform::Exception ^ at memory location 0x0B56E858. HRESULT:0xDEADF00D

Combat Pretzel fucked around with this message at 19:28 on Aug 31, 2013

# ? Aug 31, 2013 19:25

Bonfire Lit: Jul 9, 2008; If you're one of the sinners who caused this please unfriend me now.

Not seeing any broken math in your sample output there: lenTempbuf (4410) * requestedChannels (2) * sizeof float (4) == s (35280). Are you sure that tempbuf is large enough to hold the data you're trying to copy out of it (it's a read that fails, not a write)?

# ? Sep 1, 2013 00:45

Combat Pretzel: Jun 23, 2004; No, seriously... what kurds?!

It turned out to be sort of a clusterfuck. I was using the proxy function in two places and forgot to remove the unnecessary use of it, before adding all the logging, leading me on a wild goose chase.

Turned out to be some bad math making, i.e. the multiplication with requestedChannels, the reads (and the output buffers) double of what they should have been. The upper layers are just test code that didn't do any checks, so the too large buffers went unnoticed. Anyway, the reads only failed when the related memory allocation was at the end of the heap, tripping the virtual memory manager or whatever, which didn't always happen depending how the heap was being fragmented on app start.

Visual Studio displaying a call stack like a swiss cheese didn't help either. Which got all of this madness started to begin with. It showed me the memcpy that broke and a caller two levels up, but nothing in between.

Combat Pretzel fucked around with this message at 03:05 on Sep 1, 2013

# ? Sep 1, 2013 03:03

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Combat Pretzel posted:

It showed me the memcpy that broke and a caller two levels up, but nothing in between.

http://randomascii.wordpress.com/2013/08/19/developers-rejoicewindows-7-stack-corruption-fixed/ may be relevant.

# ? Sep 1, 2013 03:16

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Ciaphas posted:

I hate this/these loving language(s).

It's actually a pretty good idea to get down what the guarantees of types are and make your conversions as explicit as possible. I've seen numerous codebases run into severe problems porting to 64-bit for example because they cast address differences (or raw pointers) to int. Newer high-level languages often require very explicit conversions between types that are of questionable compatibility or unspecified accuracy, i.e. C# uses TimeSpan rather than a numeric type and converting to and from chars requires using a text encoding.

OneEightHundred fucked around with this message at 15:31 on Sep 1, 2013

# ? Sep 1, 2013 15:25

Combat Pretzel: Jun 23, 2004; No, seriously... what kurds?!

Plorkyeran posted:

http://randomascii.wordpress.com/2013/08/19/developers-rejoicewindows-7-stack-corruption-fixed/ may be relevant.

Says that Windows 8 doesn't have that issue. Strange.

# ? Sep 1, 2013 23:43

xgalaxy: Jan 27, 2004; i write code

If I dont want or need a cross platform GUI, for Windows development, is MFC the way to go?
This is for a personal project. I've used Qt before at work, and I'd rather avoid it.

# ? Sep 2, 2013 08:51

Computer viking: May 30, 2011; Now with less breakage.

xgalaxy posted:

If I dont want or need a cross platform GUI, for Windows development, is MFC the way to go?
This is for a personal project. I've used Qt before at work, and I'd rather avoid it.

I'd say C#/.net, which is mostly quite nice - but if you want c++ I'll refrain from giving unfounded advice.

# ? Sep 2, 2013 09:13

xgalaxy: Jan 27, 2004; i write code

Computer viking posted:

I'd say C#/.net, which is mostly quite nice - but if you want c++ I'll refrain from giving unfounded advice.

I could go C# for the GUI I guess, but I'd have to use /CLR or whatever it is so I can write C++ as well,

# ? Sep 2, 2013 09:29

hooah: Feb 6, 2006; WTF?

Is there an introduction to creating/editing makefiles that doesn't assume I know anything about g++ commands? I'd been using MSVC 2010 for a few months, since that's what we were provided in my first programming class, but the professor of my current class (at a different school) recommends we get familiar with NetBeans on Linux, which apparently (judging by my difficulty thus far) means we need to deal with makefiles.

While this may be covered soon in the class, I'd like to get a head start on it if I can.

# ? Sep 2, 2013 14:45

OzyMandrill: Aug 12, 2013; Look upon my words
and despair

xgalaxy posted:

If I dont want or need a cross platform GUI, for Windows development, is MFC the way to go?
This is for a personal project. I've used Qt before at work, and I'd rather avoid it.

I would reckon so, yes. Personally, I'm rubbish at it but would love to be better, but the guys I know who use it a lot can knock up functional UIs very quickly (and use it as the weapon of choice for small windows only tools)
If you use Visual Studio then there are a bunch of things that make the MFC stuff much easier too.

# ? Sep 2, 2013 14:54

Vinterstum: Jul 30, 2003

hooah posted:

Is there an introduction to creating/editing makefiles that doesn't assume I know anything about g++ commands? I'd been using MSVC 2010 for a few months, since that's what we were provided in my first programming class, but the professor of my current class (at a different school) recommends we get familiar with NetBeans on Linux, which apparently (judging by my difficulty thus far) means we need to deal with makefiles.

While this may be covered soon in the class, I'd like to get a head start on it if I can.

Rather than directly creating/editing your own Makefiles, I'd recommend looking into a higher level build file generator like CMake. Basically means you set up your build in CMakeLists.txt and CMake can use that to generate either Makefiles, or VS2010 projects, or XCode projects, etc, etc. Saves on some grunt work.

There's some alternatives to cmake like scons, premake, gyp etc, too. For something simple it probably doesn't really matter what you use.

EDIT: Assuming this is OK for your class of course, and Makefiles aren't actually themselves on the curriculum.

# ? Sep 2, 2013 16:48

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

I really can't imagine MFC ever being the correct choice for a new project.

# ? Sep 2, 2013 21:08

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Windows Forms is pretty much the thing to use for Windows-only UI right now. If you need native code with it then just write a mixed-mode app.

e: WPF is probably better for larger ongoing projects, WinForms is better for small stuff because WPF's setup time is annoying (gently caress XAML).

OneEightHundred fucked around with this message at 22:23 on Sep 2, 2013

# ? Sep 2, 2013 21:17

Posting Principle: Dec 10, 2011; by Ralp

If you don't need to use C++, WPF is the way to go. It's probably the way to go even if you need C++. Don't use MFC jesus christ.

# ? Sep 2, 2013 21:34

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Plorkyeran posted:

I really can't imagine MFC ever being the correct choice for a new project.

This very much. You'd be better off using the old Windows C APIs and GDI (they're actually fairly inoffensive) than the insane bullshit of hideous secret macros and junk that MFC is made of.

(This is not a recommendation of the old stuff.)

# ? Sep 2, 2013 23:41

more like dICK: Feb 15, 2010; This is inevitable.

Is C99 widespread enough that it can be safely used in a library meant for public consumption, or should I be sticking to C89? Related, what's the go-to utility library for C these days, Apache or Glib?

e: Actually I would love any links to good resources about modern C. I'm stuck in C++ land.

# ? Sep 3, 2013 00:30

Qwertycoatl: Dec 31, 2008

Qwertycoatl posted:

Microsoft's support for C99 is somewhere between patchy and nonexistent, so if you want people to compile it in visual studio then stick to C89.

2013 is supposed to implement the majority of it.

# ? Sep 3, 2013 01:54

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

It is probably easier to learn C# and WPF from scratch than to learn just a Windows C++ GUI framework from scratch.

e: and C++/CLI (not the newer WinRT stuff or whatever) is intended only for use gluing other components together. It's not that you can't do actual projects in it from a language perspective, but your tools are gimped: There's no Intellisense, and at least VS2010 is buggy as hell when you've got a C++/CLI project in your solution.

# ? Sep 3, 2013 02:07

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Yeah, I would strong advise against using C++/CLI for anything other than creating .NET bindings for a C++ library. Even a C library is likely to be easier with PInvoke in the long run.

# ? Sep 3, 2013 03:16

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

Having done both, I'd say they're about the same. The problems you face in each case are completely different but the volume of them seems similar.

# ? Sep 3, 2013 03:28

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

GrumpyDoctor posted:

VS2010 is buggy as hell when you've got a C++/CLI project in your solution.

It's not that buggy, the main problem is that you have to manually set debugging to mixed mode or it'll vomit any time something goes wrong in the managed code. The Auto debug mode option basically doesn't work.

# ? Sep 3, 2013 04:51

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

OneEightHundred posted:

It's not that buggy, the main problem is that you have to manually set debugging to mixed mode or it'll vomit any time something goes wrong in the managed code. The Auto debug mode option basically doesn't work.

The WPF designer will throw an exception under certain circumstances when you try to load design view of your XAML (you'll have to unload the C++/CLI project and remove it from the solution), and sometimes you have to do solution-wide rebuilds for no reason. It's pretty easy to actually crash cl.exe in C++/CLI code.

# ? Sep 3, 2013 06:32

Dren: Jan 5, 2001; Pillbug

hooah posted:

Is there an introduction to creating/editing makefiles that doesn't assume I know anything about g++ commands? I'd been using MSVC 2010 for a few months, since that's what we were provided in my first programming class, but the professor of my current class (at a different school) recommends we get familiar with NetBeans on Linux, which apparently (judging by my difficulty thus far) means we need to deal with makefiles.

While this may be covered soon in the class, I'd like to get a head start on it if I can.

Simple makefiles aren't too tough. If your project's not that big then it's probably easier to learn to write a simple makefile than to tangle with cmake, though cmake's not too bad either. Here's some basics about writing a makefile.

Here's how to make 'myprog' from myprog.cpp

code:

myprog: myprog.cpp
	g++ -Wall -o myprog myprog.cpp

clean:
	rm -rf myprog

You can type clean to clear out the results of a previous build. The -o option to g++ tells it to name the resulting file 'myprog' instead of 'a.out'. The -Wall option means "Warnings all". It's very important to leave this option on, especially if you're a beginner. Otherwise you might miss important error messages.

Here's how to make 'myprog' from myprog.cpp and myclass.cpp

code:

myprog: myprog.cpp myclass.cpp
	g++ -Wall -o myprog myprog.cpp myclass.cpp

clean:
	rm -rf myprog

Notice that myprog depends on myprog.cpp and myclass.cpp. It should probably depend on any headers that you wrote as well but I'm going to ignore headers since this is a really simple makefile.

You can compile individual source files one at a time into object files then later link them into an executable or a library e.g.

code:

myprog: myprog.o myclass.o
	g++ -o myprog myprog.o myclass.o

myprog.o: myprog.cpp
	g++ -Wall -c myprog.cpp

myclass.o: myclass.cpp
	g++ -Wall -c myclass.cpp

clean:
	rm -rf myprog *.o

The -c option to g++ tells it to compile the source files but not link. The resulting files have a .o suffix and are called object files. Notice that -Wall is no longer in the first step. It's not needed there any longer because the first step isn't doing any compiling, it's just linking.

The syntax is getting repetitive though. GNU Make has Automatic Variables that can be used to keep from repeating stuff so much. Here's the last makefile but with automatic variables:

code:

myprog: myprog.o myclass.o
	g++ -o $@ $^

myprog.o: myprog.cpp
	g++ -Wall -c $^

myclass.o: myclass.cpp
	g++ -Wall -c $^

clean:
	rm -rf myprog *.o

Alright, that's a lot less typing. $@ means the name of the target (myprog). $^ means the names of all of the prerequisites.

But we can do better. Make also has Pattern Rules, a type of Implicit Rule. You can use pattern rules to say "this is how to make any .o file from a corresponding .cpp file".

code:

myprog: myprog.o myclass.o
	g++ -o $@ $^

%.o: %.cpp
	g++ -Wall -c $^

clean:
	rm -rf myprog *.o

Make will look at myprog and see the prereqs of 'myprog.o' and 'myclass.o'. Since there are no explicit targets for creating those prereqs it will look for an implicit rule to build them. Make will see that there is an implicit rule for building .o files. Any .o file can be built using a .cpp file that has the same name before the extension. Make will then build both of the needed .o files using the implicit rule.

So this is pretty good! Not a ton of typing and all of the source is building. But we can do a little better by adding some make variables. I'm going to use several fairly common variables here.

code:

CXX=g++
CXXFLAGS=-Wall
IFLAGS=-Iinclude/

OBJECTS=myprog.o myclass.o

myprog: $(OBJECTS)
	$(CXX) -o $@ $^

%.o: %.cpp
	$(CXX) $(CXXFLAGS) $(IFLAGS) -c $^

clean:
	rm -rf myprog *.o

A variable has been added to alias g++ to CXX. This isn't super necessary but it's very common to see it. The idea, I suppose, is that this makes it easy to switch compilers.
Another variable has been added to allow you to pass compile flags to g++, CXXFLAGS. In it, I've put -Wall. You could put other flags there too, g++ has many options.
The -I option, listed in IFLAGS, allows you to tell make where to look for header files (if you didn't put them in the base directory or if you've included a system header that g++ can't find). Here, I've assumed your project has an 'include' directory.
Lastly, I've added a variable to store your object file names and called it OBJECTS. This is a fairly common thing to do and it can become useful to have OBJECTS listings at the top of the file if you need to do things like build multiple binaries and libraries inside the same makefile.

One last trick. It's a tad nicer to list sources instead of objects since sources are what you've actually got, even though objects are the prereqs for myprog. Here's a sample of how to use make's pattern substitution tools to get a list of objects from a list of sources.

code:

CXX=g++
CXXFLAGS=-Wall
IFLAGS=-Iinclude/

SOURCES=myprog.cpp myclass.cpp
OBJECTS=$(SOURCES:%.cpp=%.o)

myprog: $(OBJECTS)
	$(CXX) -o $@ $^

%.o: %.cpp
	$(CXX) $(CXXFLAGS) $(IFLAGS) -c $^

clean:
	rm -rf myprog *.o

I hope that wasn't too hard to follow. Unfortunately, these makefiles neglect header dependencies so if all you change is a header you'll have to clean and rebuild. I'm not sure how to easily add automatic header dependencies without involving g++'s -MM option for automatically resolving header dependencies, then pulling them in with make's include directive. I think it's not that bad to do I just can't quite remember the syntax.

# ? Sep 5, 2013 03:11

Rothon: Jan 4, 2012

I would advise using the -Wextra flag as well, as it adds a bunch of useful warnings that -Wall doesn't.

# ? Sep 5, 2013 04:12

hooah: Feb 6, 2006; WTF?

Dren posted:

makefile info

Thanks, that's way more helpful than most of the stuff I'd found by searching, and more helpful than any of it. Now I can use NetBeans again!

# ? Sep 5, 2013 12:58

Dren: Jan 5, 2001; Pillbug

hooah posted:

Thanks, that's way more helpful than most of the stuff I'd found by searching, and more helpful than any of it. Now I can use NetBeans again!

One huge gotcha for people coming from procedural languages is the way variable expansion is handled in make. Expansion of variables created with the '=' operator is deferred until the variable is used. You can read more about variable behavior at The Two Flavors of Variables. Deferred recursive variable expansion mostly will behave the way you expect. Until, that is, it looks like you're defining something but the definition doesn't seem to be activated when you need it and you can't figure out what is going on.

If you'd like to get a deeper understanding of make, please read Writing Makefiles and pay particular attention to the section How make Reads a Makefile. Understanding how make processes a makefile can save you from some enormous headaches with make.

# ? Sep 5, 2013 16:39

shodanjr_gr: Nov 20, 2007

I got a programming pattern question.

I have an established library and for some (not all) of the exposed classes, I'd like to place proxies in front of them (in order to alter the functionality). For the components of the library that are not proxied, I'd like them to maintain their original functionality.

I'd like my proxy layer to offer the exact same interface as the library that it's sitting in front of (same namespaces, same symbols). The problem is that the proxy layer also has to link against the library itself so, if it exposes the exact same interface, i'll end up with symbol name conflicts.

Is there some elegant way to do this (without editing the source of the original library)?

# ? Sep 6, 2013 18:37

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

shodanjr_gr posted:

Is there some elegant way to do this (without editing the source of the original library)?

Namespaces. Use one for your proxy; if the original library doesn't use one you can do ::Function to call theirs not yours, within your proxy. Then in your code that wants to use your proxy and not [directly] the original library, you do using YourNameSpace so it will work without changing any other code.

Edit: and you make sure the original library's headers aren't included by your code other than in the proxy's cpp files.

roomforthetuna fucked around with this message at 22:25 on Sep 6, 2013

# ? Sep 6, 2013 20:13

High Protein: Jul 12, 2009

If you don't want to add an additional namespace to your calling code, it gets a bit gross. In short, you never want the calling code to see the original namespace, only the wrapper's:

original.h:

code:

namespace originalns
{
	class cls1
	{
	public:
		void bla(); //outputs "original"
	};
};

wrapper.h:

code:

namespace wrapperns
{
	namespace originalns
	{
		class cls1
		{
		public:
			cls1();
			void bla();
		private:
			void* m_Original;
		};
	};
	
};
#ifndef WRAPPER_CPP
using namespace wrapperns;
#endif

wrapper.cpp:

code:

#include <cstdio>
#include <original.h>
#define WRAPPER_CPP
#include "wrapper.h"

wrapperns::originalns::cls1::cls1()
:m_Original(new ::originalns::cls1)
{

}


void wrapperns::originalns::cls1::bla()
{
	puts("wrapper!");
	static_cast<::originalns::cls1*>(m_Original)->bla();
}

If you now create an original::cls1 and call bla, it will print "wrapper" and then "original". Also works if original lives in some dll.

# ? Sep 6, 2013 20:45

shodanjr_gr: Nov 20, 2007

High Protein posted:

If you don't want to add an additional namespace to your calling code, it gets a bit gross. In short, you never want the calling code to see the original namespace, only the wrapper's:

Thanks, this is actually very neat.

However, the situation is slightly more complicated (I should have probably included this in the original question). The classes that I want to proxy are parts of a complex hierarchy (a scenegraph) so an approach like this would probably break interchangeability (unless every class in the hierarchy was put behind a proxy).

Instead of using a pimpl approach (which would also require writing function stubs for every function in originalcls). Is there a way to get this to work through inheritance? Optimally, wrappercls would want to inherit from originalcls in order to get all the functionality and just overload relevant methods. But obviously I wouldn't be able to do:

code:


namespace wrapperns
{
	namespace originalns
	{
		class wrappercls : public originalns::cls1
		{

		}
	}
}

since in order to maintain the interchangeability of libraries, cls1 and wrappercls would actually have to be the SAME name.

Would this work?

code:


namespace helpernamespace
{
	#include "original.h"
}

namespace wrapperns
{
	namespace originalns
	{
		class wrappercls : public helpernamespace::originalns::cls1
		{

		}
	}
}

Thanks again goons!

# ? Sep 6, 2013 21:43

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

Inheriting from a class in a way that it wasn't intended to be inherited from is generally considered Very Poor Form: in the absolute best case the code is difficult to understand, in most cases something doesn't work right, and in the worst case you get memory leaks or crashes or something. It sounds like this will actually be a problem for you, because you want "interchangeability" but presumably the functions you're trying to wrap weren't declared as virtual, so if you try to use them as base methods you won't actually dispatch to the wrapped versions. (If they were declared as virtual then you don't have a problem here.)

If you did manage to kludge together a way to statically dispatch to something with your wrapped behavior without secretly injecting some namespace or something, I can't see how you wouldn't run afoul of the one definition rule, but maybe one of the wizards here has a magic solution.

# ? Sep 6, 2013 22:22

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

What you're doing sounds like a bad idea, but to answer the original question of "how do I replace some of the symbols from a library", one option is to write a wrapper around those symbols, compile the wrapper + original library into a shared library which does not expose the original symbol names, then write a second wrapper which maps the wrapped symbols back to the original names.

I would not recommend doing this unless you have no other options.

# ? Sep 6, 2013 22:41

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 11:34

Dren: Jan 5, 2001; Pillbug

If you have the source it's sounding like you might be better off writing a patch to the library and recompiling it.

# ? Sep 7, 2013 02:44

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

«‹›640 »

The_Franz posted:

Ciaphas posted:

code:

code:

code:

Combat Pretzel posted:

Ciaphas posted:

Plorkyeran posted:

xgalaxy posted:

Computer viking posted:

xgalaxy posted:

hooah posted:

Plorkyeran posted:

more like dICK posted:

more like dICK posted:

Qwertycoatl posted:

GrumpyDoctor posted:

OneEightHundred posted:

hooah posted:

code:

code:

code:

code:

code:

code:

code:

Dren posted:

hooah posted:

shodanjr_gr posted:

code:

code:

code:

High Protein posted:

code:

code: