|Different STL support in one application email@example.com (Ashutosh) (2012-07-05)|
|DKIM-Signature:||v=1; a=rsa-sha256; c=simple; d=iecc.com; h=cc:from:subject:date:sender:message-id:mime-version:content-type:vbr-info; s=9604.4ff8a36f.k1207; firstname.lastname@example.org; bh=A8KRIIHk6bMwTk1nEWS8J57HvAwBzQQFrMsWYbM6kpM=; b=bMZOs0cVLccYqkHvtdy6JQxyxhu9ojEabkCKOaLBngbtItfuAByqHCTVsMDGB2TddHFYu7onpoeP5US9HarfRXhukIZv//zl05dYB2VI2ZdfRBkxiZ6HTiE02MydCFFS0GfdU0JYNWJhQpqrVioQMDI9hEydVUeaW1KvZCBSI4s=|
|VBR-Info:||md=iecc.com; mc=all; mv=dwl.spamhaus.org|
|Date:||Thu, 5 Jul 2012 23:54:52 -0700 (PDT)|
|Posted-Date:||07 Jul 2012 17:00:30 EDT|
I came across a requirement where we need to support 2 type of STL
(GNU STL & RoughWay STL) in customer applications. For this we have
both the STL support with our compiler ready, but thats not only
sufficient we came across one major problem:
1) If a binary compiled with GNU STL and it interacts with Rough Way STL,
then because of different object layout it fails.
i.e. GNU STL vector passed to function which expects Rough Way STL objects.
2) There are some pre-compiled third party libraries(Compiled with
GNU/RoughWay headers) which we can't change.
The same interaction problem here also.
1) Write generic wrappers for both the libraries and use them.
2) Write a runtime library which automatically converts objects when
different object layout interaction happens.
These are only raw solutions, each has some issues.
Any idea, how to solve this problem ?
Return to the
Search the comp.compilers archives again.