Error due to ambiguous ostrstream while running bfc.C in ROOT6 #126
Labels
ROOT6
Issues and changes related to transition from ROOT5 to ROOT6
Comments
|
Hi Dmitri,
This is exactly the problem I mentioned on Wednesday (and just getting
back to now).
The problem is that we have a duplicate ostrstream class defined here--
StRoot/St_base/Stsstream.h
I guess in ROOT6, an #include has been exposed somewhere that leads to a
conflict
with the above code. So...
A possible solution would be to delete everything in Stsstream.h and
replace with
#include <strstream>
Testing in my geant4star area... I can at least load StMessMgr (which is
usually where
things fail for me).
Warnings about deprecated code are being issued during compilation,
though... code has been
deprecated since 1998. So we should be careful using this because it
could disappear at any moment...
Victor-- could you remind us of the history behind Stssream.h, and
whether we still
need it or not? Or what a better solution would be?
Cheers,
Jason
…On 2021-08-27 11:43, Dmitri Smirnov wrote:
When I try to run one of our tests in ROOT6 environment I get the
following error:
Processing bfc.C(10,
"pp2017,StiCA,btof,mtd,pp2pp,fmsDat,fmsPoint,fpsDat,BEmcChkStat,QAalltrigs,CorrX,OSpaceZ2,OGridLeak3D,-hitfilt",
"/star-test-data/quick/st_physics_18069061_raw_2000021.daq")...
In file included from input_line_37:1:
In file included from /star-sw/StRoot/macros/bfc.C:19:
In file included from /star-sw/.sl88_gcc789/include/StBFChain.h:22:
In file included from /star-sw/.sl88_gcc789/include/StChain.h:22:
In file included from /star-sw/.sl88_gcc789/include/StMaker.h:26:
/star-sw/.sl88_gcc789/include/StMessMgr.h:108:26: error: reference to
'ostrstream' is ambiguous
class StMessMgr : public ostrstream {
^
/star-sw/.sl88_gcc789/include/Stsstream.h:15:7: note: candidate found
by name lookup is 'ostrstream'
class ostrstream : public std::ostringstream {
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/backward/strstream:143:9:
note: candidate found by name lookup is 'std::ostrstream'
class ostrstream : public basic_ostream<char>
Any suggestions how to fix this? @perevbnlgov [1] @klendathu2k [2]
--
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [3], or unsubscribe
[4].
Triage notifications on the go with GitHub Mobile for iOS [5] or
Android [6].
Links:
------
[1] https://github.com/perevbnlgov
[2] https://github.com/klendathu2k
[3] #126
[4]
https://github.com/notifications/unsubscribe-auth/ANL4LVE4PGR4HIQIIB34GI3T66XCLANCNFSM5C5ZVHAQ
[5]
https://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!P4SdNyxKAPE!V8bmJOtXOISyUo-1cnxFnKajqe-ENutqDojv7XR6d-Q9Xr7P2Iv5FHeam8CFG2Y$
[6]
https://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!P4SdNyxKAPE!V8bmJOtXOISyUo-1cnxFnKajqe-ENutqDojv7XR6d-Q9Xr7P2Iv5FHeaFnO9Myk$
|
So, basically you are proposing to drop our local implementation of Anyway, for now I just renamed our 'ostrstream' to something different so it does not collide with the std:: one from wherever it is coming from. Enclosing it in a star:: namespace would probably be a better solution... Fortunately, we don't have many instances where |
plexoos
added
the
ROOT6
|
Victor-- could you remind us of the history behind Stssream.h, and
Yes I could. At the very beginning it was used very old and very ugly
version of stream.
When more new version came, it became completely incompatible with the
existing code.
Especially with Jeff Porter DB and Gene StMessage. This Stiustream was
used to keep
compatibility with old version of iostream and new one. When Root6 + new
C++ compiler
arised, it became not compatible again. I completely rewrote this
iostream and change
a lot of old code to be compatible with the latest iostrea version.
Unfortunately, as I have already told, O did not save it in CVS and
deleted by mistake.
When I was trying to recover, I used less strict version of C++ (from
Yuri)
and much less changes were needed to comply with this iostream problem.
Standard compilation was OK. But probably my easy way of fixing it, is
too easy.
So I need to come back and fix it using the latest version of iostream.
Victor
…On 2021-08-27 12:25, klendathu2k wrote:
Hi Dmitri,
This is exactly the problem I mentioned on Wednesday (and just getting
back to now).
The problem is that we have a duplicate ostrstream class defined
here--
StRoot/St_base/Stsstream.h
I guess in ROOT6, an #include has been exposed somewhere that leads to
a
conflict
with the above code. So...
A possible solution would be to delete everything in Stsstream.h and
replace with
#include <strstream>
Testing in my geant4star area... I can at least load StMessMgr (which
is
usually where
things fail for me).
Warnings about deprecated code are being issued during compilation,
though... code has been
deprecated since 1998. So we should be careful using this because it
could disappear at any moment...
Victor-- could you remind us of the history behind Stssream.h, and
whether we still
need it or not? Or what a better solution would be?
Cheers,
Jason
On 2021-08-27 11:43, Dmitri Smirnov wrote:
> When I try to run one of our tests in ROOT6 environment I get the
> following error:
>
> Processing bfc.C(10,
>
"pp2017,StiCA,btof,mtd,pp2pp,fmsDat,fmsPoint,fpsDat,BEmcChkStat,QAalltrigs,CorrX,OSpaceZ2,OGridLeak3D,-hitfilt",
> "/star-test-data/quick/st_physics_18069061_raw_2000021.daq")...
> In file included from input_line_37:1:
> In file included from /star-sw/StRoot/macros/bfc.C:19:
> In file included from /star-sw/.sl88_gcc789/include/StBFChain.h:22:
> In file included from /star-sw/.sl88_gcc789/include/StChain.h:22:
> In file included from /star-sw/.sl88_gcc789/include/StMaker.h:26:
> /star-sw/.sl88_gcc789/include/StMessMgr.h:108:26: error: reference
to
> 'ostrstream' is ambiguous
> class StMessMgr : public ostrstream {
> ^
> /star-sw/.sl88_gcc789/include/Stsstream.h:15:7: note: candidate
found
> by name lookup is 'ostrstream'
> class ostrstream : public std::ostringstream {
> ^
>
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/backward/strstream:143:9:
> note: candidate found by name lookup is 'std::ostrstream'
> class ostrstream : public basic_ostream<char>
>
> Any suggestions how to fix this? @perevbnlgov [1] @klendathu2k [2]
>
> --
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub [3], or unsubscribe
> [4].
> Triage notifications on the go with GitHub Mobile for iOS [5] or
> Android [6].
>
> Links:
> ------
> [1] https://github.com/perevbnlgov
> [2] https://github.com/klendathu2k
> [3] #126
> [4]
>
https://github.com/notifications/unsubscribe-auth/ANL4LVE4PGR4HIQIIB34GI3T66XCLANCNFSM5C5ZVHAQ
> [5]
>
https://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!P4SdNyxKAPE!V8bmJOtXOISyUo-1cnxFnKajqe-ENutqDojv7XR6d-Q9Xr7P2Iv5FHeam8CFG2Y$
> [6]
>
https://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!P4SdNyxKAPE!V8bmJOtXOISyUo-1cnxFnKajqe-ENutqDojv7XR6d-Q9Xr7P2Iv5FHeaFnO9Myk$
--
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [1], or unsubscribe
[2].
Triage notifications on the go with GitHub Mobile for iOS [3] or
Android [4].
Links:
------
[1]
#126 (comment)
[2]
https://github.com/notifications/unsubscribe-auth/ANQUL7MSQEDNBSII6E7APTDT664BHANCNFSM5C5ZVHAQ
[3]
https://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!P4SdNyxKAPE!WtvhmwSUqup7cjuOSPAjUuK4ajdcTtqYQO3Jkri709CMTRxus7XqFi4vxEafcA$
[4]
https://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!P4SdNyxKAPE!WtvhmwSUqup7cjuOSPAjUuK4ajdcTtqYQO3Jkri709CMTRxus7XqFi7G7v9Gwg$
|
|
Thanks. If I read correctly, coming up with a solution is a non-trivial
task.
First must re-implment your *stream, then modify many STAR codes.
So... just thinking out loud. Rather than reinventing the deprecated
wheel...
Why not move to something that replaced ostrstream?
https://stackoverflow.com/questions/10849656/what-should-i-use-instead-of-stdostrstream
Specifically...
std::stringstream
…On 2021-08-27 13:44, perevbnlgov wrote:
> Victor-- could you remind us of the history behind Stssream.h, and
Yes I could. At the very beginning it was used very old and very ugly
version of stream.
When more new version came, it became completely incompatible with the
existing code.
Especially with Jeff Porter DB and Gene StMessage. This Stiustream was
used to keep
compatibility with old version of iostream and new one. When Root6 +
new
C++ compiler
arised, it became not compatible again. I completely rewrote this
iostream and change
a lot of old code to be compatible with the latest iostrea version.
Unfortunately, as I have already told, O did not save it in CVS and
deleted by mistake.
When I was trying to recover, I used less strict version of C++ (from
Yuri)
and much less changes were needed to comply with this iostream
problem.
Standard compilation was OK. But probably my easy way of fixing it, is
too easy.
So I need to come back and fix it using the latest version of
iostream.
Victor
On 2021-08-27 12:25, klendathu2k wrote:
> Hi Dmitri,
>
> This is exactly the problem I mentioned on Wednesday (and just
getting
>
> back to now).
>
> The problem is that we have a duplicate ostrstream class defined
> here--
> StRoot/St_base/Stsstream.h
>
> I guess in ROOT6, an #include has been exposed somewhere that leads
to
> a
> conflict
> with the above code. So...
>
> A possible solution would be to delete everything in Stsstream.h and
> replace with
> #include <strstream>
>
> Testing in my geant4star area... I can at least load StMessMgr
(which
> is
> usually where
> things fail for me).
>
> Warnings about deprecated code are being issued during compilation,
> though... code has been
> deprecated since 1998. So we should be careful using this because it
> could disappear at any moment...
>
> Victor-- could you remind us of the history behind Stssream.h, and
> whether we still
> need it or not? Or what a better solution would be?
>
> Cheers,
> Jason
>
> On 2021-08-27 11:43, Dmitri Smirnov wrote:
>> When I try to run one of our tests in ROOT6 environment I get the
>> following error:
>>
>> Processing bfc.C(10,
>>
>
"pp2017,StiCA,btof,mtd,pp2pp,fmsDat,fmsPoint,fpsDat,BEmcChkStat,QAalltrigs,CorrX,OSpaceZ2,OGridLeak3D,-hitfilt",
>> "/star-test-data/quick/st_physics_18069061_raw_2000021.daq")...
>> In file included from input_line_37:1:
>> In file included from /star-sw/StRoot/macros/bfc.C:19:
>> In file included from /star-sw/.sl88_gcc789/include/StBFChain.h:22:
>> In file included from /star-sw/.sl88_gcc789/include/StChain.h:22:
>> In file included from /star-sw/.sl88_gcc789/include/StMaker.h:26:
>> /star-sw/.sl88_gcc789/include/StMessMgr.h:108:26: error: reference
> to
>> 'ostrstream' is ambiguous
>> class StMessMgr : public ostrstream {
>> ^
>> /star-sw/.sl88_gcc789/include/Stsstream.h:15:7: note: candidate
> found
>> by name lookup is 'ostrstream'
>> class ostrstream : public std::ostringstream {
>> ^
>>
>
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/backward/strstream:143:9:
>> note: candidate found by name lookup is 'std::ostrstream'
>> class ostrstream : public basic_ostream<char>
>>
>> Any suggestions how to fix this? @perevbnlgov [1] @klendathu2k [2]
>>
>> --
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub [3], or unsubscribe
>> [4].
>> Triage notifications on the go with GitHub Mobile for iOS [5] or
>> Android [6].
>>
>> Links:
>> ------
>> [1] https://github.com/perevbnlgov
>> [2] https://github.com/klendathu2k
>> [3] #126
>> [4]
>>
>
https://github.com/notifications/unsubscribe-auth/ANL4LVE4PGR4HIQIIB34GI3T66XCLANCNFSM5C5ZVHAQ
>> [5]
>>
>
https://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!P4SdNyxKAPE!V8bmJOtXOISyUo-1cnxFnKajqe-ENutqDojv7XR6d-Q9Xr7P2Iv5FHeam8CFG2Y$
>> [6]
>>
>
https://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!P4SdNyxKAPE!V8bmJOtXOISyUo-1cnxFnKajqe-ENutqDojv7XR6d-Q9Xr7P2Iv5FHeaFnO9Myk$
> --
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub [1], or unsubscribe
> [2].
> Triage notifications on the go with GitHub Mobile for iOS [3] or
> Android [4].
>
> Links:
> ------
> [1]
>
#126 (comment)
> [2]
>
https://github.com/notifications/unsubscribe-auth/ANQUL7MSQEDNBSII6E7APTDT664BHANCNFSM5C5ZVHAQ
> [3]
>
https://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!P4SdNyxKAPE!WtvhmwSUqup7cjuOSPAjUuK4ajdcTtqYQO3Jkri709CMTRxus7XqFi4vxEafcA$
> [4]
>
https://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!P4SdNyxKAPE!WtvhmwSUqup7cjuOSPAjUuK4ajdcTtqYQO3Jkri709CMTRxus7XqFi7G7v9Gwg$
--
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [1], or unsubscribe
[2].
Triage notifications on the go with GitHub Mobile for iOS [3] or
Android [4].
Links:
------
[1]
#126 (comment)
[2]
https://github.com/notifications/unsubscribe-auth/ANL4LVAANERBWZ7HMPMD4Y3T67FJFANCNFSM5C5ZVHAQ
[3]
https://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!P4SdNyxKAPE!QEDcpiGtWoogbce7AKzUvqI3e-kMzl1DQTJm1JN05uAHx2bVY8xumwH2AOHXDs4$
[4]
https://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!P4SdNyxKAPE!QEDcpiGtWoogbce7AKzUvqI3e-kMzl1DQTJm1JN05uAHx2bVY8xumwH2wQ3g0fU$
|
|
Why not move to something that replaced ostrstream?
https://stackoverflow.com/questions/10849656/what-should-i-use-instead-of-stdostrstream
Specifically...
It was exactly what i did and lost
<sstream>, basic_stringstream
Victor
…On 2021-08-27 15:29, klendathu2k wrote:
Thanks. If I read correctly, coming up with a solution is a
non-trivial
task.
First must re-implment your *stream, then modify many STAR codes.
So... just thinking out loud. Rather than reinventing the deprecated
wheel...
Why not move to something that replaced ostrstream?
https://stackoverflow.com/questions/10849656/what-should-i-use-instead-of-stdostrstream
[1]
Specifically...
std::stringstream
On 2021-08-27 13:44, perevbnlgov wrote:
>> Victor-- could you remind us of the history behind Stssream.h, and
> Yes I could. At the very beginning it was used very old and very
ugly
> version of stream.
> When more new version came, it became completely incompatible with
the
>
> existing code.
> Especially with Jeff Porter DB and Gene StMessage. This Stiustream
was
>
> used to keep
> compatibility with old version of iostream and new one. When Root6 +
> new
> C++ compiler
> arised, it became not compatible again. I completely rewrote this
> iostream and change
> a lot of old code to be compatible with the latest iostrea version.
> Unfortunately, as I have already told, O did not save it in CVS and
> deleted by mistake.
> When I was trying to recover, I used less strict version of C++
(from
> Yuri)
> and much less changes were needed to comply with this iostream
> problem.
> Standard compilation was OK. But probably my easy way of fixing it,
is
>
> too easy.
> So I need to come back and fix it using the latest version of
> iostream.
> Victor
>
> On 2021-08-27 12:25, klendathu2k wrote:
>> Hi Dmitri,
>>
>> This is exactly the problem I mentioned on Wednesday (and just
> getting
>>
>> back to now).
>>
>> The problem is that we have a duplicate ostrstream class defined
>> here--
>> StRoot/St_base/Stsstream.h
>>
>> I guess in ROOT6, an #include has been exposed somewhere that leads
> to
>> a
>> conflict
>> with the above code. So...
>>
>> A possible solution would be to delete everything in Stsstream.h
and
>> replace with
>> #include <strstream>
>>
>> Testing in my geant4star area... I can at least load StMessMgr
> (which
>> is
>> usually where
>> things fail for me).
>>
>> Warnings about deprecated code are being issued during compilation,
>> though... code has been
>> deprecated since 1998. So we should be careful using this because
it
>> could disappear at any moment...
>>
>> Victor-- could you remind us of the history behind Stssream.h, and
>> whether we still
>> need it or not? Or what a better solution would be?
>>
>> Cheers,
>> Jason
>>
>> On 2021-08-27 11:43, Dmitri Smirnov wrote:
>>> When I try to run one of our tests in ROOT6 environment I get the
>>> following error:
>>>
>>> Processing bfc.C(10,
>>>
>>
>
"pp2017,StiCA,btof,mtd,pp2pp,fmsDat,fmsPoint,fpsDat,BEmcChkStat,QAalltrigs,CorrX,OSpaceZ2,OGridLeak3D,-hitfilt",
>>> "/star-test-data/quick/st_physics_18069061_raw_2000021.daq")...
>>> In file included from input_line_37:1:
>>> In file included from /star-sw/StRoot/macros/bfc.C:19:
>>> In file included from
/star-sw/.sl88_gcc789/include/StBFChain.h:22:
>>> In file included from /star-sw/.sl88_gcc789/include/StChain.h:22:
>>> In file included from /star-sw/.sl88_gcc789/include/StMaker.h:26:
>>> /star-sw/.sl88_gcc789/include/StMessMgr.h:108:26: error: reference
>> to
>>> 'ostrstream' is ambiguous
>>> class StMessMgr : public ostrstream {
>>> ^
>>> /star-sw/.sl88_gcc789/include/Stsstream.h:15:7: note: candidate
>> found
>>> by name lookup is 'ostrstream'
>>> class ostrstream : public std::ostringstream {
>>> ^
>>>
>>
>
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/backward/strstream:143:9:
>>> note: candidate found by name lookup is 'std::ostrstream'
>>> class ostrstream : public basic_ostream<char>
>>>
>>> Any suggestions how to fix this? @perevbnlgov [1] @klendathu2k [2]
>>>
>>> --
>>> You are receiving this because you were mentioned.
>>> Reply to this email directly, view it on GitHub [3], or
unsubscribe
>>> [4].
>>> Triage notifications on the go with GitHub Mobile for iOS [5] or
>>> Android [6].
>>>
>>> Links:
>>> ------
>>> [1] https://github.com/perevbnlgov
>>> [2] https://github.com/klendathu2k
>>> [3] #126
>>> [4]
>>>
>>
>
https://github.com/notifications/unsubscribe-auth/ANL4LVE4PGR4HIQIIB34GI3T66XCLANCNFSM5C5ZVHAQ
>>> [5]
>>>
>>
>
https://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!P4SdNyxKAPE!V8bmJOtXOISyUo-1cnxFnKajqe-ENutqDojv7XR6d-Q9Xr7P2Iv5FHeam8CFG2Y$
>>> [6]
>>>
>>
>
https://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!P4SdNyxKAPE!V8bmJOtXOISyUo-1cnxFnKajqe-ENutqDojv7XR6d-Q9Xr7P2Iv5FHeaFnO9Myk$
>> --
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub [1], or unsubscribe
>> [2].
>> Triage notifications on the go with GitHub Mobile for iOS [3] or
>> Android [4].
>>
>> Links:
>> ------
>> [1]
>>
>
#126 (comment)
>> [2]
>>
>
https://github.com/notifications/unsubscribe-auth/ANQUL7MSQEDNBSII6E7APTDT664BHANCNFSM5C5ZVHAQ
>> [3]
>>
>
https://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!P4SdNyxKAPE!WtvhmwSUqup7cjuOSPAjUuK4ajdcTtqYQO3Jkri709CMTRxus7XqFi4vxEafcA$
>> [4]
>>
>
https://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!P4SdNyxKAPE!WtvhmwSUqup7cjuOSPAjUuK4ajdcTtqYQO3Jkri709CMTRxus7XqFi7G7v9Gwg$
> --
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub [1], or unsubscribe
> [2].
> Triage notifications on the go with GitHub Mobile for iOS [3] or
> Android [4].
>
> Links:
> ------
> [1]
>
#126 (comment)
> [2]
>
https://github.com/notifications/unsubscribe-auth/ANL4LVAANERBWZ7HMPMD4Y3T67FJFANCNFSM5C5ZVHAQ
> [3]
>
https://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!P4SdNyxKAPE!QEDcpiGtWoogbce7AKzUvqI3e-kMzl1DQTJm1JN05uAHx2bVY8xumwH2AOHXDs4$
> [4]
>
https://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!P4SdNyxKAPE!QEDcpiGtWoogbce7AKzUvqI3e-kMzl1DQTJm1JN05uAHx2bVY8xumwH2wQ3g0fU$
--
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [2], or unsubscribe
[3].
Triage notifications on the go with GitHub Mobile for iOS [4] or
Android [5].
Links:
------
[1]
https://urldefense.com/v3/__https://stackoverflow.com/questions/10849656/what-should-i-use-instead-of-stdostrstream__;!!P4SdNyxKAPE!QtvkB0BDXDGM_vZapxEImHkpkPQ81xHt-WVS7lAZuXmuCr8U9Kn9Fdmkk6ZUdQ$
[2]
#126 (comment)
[3]
https://github.com/notifications/unsubscribe-auth/ANQUL7LMDLVQXUWOBCOVKI3T67RR5ANCNFSM5C5ZVHAQ
[4]
https://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!P4SdNyxKAPE!QtvkB0BDXDGM_vZapxEImHkpkPQ81xHt-WVS7lAZuXmuCr8U9Kn9Fdl3uzBNzQ$
[5]
https://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!P4SdNyxKAPE!QtvkB0BDXDGM_vZapxEImHkpkPQ81xHt-WVS7lAZuXmuCr8U9Kn9FdnUVSH3Tg$
|
Is there anything wrong with renaming the redefined |
|
Nothing wrong, per se. But we're maintaining a piece of code that can
be replaced by something
in the STL. I think it's worth a little effort here. I have started to
refactor codes to make this
replacement. If I can't finish (leaving for vacation days early
tomorrow), I'll push the branch in
whatever state it is and point you + Victor to it.
…On 2021-08-27 16:40, Dmitri Smirnov wrote:
>> Why not move to something that replaced ostrstream?
>>
>
https://stackoverflow.com/questions/10849656/what-should-i-use-instead-of-stdostrstream
>> [1] Specifically...
>
> It was exactly what i did and lost , basic_stringstream
Is there anything wrong with renaming the redefined ostrstream to
something else in order to avoid collision with std::ostrstream?
--
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [2], or unsubscribe
[3].
Triage notifications on the go with GitHub Mobile for iOS [4] or
Android [5].
Links:
------
[1]
https://urldefense.com/v3/__https://stackoverflow.com/questions/10849656/what-should-i-use-instead-of-stdostrstream__;!!P4SdNyxKAPE!XT8AUmN3rafqVZV6VzRrf-C8wReaq3e5lfVuxQ8nt88_dP1b1niOQzoYdI8R1kg$
[2]
#126 (comment)
[3]
https://github.com/notifications/unsubscribe-auth/ANL4LVEBC2PCATM34H7PXDDT67Z4XANCNFSM5C5ZVHAQ
[4]
https://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!P4SdNyxKAPE!XT8AUmN3rafqVZV6VzRrf-C8wReaq3e5lfVuxQ8nt88_dP1b1niOQzoYb1Q07G4$
[5]
https://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!P4SdNyxKAPE!XT8AUmN3rafqVZV6VzRrf-C8wReaq3e5lfVuxQ8nt88_dP1b1niOQzoY1k--PAc$
|
|
FYI--
On my repo I have a possible solution, replacing ostrstream w/
ostringstream.
https://github.com/klendathu2k/star-sw-1/tree/star-root6-stringstream
Code compiles. Have made no other tests than that.
…On 2021-08-27 17:17, jwebb wrote:
Nothing wrong, per se. But we're maintaining a piece of code that can
be replaced by something
in the STL. I think it's worth a little effort here. I have started
to refactor codes to make this
replacement. If I can't finish (leaving for vacation days early
tomorrow), I'll push the branch in
whatever state it is and point you + Victor to it.
On 2021-08-27 16:40, Dmitri Smirnov wrote:
>>> Why not move to something that replaced ostrstream?
>>>
>>
> https://stackoverflow.com/questions/10849656/what-should-i-use-instead-of-stdostrstream
>>> [1] Specifically...
>>
>> It was exactly what i did and lost , basic_stringstream
>
> Is there anything wrong with renaming the redefined ostrstream to
> something else in order to avoid collision with std::ostrstream?
>
> --
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub [2], or unsubscribe
> [3].
> Triage notifications on the go with GitHub Mobile for iOS [4] or
> Android [5].
>
> Links:
> ------
> [1]
> https://urldefense.com/v3/__https://stackoverflow.com/questions/10849656/what-should-i-use-instead-of-stdostrstream__;!!P4SdNyxKAPE!XT8AUmN3rafqVZV6VzRrf-C8wReaq3e5lfVuxQ8nt88_dP1b1niOQzoYdI8R1kg$
> [2]
> #126 (comment)
> [3]
> https://github.com/notifications/unsubscribe-auth/ANL4LVEBC2PCATM34H7PXDDT67Z4XANCNFSM5C5ZVHAQ
> [4]
> https://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!P4SdNyxKAPE!XT8AUmN3rafqVZV6VzRrf-C8wReaq3e5lfVuxQ8nt88_dP1b1niOQzoYb1Q07G4$
> [5]
> https://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!P4SdNyxKAPE!XT8AUmN3rafqVZV6VzRrf-C8wReaq3e5lfVuxQ8nt88_dP1b1niOQzoY1k--PAc$
|
plexoos
added a commit
that referenced
this issue
Sep 2, 2021
Fixes #126 Error due to ambiguous ostrstream while running bfc.C in ROOT6
plexoos
added a commit
that referenced
this issue
Sep 2, 2021
Fixes #126 Error due to ambiguous ostrstream while running bfc.C in ROOT6
plexoos
added a commit
that referenced
this issue
Sep 17, 2021
Triggered by #126 (Error due to ambiguous ostrstream while running bfc.C in ROOT6) Since the STAR's `ostrstream` inherits from `std::ostringstream` with only minor modifications to its API, it should be safe to remote this local implementation of `ostrstream` and use `ostringstream` from the standard library.
plexoos
added a commit
that referenced
this issue
Sep 30, 2021
Triggered by #126 (Error due to ambiguous ostrstream while running bfc.C in ROOT6) Since the STAR's `ostrstream` inherits from `std::ostringstream` with only minor modifications to its API, it should be safe to remote this local implementation of `ostrstream` and use `ostringstream` from the standard library.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I try to run one of our tests in ROOT6 environment I get the following error:
Any suggestions how to fix this? @perevbnlgov @klendathu2k
The text was updated successfully, but these errors were encountered: