Menu
▾
▴
adobe-source-devel
|
From: David C. <unc...@un...> - 2005-03-23 02:15:12
|
I'm working on my XCode "Adobe Begin" project. After setting up the header paths so it properly finds boost and so forth, I get these errors: headers/report_exception.hpp:43: error: looser throw specifier for `virtual adobe::implementation::os_exception::~os_exception()' /usr/include/gcc/darwin/3.3/c++/exception:56: error: overriding `virtual std::exception::~exception() throw ()' headers/latch.hpp:32: error: class `adobe::latch_t<ValueType>' does not have any field named `trigger_func_m' headers/latch.hpp:32: error: class `adobe::latch_t<ValueType>' does not have any field named `validity_func_m' adobe/test/visual/sources/client_assembler.cpp:1314: error: parse error before `>' token The throw specifier issue seems to be from the implicit destructor for os_exception. -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Foster T. B. <fbr...@ad...> - 2005-03-23 16:44:48
|
Interesting... I haven't seen this problem before, and am unsure as to why it's showing only in GCC on the Mac... Another nit: This header isn't being used currently. We were working on the semantics of a button and the notion of it controlling a latch fell out. This is where this header came from, but we haven't got the details worked out yet. References to this header file can be removed. Blessings, Foster On Mar 22, 2005, at 06:15p, David Catmull wrote: > I'm working on my XCode "Adobe Begin" project. After setting up the > header paths so it properly finds boost and so forth, I get these > errors: > > headers/report_exception.hpp:43: error: looser throw specifier for > `virtual adobe::implementation::os_exception::~os_exception()' > /usr/include/gcc/darwin/3.3/c++/exception:56: error: overriding > `virtual std::exception::~exception() throw ()' > headers/latch.hpp:32: error: class `adobe::latch_t<ValueType>' does > not have any field named `trigger_func_m' > headers/latch.hpp:32: error: class `adobe::latch_t<ValueType>' does > not have any field named `validity_func_m' > adobe/test/visual/sources/client_assembler.cpp:1314: error: parse > error before `>' token > > The throw specifier issue seems to be from the implicit destructor for > os_exception. > > -- > David Catmull > unc...@un... > http://www.uncommonplace.com/ > > > > ------------------------------------------------------- > This SF.net email is sponsored by: 2005 Windows Mobile Application > Contest > Submit applications for Windows Mobile(tm)-based Pocket PCs or > Smartphones > for the chance to win $25,000 and application distribution. Enter > today at > http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > > -- Foster T. Brereton <}}}>< Romans 3:21-26 A d o b e S o f t w a r e T e c h n o l o g y L a b "What 99 percent of programmers need to know is not how to build components but how to use them." -- Alexander Stepanov |
|
From: Ralph T. <ra...@gm...> - 2005-03-23 18:17:18
|
I noticed that this was only being included on GCC/Mac and I changed it in the sandbox so that it would actually compile. It sounds like we'd be better off just cvs delete ing the file altogether. Thanks, Ralph On Wed, 23 Mar 2005 08:44:24 -0800, Foster T. Brereton <fbr...@ad...> wrote: > Interesting... I haven't seen this problem before, and am unsure as to > why it's showing only in GCC on the Mac... > > Another nit: This header isn't being used currently. We were working on > the semantics of a button and the notion of it controlling a latch fell > out. This is where this header came from, but we haven't got the > details worked out yet. References to this header file can be removed. > > Blessings, > Foster > > On Mar 22, 2005, at 06:15p, David Catmull wrote: > > > I'm working on my XCode "Adobe Begin" project. After setting up the > > header paths so it properly finds boost and so forth, I get these > > errors: > > > > headers/report_exception.hpp:43: error: looser throw specifier for > > `virtual adobe::implementation::os_exception::~os_exception()' > > /usr/include/gcc/darwin/3.3/c++/exception:56: error: overriding > > `virtual std::exception::~exception() throw ()' > > headers/latch.hpp:32: error: class `adobe::latch_t<ValueType>' does > > not have any field named `trigger_func_m' > > headers/latch.hpp:32: error: class `adobe::latch_t<ValueType>' does > > not have any field named `validity_func_m' > > adobe/test/visual/sources/client_assembler.cpp:1314: error: parse > > error before `>' token > > > > The throw specifier issue seems to be from the implicit destructor for > > os_exception. > > > > -- > > David Catmull > > unc...@un... > > http://www.uncommonplace.com/ > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: 2005 Windows Mobile Application > > Contest > > Submit applications for Windows Mobile(tm)-based Pocket PCs or > > Smartphones > > for the chance to win $25,000 and application distribution. Enter > > today at > > http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click > > _______________________________________________ > > Adobe-source-devel mailing list > > Ado...@li... > > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > > > > > -- > Foster T. Brereton <}}}>< Romans 3:21-26 > A d o b e S o f t w a r e T e c h n o l o g y L a b > "What 99 percent of programmers need to know is not how to build > components but how to use them." -- Alexander Stepanov > > ------------------------------------------------------- > This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 > Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows > Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register > by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > |
|
From: David C. <unc...@un...> - 2005-03-25 16:05:59
|
I'm having a hard time figuring out this error. It happens on this line in the bevel_button_proxy_t constructor (around line 1315 of client_assembler.cpp): control_m.add_menu_item( (*iter).get<adobe::dictionary_t>()[key_name].get<std::string>(), (*iter).get<adobe::dictionary_t>()[key_value]); I'm getting "parse error before `>' token" and it seems to be referring to <adobe::dictionary_t>. This is odd because dictionary_t is used several times before this in this file. In assemblage.cpp, line 28, changing this: adobe::for_each(connections_m, boost::bind(connection_t::disconnect, _1)); to this: adobe::for_each(connections_m, boost::bind(&connection_t::disconnect, _1)); fixes another compiler error. I haven't yet figured out the "parse error before `;' token" error at assemblage.hpp line 48. -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Foster T. B. <fbr...@ad...> - 2005-03-25 17:11:42
|
All, On Mar 25, 2005, at 08:05a, David Catmull wrote: > I'm having a hard time figuring out this error. It happens on this > line in the bevel_button_proxy_t constructor (around line 1315 of > client_assembler.cpp): > control_m.add_menu_item( > (*iter).get<adobe::dictionary_t>()[key_name].get<std::string>(), > (*iter).get<adobe::dictionary_t>()[key_value]); > I'm getting "parse error before `>' token" and it seems to be > referring to <adobe::dictionary_t>. This is odd because dictionary_t > is used several times before this in this file. > For these errors, try adding a 'template' keyword in front of the call to get: (*iter).template get<adobe::dictionary> ... [key_name].template get<std::string>(), etc., etc. Addition of the keyword is a permissible C++ "hint" to compilers that get is a templated function. The reason why this can't necessarily be figured out by the compiler eludes me at this point. Let me know if that helps. > In assemblage.cpp, line 28, changing this: > adobe::for_each(connections_m, boost::bind(connection_t::disconnect, > _1)); > to this: > adobe::for_each(connections_m, boost::bind(&connection_t::disconnect, > _1)); > fixes another compiler error. From what I understand connection_t::disconnect and &connection_t::disconnect are equivalent provided that connection_t::disconnect is a member function, not a member variable. The change shouldn't be necessary but if the compiler prefers the latter over the former, so be it. Blessings, Foster -- Foster T. Brereton <}}}>< Romans 3:21-26 A d o b e S o f t w a r e T e c h n o l o g y L a b "What 99 percent of programmers need to know is not how to build components but how to use them." -- Alexander Stepanov |
|
From: <syn...@gm...> - 2005-03-25 17:44:03
|
Foster T. Brereton wrote: >> In assemblage.cpp, line 28, changing this: >> adobe::for_each(connections_m, >> boost::bind(connection_t::disconnect, _1)); >> to this: >> adobe::for_each(connections_m, >> boost::bind(&connection_t::disconnect, _1)); >> fixes another compiler error. It's the same change I've posted in the 'mscv8/visual' mail > > From what I understand connection_t::disconnect and > &connection_t::disconnect are equivalent provided that > connection_t::disconnect is a member function, not a member variable. > The change shouldn't be necessary but if the compiler prefers the latter > over the former, so be it. Isn't the the difference that 'connection_t::disconnect' is just a type and '&connection_t::disconnect' is a pointer to a function with this type? The member function is generated by templates but finally you need a pointer to call it, or I'm wrong? Regards, Peter |
|
From: Foster T. B. <fbr...@ad...> - 2005-03-23 18:23:08
|
I'd like to keep it in there for now. I anticipate it will serve a purpose in the (hopefully near) future, though for now it's just sitting there. I believe the only reference to it is in client_assembler.cpp. I'd make the change myself but I'm still wrestling with this ssh-through-the-firewall issue. Blessings, Foster On Mar 23, 2005, at 10:17a, Ralph Thomas wrote: > I noticed that this was only being included on GCC/Mac and I changed > it in the sandbox so that it would actually compile. It sounds like > we'd be better off just cvs delete ing the file altogether. > > Thanks, > Ralph > > On Wed, 23 Mar 2005 08:44:24 -0800, Foster T. Brereton > <fbr...@ad...> wrote: >> Interesting... I haven't seen this problem before, and am unsure as to >> why it's showing only in GCC on the Mac... >> >> Another nit: This header isn't being used currently. We were working >> on >> the semantics of a button and the notion of it controlling a latch >> fell >> out. This is where this header came from, but we haven't got the >> details worked out yet. References to this header file can be removed. >> >> Blessings, >> Foster >> >> On Mar 22, 2005, at 06:15p, David Catmull wrote: >> >>> I'm working on my XCode "Adobe Begin" project. After setting up the >>> header paths so it properly finds boost and so forth, I get these >>> errors: >>> >>> headers/report_exception.hpp:43: error: looser throw specifier for >>> `virtual adobe::implementation::os_exception::~os_exception()' >>> /usr/include/gcc/darwin/3.3/c++/exception:56: error: overriding >>> `virtual std::exception::~exception() throw ()' >>> headers/latch.hpp:32: error: class `adobe::latch_t<ValueType>' does >>> not have any field named `trigger_func_m' >>> headers/latch.hpp:32: error: class `adobe::latch_t<ValueType>' does >>> not have any field named `validity_func_m' >>> adobe/test/visual/sources/client_assembler.cpp:1314: error: parse >>> error before `>' token >>> >>> The throw specifier issue seems to be from the implicit destructor >>> for >>> os_exception. >>> >>> -- >>> David Catmull >>> unc...@un... >>> http://www.uncommonplace.com/ >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: 2005 Windows Mobile Application >>> Contest >>> Submit applications for Windows Mobile(tm)-based Pocket PCs or >>> Smartphones >>> for the chance to win $25,000 and application distribution. Enter >>> today at >>> http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click >>> _______________________________________________ >>> Adobe-source-devel mailing list >>> Ado...@li... >>> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel >>> >>> >> -- >> Foster T. Brereton <}}}>< Romans 3:21-26 >> A d o b e S o f t w a r e T e c h n o l o g y L a b >> "What 99 percent of programmers need to know is not how to build >> components but how to use them." -- Alexander Stepanov >> >> ------------------------------------------------------- >> This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon >> 2005 >> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest >> Windows >> Embedded(r) & Windows Mobile(tm) platforms, applications & content. >> Register >> by 3/29 & save $300 >> http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click >> _______________________________________________ >> Adobe-source-devel mailing list >> Ado...@li... >> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel >> > > -- Foster T. Brereton <}}}>< Romans 3:21-26 A d o b e S o f t w a r e T e c h n o l o g y L a b "What 99 percent of programmers need to know is not how to build components but how to use them." -- Alexander Stepanov |
|
From: David C. <unc...@un...> - 2005-03-24 03:59:32
|
Here are some more issues.
In ui_core_implementation.hpp, there are a bunch of warnings about
"specializing 'struct adobe::delete_ptr<something>' in a different
namespace". It looks like all those specialization macros ought to be
in a namespace adobe {} block.
Other errors:
client_assembler.cpp:1314: error: parse error before `>' token
headers/mac/ui_core_implementation.hpp:168: error: `struct
adobe::window_t::implementation_t' is private
headers/mac/ui_core_implementation.hpp:674: error: within this context
ui_core_implementation.cpp:68: error: no matching function for call to
`adobe::auto_resource<const __CFString*, adobe::ptr_traits<const
__CFString*> >::auto_resource(adobe::auto_resource<const __CFString*,
adobe::ptr_traits<const __CFString*> >)'
adobe/test/visual/sources/mac/ui_core_implementation.cpp:4952: error:
specialization of ReturnType adobe::view_for_element(DisplayElement&)
[with ReturnType = OpaqueControlRef*, DisplayElement = adobe::window_t]
after instantiation
adobe/test/visual/sources/mac/ui_core_implementation.cpp:5062: error:
specialization of ReturnType adobe::view_for_element(DisplayElement&)
[with ReturnType = OpaqueControlRef*, DisplayElement =
adobe::static_text_t] after instantiation
There are lots of warnings about assigning float values to int
variables, and the like. Apparently gcc isn't as happy about those
implicit conversions as CodeWarrior. For example:
adobe/test/visual/sources/mac/ui_core_implementation.cpp:536: warning:
assignment to `short int' from `float'
Maybe the tracking loop (line 1160) should be a do-while loop, so
finding a useful initial MouseTrackingResult value wouldn't be an
issue:
adobe/test/visual/sources/mac/ui_core_implementation.cpp:1117: warning:
initialization of negative value `-1' to `MouseTrackingResult'
--
David Catmull
unc...@un...
http://www.uncommonplace.com/
|
|
From: Ralph T. <ra...@gm...> - 2005-03-24 07:45:08
|
> headers/mac/ui_core_implementation.hpp:168: error: `struct > adobe::window_t::implementation_t' is private This one is a bit odd -- implementation_t is public for every other widget in ui_core, except window_t where it's private except when BOOST_MSVC is defined. Is there any motivation for keeping it private for any build? I don't think that anything will break on Metrowerks if it's public, right? Ralph |
|
From: Foster T. B. <fbr...@ad...> - 2005-03-24 18:10:56
|
Yeah, for now this should move to be public. Blessings, Foster On Mar 23, 2005, at 11:45p, Ralph Thomas wrote: >> headers/mac/ui_core_implementation.hpp:168: error: `struct >> adobe::window_t::implementation_t' is private > > This one is a bit odd -- implementation_t is public for every other > widget in ui_core, except window_t where it's private except when > BOOST_MSVC is defined. Is there any motivation for keeping it private > for any build? I don't think that anything will break on Metrowerks if > it's public, right? > > Ralph > > > ------------------------------------------------------- > This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon > 2005 > Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows > Embedded(r) & Windows Mobile(tm) platforms, applications & content. > Register > by 3/29 & save $300 > http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > > -- Foster T. Brereton <}}}>< Romans 3:21-26 A d o b e S o f t w a r e T e c h n o l o g y L a b "What 99 percent of programmers need to know is not how to build components but how to use them." -- Alexander Stepanov |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X