[jira] [Resolved] (XERCESC-2209) Remove HAVE_LSTRING
[ https://issues.apache.org/jira/browse/XERCESC-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2209. -- Resolution: Fixed > Remove HAVE_LSTRING > --- > > Key: XERCESC-2209 > URL: https://issues.apache.org/jira/browse/XERCESC-2209 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > HAVE_LSTRING is checked for by both autoconf and cmake. However, it's not > used anywhere, so can be safely dropped. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[GitHub] [xerces-c] rleigh-codelibre merged pull request #20: XERCESC-2209: Remove unused LSTRING feature test
rleigh-codelibre merged pull request #20: URL: https://github.com/apache/xerces-c/pull/20 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] branch master updated: XERCESC-2209: Remove unused LSTRING feature test
This is an automated email from the ASF dual-hosted git repository.
rleigh pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/xerces-c.git
The following commit(s) were added to refs/heads/master by this push:
new f6c5dab XERCESC-2209: Remove unused LSTRING feature test
new 15b086b Merge pull request #20 from
rleigh-codelibre/XERCESC-2209_Remove_LSTRING
f6c5dab is described below
commit f6c5dab017f92f746026dc3c6ebc485c9558cb2e
Author: Roger Leigh
AuthorDate: Wed Jun 10 20:26:12 2020 +0100
XERCESC-2209: Remove unused LSTRING feature test
---
CMakeLists.txt| 1 -
cmake/XercesLString.cmake | 31 ---
config.h.cmake.in | 3 ---
configure.ac | 2 --
m4/cxx_have_lstring.m4| 25 -
5 files changed, 62 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index a8e304d..7ecd6e1 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -125,7 +125,6 @@ include(XercesMsgLoaderSelection)
include(XercesTranscoderSelection)
include(XercesFileMgrSelection)
include(XercesXMLCh)
-include(XercesLString)
include(XercesMFC)
include(XercesSSE2)
include(XercesPathMax)
diff --git a/cmake/XercesLString.cmake b/cmake/XercesLString.cmake
deleted file mode 100644
index 81975cb..000
--- a/cmake/XercesLString.cmake
+++ /dev/null
@@ -1,31 +0,0 @@
-# CMake build for xerces-c
-#
-# Written by Roger Leigh
-#
-# Licensed to the Apache Software Foundation (ASF) under one or more
-# contributor license agreements. See the NOTICE file distributed with
-# this work for additional information regarding copyright ownership.
-# The ASF licenses this file to You under the Apache License, Version 2.0
-# (the "License"); you may not use this file except in compliance with
-# the License. You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-# Wide string literals
-
-include(CheckCXXSourceCompiles)
-
-check_cxx_source_compiles("
-int main() {
- const wchar_t* s=L\"wide string\";
- return 0;
-}"
- HAVE_LSTRING)
-
-set(XERCES_LSTRSUPPORT ${HAVE_LSTRING})
diff --git a/config.h.cmake.in b/config.h.cmake.in
index 3f7066d..d8ce9cf 100644
--- a/config.h.cmake.in
+++ b/config.h.cmake.in
@@ -114,9 +114,6 @@
/* Define to 1 if you have the header file. */
#cmakedefine HAVE_LOCALE_H 1
-/* define if the compiler implements L"widestring" */
-#cmakedefine HAVE_LSTRING 1
-
/* Define to 1 if you have the header file. */
#cmakedefine HAVE_MACHINE_ENDIAN_H 1
diff --git a/configure.ac b/configure.ac
index ccf4f66..b8dd7cb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -157,8 +157,6 @@ AC_TYPE_SIZE_T
XERCES_INT_TYPES
-AC_CXX_HAVE_LSTRING
-
ACX_PTHREAD
# Checks for library functions.
diff --git a/m4/cxx_have_lstring.m4 b/m4/cxx_have_lstring.m4
deleted file mode 100644
index 3d35f70..000
--- a/m4/cxx_have_lstring.m4
+++ /dev/null
@@ -1,25 +0,0 @@
-dnl @synopsis AC_CXX_HAVE_LSTRING
-dnl
-dnl If the compiler can prevent names clashes using namespaces, define
-dnl HAVE_LSTRING.
-dnl
-dnl @category Cxx
-dnl @author James Berry
-dnl @version 2005-02-21
-dnl @license AllPermissive
-
-AC_DEFUN([AC_CXX_HAVE_LSTRING],
-[AC_CACHE_CHECK([whether the compiler implements L"widestring"],
-ac_cv_cxx_have_lstring,
-[AC_LANG_SAVE
- AC_LANG_CPLUSPLUS
- AC_COMPILE_IFELSE(
- [AC_LANG_SOURCE(
- [[const wchar_t* s=L"wide string";]])],
- ac_cv_cxx_have_lstring=yes, ac_cv_cxx_have_lstring=no)
- AC_LANG_RESTORE
-])
-if test "$ac_cv_cxx_have_lstring" = yes; then
- AC_DEFINE(HAVE_LSTRING,,[define if the compiler implements L"widestring"])
-fi
-])
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2210) Remove XERCES_NO_MATCHING_DELETE_OPERATOR
[ https://issues.apache.org/jira/browse/XERCESC-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2210. -- Resolution: Fixed > Remove XERCES_NO_MATCHING_DELETE_OPERATOR > - > > Key: XERCESC-2210 > URL: https://issues.apache.org/jira/browse/XERCESC-2210 > Project: Xerces-C++ > Issue Type: Bug > Components: Build, Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > XERCES_NO_MATCHING_DELETE_OPERATOR is checked for by both autoconf and cmake. > It is used in XMemory and DOMDocumentImpl. > Any conforming compiler from this century should be perfectly capable of > providing a proper operator delete, since it's a fundamental requirement for > all the standard containers. This check is thoroughly obsolete. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[GitHub] [xerces-c] rleigh-codelibre merged pull request #19: XERCESC-2110: Remove XERCES_NO_MATCHING_DELETE_OPERATOR
rleigh-codelibre merged pull request #19: URL: https://github.com/apache/xerces-c/pull/19 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] branch master updated: XERCESC-2110: Remove XERCES_NO_MATCHING_DELETE_OPERATOR for old Borland compiler
This is an automated email from the ASF dual-hosted git repository.
rleigh pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/xerces-c.git
The following commit(s) were added to refs/heads/master by this push:
new 5a721ad XERCESC-2110: Remove XERCES_NO_MATCHING_DELETE_OPERATOR for
old Borland compiler
new 8db2383 Merge pull request #19 from
rleigh-codelibre/XERCESC-2210_Remove_XERCES_NO_MATCHING_DELETE_OPERATOR
5a721ad is described below
commit 5a721ad3f513005ec4dda63de84b7143121e746e
Author: Roger Leigh
AuthorDate: Wed Jun 10 20:21:00 2020 +0100
XERCESC-2110: Remove XERCES_NO_MATCHING_DELETE_OPERATOR for old Borland
compiler
---
CMakeLists.txt | 1 -
cmake/XercesOperatorDelete.cmake | 43 --
config.h.cmake.in | 4 --
configure.ac | 21 ---
src/xercesc/dom/impl/DOMDocumentImpl.hpp | 7
src/xercesc/util/XMemory.cpp | 5 ---
src/xercesc/util/XMemory.hpp | 3 --
.../util/Xerces_autoconf_config.hpp.cmake.in | 2 -
src/xercesc/util/Xerces_autoconf_config.hpp.in | 2 -
9 files changed, 88 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index e5df166..a8e304d 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -125,7 +125,6 @@ include(XercesMsgLoaderSelection)
include(XercesTranscoderSelection)
include(XercesFileMgrSelection)
include(XercesXMLCh)
-include(XercesOperatorDelete)
include(XercesLString)
include(XercesMFC)
include(XercesSSE2)
diff --git a/cmake/XercesOperatorDelete.cmake b/cmake/XercesOperatorDelete.cmake
deleted file mode 100644
index ff942ab..000
--- a/cmake/XercesOperatorDelete.cmake
+++ /dev/null
@@ -1,43 +0,0 @@
-# CMake build for xerces-c
-#
-# Written by Roger Leigh
-#
-# Licensed to the Apache Software Foundation (ASF) under one or more
-# contributor license agreements. See the NOTICE file distributed with
-# this work for additional information regarding copyright ownership.
-# The ASF licenses this file to You under the Apache License, Version 2.0
-# (the "License"); you may not use this file except in compliance with
-# the License. You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-# Check whether the compiler chokes on a placement operator delete
-
-include(CheckCXXSourceCompiles)
-
-check_cxx_source_compiles("
-#include
-
-class XMemory {
-public:
- void* operator new(size_t s) { return 0; }
- void* operator new(size_t s, void* ptr) { return 0; }
- void operator delete(void* p) {}
- void operator delete(void* p, void* ptr) {}
-};
-
-int main() {
- return 0;
-}"
- CXX_matching-delete-operator)
-
-set(XERCES_NO_MATCHING_DELETE_OPERATOR 0)
-if(NOT CXX_matching-delete-operator)
- set(XERCES_NO_MATCHING_DELETE_OPERATOR 1)
-endif()
diff --git a/config.h.cmake.in b/config.h.cmake.in
index 64edf47..3f7066d 100644
--- a/config.h.cmake.in
+++ b/config.h.cmake.in
@@ -348,10 +348,6 @@
/* Define if there is support for L"widestring" */
#cmakedefine XERCES_LSTRSUPPORT 1
-/* Define to have XMemory.hpp avoid declaring a matching operator delete for
- the placement operator new */
-#cmakedefine XERCES_NO_MATCHING_DELETE_OPERATOR 1
-
/* Define to use backslash as an extra path delimiter character */
#cmakedefine XERCES_PATH_DELIMITER_BACKSLASH 1
diff --git a/configure.ac b/configure.ac
index 9df6bc9..ccf4f66 100644
--- a/configure.ac
+++ b/configure.ac
@@ -366,27 +366,6 @@ AC_DEFINE_UNQUOTED([XERCES_TEMPLATE_EXTERN],
[$template_extern], [Define as the
XERCES_XMLCH_SELECTION
-AC_MSG_CHECKING([whether the compiler chokes on a placement operator delete])
-AC_COMPILE_IFELSE( [AC_LANG_PROGRAM([[#include
-
-class XMemory
-{
-public :
-void* operator new(size_t s) {
return 0; }
-void* operator new(size_t s, void*
ptr) { return 0; }
-void operator delete(void* p) {}
-void operator delete(void* p,
void* ptr) {}
-};]],
- [[ ]])],
-[
- AC_MSG_RESULT([no])
-],
-[
- AC_MSG_RESULT([yes])
-
[jira] [Commented] (XERCESC-2204) Remove message loader
[ https://issues.apache.org/jira/browse/XERCESC-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17132685#comment-17132685 ] Roger Leigh commented on XERCESC-2204: -- In practice, most distributions providing Xerces-C++ are using "inmemory" since it's the simplest and has no additional external dependencies, and it's platform-independent. In the first instance, we could drop the "icu" and "iconv" message loaders without any loss of functionality, and retain "inmemory". We could do this in two steps: (1) change the CI to inmemory across the board to check it's not breaking anything and then (2) remove the "icu" and "iconv" configuration options and supporting code. If we wanted to, we could later drop the translation machinery entirely, but the above would be noninvasive and simple. > Remove message loader > - > > Key: XERCESC-2204 > URL: https://issues.apache.org/jira/browse/XERCESC-2204 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > We support several different message loaders (inmemory, icu, iconv). > However... we don't have any translations to actually warrant all this > complexity, and likely never will. We have the basic en_US and that's it. > So this code is essentially unused, and I don't see much prospect of it being > used in the future given that there have been zero translations written in > the last two decades. > In order to reduce the size of the test matrix and reduce the maintenance > burden, I'd like to ask if this is something we could safely drop? > See also XALANC-808 which is the same issue for Xalan-C. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2200) Update AppVeyor image in use
[ https://issues.apache.org/jira/browse/XERCESC-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17132681#comment-17132681 ] Roger Leigh commented on XERCESC-2200: -- [~scantor] I also applied a minimal version of this fix to xerces-3.2 to restore AppVeyor CI support there as well as on master, since it was broken after ICU changed their source download URLs. > Update AppVeyor image in use > > > Key: XERCESC-2200 > URL: https://issues.apache.org/jira/browse/XERCESC-2200 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > Original Estimate: 48h > Remaining Estimate: 48h > > AppVeyor images haven't been upgraded for some time. Update to newer image > with VS2019 or VS2017, and switch to vcpkg for ICU and CURL dependencies etc. > which are now provided directly by vcpkg in the AppVeyor images. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[GitHub] [xerces-c] rleigh-codelibre opened a new pull request #20: XERCESC-2209: Remove unused LSTRING feature test
rleigh-codelibre opened a new pull request #20: URL: https://github.com/apache/xerces-c/pull/20 No uses in the codebase. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[GitHub] [xerces-c] rleigh-codelibre opened a new pull request #19: XERCESC-2110: Remove XERCES_NO_MATCHING_DELETE_OPERATOR
rleigh-codelibre opened a new pull request #19: URL: https://github.com/apache/xerces-c/pull/19 Required for an old Borland compiler. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2204) Remove message loader
[ https://issues.apache.org/jira/browse/XERCESC-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17132657#comment-17132657 ] Scott Cantor commented on XERCESC-2204: --- FWIW, I have no exposure to this, so I don't have an opinion either way (apart from "less code == good"). > Remove message loader > - > > Key: XERCESC-2204 > URL: https://issues.apache.org/jira/browse/XERCESC-2204 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > We support several different message loaders (inmemory, icu, iconv). > However... we don't have any translations to actually warrant all this > complexity, and likely never will. We have the basic en_US and that's it. > So this code is essentially unused, and I don't see much prospect of it being > used in the future given that there have been zero translations written in > the last two decades. > In order to reduce the size of the test matrix and reduce the maintenance > burden, I'd like to ask if this is something we could safely drop? > See also XALANC-808 which is the same issue for Xalan-C. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2206) Use char16_t and unicode literals to replace various XMLCh types
[ https://issues.apache.org/jira/browse/XERCESC-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17132655#comment-17132655 ] Scott Cantor commented on XERCESC-2206: --- I don't know that it's going to cause "pain" but I'm trying to say that it will necessitate maintaining two branches to do this, when we obviously are having trouble finding bodies to maintain even one. It's not easy for me to say that the benefit is worth it. In my experience, if you can't drop the old, there's little value in adding technical debt for the new. I think what I would probably argue is that having staged patches that update the code may be "good enough" vs. actually shipping them and having to support both. > Use char16_t and unicode literals to replace various XMLCh types > > > Key: XERCESC-2206 > URL: https://issues.apache.org/jira/browse/XERCESC-2206 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > Currently, XMLCh can be a variety of 16-bit types depending upon the > platform, from wchar_t, uint16_t, unsigned short, to char16_t. > To reduce the platform-specific variability, fix XMLCh to char16_t, and also > permit the use of u"" unicode string literals in the codebase. This will > allow replacement of Unicode constants with direct use of literals. > This will additionally reduce the size of the test matrix with only one > character variant to test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2206) Use char16_t and unicode literals to replace various XMLCh types
[ https://issues.apache.org/jira/browse/XERCESC-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17132650#comment-17132650 ] Roger Leigh commented on XERCESC-2206: -- I certainly don't want to proceed with anything if it will cause you problems. My understanding from earlier conversations was that branching off xerces-3.2 would unblock such changes on the master branch, so that they wouldn't be disruptive for the stable release. Apologies if I've misunderstood. The changes I have made so far on master bring the language requirement up to C++98, and some of these changes would raise it up to C++11. If we need to discuss that further e.g. on the mailing list with a wider audience or in person, I'll be happy to do so. The intent is to make the library easier and more convenient to use, rather than causing unnecessary pain. Some of the tickets I've opened, such as XERCESC-2204 are more for discussion than any immediate action. The overriding intent for these is to minimise the combinatorial explosion of interacting configuration options to maximise test coverage and to minimise the maintenance required so that an end user is not going to get an untested combination. > Use char16_t and unicode literals to replace various XMLCh types > > > Key: XERCESC-2206 > URL: https://issues.apache.org/jira/browse/XERCESC-2206 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > Currently, XMLCh can be a variety of 16-bit types depending upon the > platform, from wchar_t, uint16_t, unsigned short, to char16_t. > To reduce the platform-specific variability, fix XMLCh to char16_t, and also > permit the use of u"" unicode string literals in the codebase. This will > allow replacement of Unicode constants with direct use of literals. > This will additionally reduce the size of the test matrix with only one > character variant to test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2206) Use char16_t and unicode literals to replace various XMLCh types
[ https://issues.apache.org/jira/browse/XERCESC-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130676#comment-17130676 ] Scott Cantor commented on XERCESC-2206: --- Installing both sets of headers is probably optional, I think it's enough to just allow side by side install of the library, which would work for 3.2 and 3.3 (the minor version is embedded into the library name, wisdom of that decision notwithstanding). I would agree that it's not likely to be a major hassle to maintain both, I'm just noting I would have to for a while (independently of whether I'm doing it officially or not). > Use char16_t and unicode literals to replace various XMLCh types > > > Key: XERCESC-2206 > URL: https://issues.apache.org/jira/browse/XERCESC-2206 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > Currently, XMLCh can be a variety of 16-bit types depending upon the > platform, from wchar_t, uint16_t, unsigned short, to char16_t. > To reduce the platform-specific variability, fix XMLCh to char16_t, and also > permit the use of u"" unicode string literals in the codebase. This will > allow replacement of Unicode constants with direct use of literals. > This will additionally reduce the size of the test matrix with only one > character variant to test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2206) Use char16_t and unicode literals to replace various XMLCh types
[ https://issues.apache.org/jira/browse/XERCESC-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130670#comment-17130670 ] Roger Leigh commented on XERCESC-2206: -- None of this is intended to cause any *API* break. But if there's any question of needing it to be parallel installable, we could make this preparatory work for a version 4.0 so that distributors can have xerces-c3 and xerces-c4 co-installable. For the few bugfixes and security updates which need applying, it won't be too much work to apply them to both branches. My intent here is to make Xerces-C++ viable for the longer term by making it transparently usable with contemporary compilers and standard libraries from the last decade, rather than have it stuck in the pre-Standard mid-90s-era which is mutually incompatible with the rest of the C++ world. I am not suggesting using C++20 or C++17, or anything remotely bleeding edge. We would be using a strictly limited subset of features, which currently would be: char16_t, thread and eventually optional use of streams and the standard exception types, and possibly ustring. None of those changes are intended to cause any breakage for existing C++ code using Xerces-C++. The char16_t change should be entirely transparent since it's already in 3.2.x if the compiler supports it, and is tested against most open source Xerces-C++ users. What it will enable is the guaranteed ability to utilise unicode literals and string literals in code calling Xerces which will make applications simpler and more readable. > Use char16_t and unicode literals to replace various XMLCh types > > > Key: XERCESC-2206 > URL: https://issues.apache.org/jira/browse/XERCESC-2206 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > Currently, XMLCh can be a variety of 16-bit types depending upon the > platform, from wchar_t, uint16_t, unsigned short, to char16_t. > To reduce the platform-specific variability, fix XMLCh to char16_t, and also > permit the use of u"" unicode string literals in the codebase. This will > allow replacement of Unicode constants with direct use of literals. > This will additionally reduce the size of the test matrix with only one > character variant to test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2206) Use char16_t and unicode literals to replace various XMLCh types
[ https://issues.apache.org/jira/browse/XERCESC-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130648#comment-17130648 ] Scott Cantor commented on XERCESC-2206: --- I suppose maintaining two branches is an option but it's not an ideal state certainly and doesn't really get the project into a better state unless I just fork. > Use char16_t and unicode literals to replace various XMLCh types > > > Key: XERCESC-2206 > URL: https://issues.apache.org/jira/browse/XERCESC-2206 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > Currently, XMLCh can be a variety of 16-bit types depending upon the > platform, from wchar_t, uint16_t, unsigned short, to char16_t. > To reduce the platform-specific variability, fix XMLCh to char16_t, and also > permit the use of u"" unicode string literals in the codebase. This will > allow replacement of Unicode constants with direct use of literals. > This will additionally reduce the size of the test matrix with only one > character variant to test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2206) Use char16_t and unicode literals to replace various XMLCh types
[ https://issues.apache.org/jira/browse/XERCESC-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130630#comment-17130630 ] Roger Leigh commented on XERCESC-2206: -- I have deliberately set the version to 3.3 so this is solely for the "master" branch and not intended to disrupt the "xerces-3.2" branch; likewise for all the issues created today. > Use char16_t and unicode literals to replace various XMLCh types > > > Key: XERCESC-2206 > URL: https://issues.apache.org/jira/browse/XERCESC-2206 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > Currently, XMLCh can be a variety of 16-bit types depending upon the > platform, from wchar_t, uint16_t, unsigned short, to char16_t. > To reduce the platform-specific variability, fix XMLCh to char16_t, and also > permit the use of u"" unicode string literals in the codebase. This will > allow replacement of Unicode constants with direct use of literals. > This will additionally reduce the size of the test matrix with only one > character variant to test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2206) Use char16_t and unicode literals to replace various XMLCh types
[ https://issues.apache.org/jira/browse/XERCESC-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130605#comment-17130605 ] Scott Cantor commented on XERCESC-2206: --- Same as other issue, I have no such support on too many platforms for that to be possible right now. > Use char16_t and unicode literals to replace various XMLCh types > > > Key: XERCESC-2206 > URL: https://issues.apache.org/jira/browse/XERCESC-2206 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > Currently, XMLCh can be a variety of 16-bit types depending upon the > platform, from wchar_t, uint16_t, unsigned short, to char16_t. > To reduce the platform-specific variability, fix XMLCh to char16_t, and also > permit the use of u"" unicode string literals in the codebase. This will > allow replacement of Unicode constants with direct use of literals. > This will additionally reduce the size of the test matrix with only one > character variant to test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2205) Require std::mutex and std::thread
[ https://issues.apache.org/jira/browse/XERCESC-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130603#comment-17130603 ] Scott Cantor commented on XERCESC-2205: --- I've got far too much exposure to compilers without any of that support. C++-98 is fine, but C++-11 isn't remotely possible for me and probably won't be for several years. > Require std::mutex and std::thread > -- > > Key: XERCESC-2205 > URL: https://issues.apache.org/jira/browse/XERCESC-2205 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > Replace the existing MutexManager with the standard library implementation. > This is essentially going to be pthreads or Windows threads under the hood, > so it's effectively replacing PosixMutexManager and WindowsMutexManager with > a single standard replacement. This is currently StdMutexMgr, but rather > than using the MutexManager abstraction, we would be using the standard types > directly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2210) Remove XERCES_NO_MATCHING_DELETE_OPERATOR
Roger Leigh created XERCESC-2210: Summary: Remove XERCES_NO_MATCHING_DELETE_OPERATOR Key: XERCESC-2210 URL: https://issues.apache.org/jira/browse/XERCESC-2210 Project: Xerces-C++ Issue Type: Bug Components: Build, Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Assignee: Roger Leigh Fix For: 3.3.0 XERCES_NO_MATCHING_DELETE_OPERATOR is checked for by both autoconf and cmake. It is used in XMemory and DOMDocumentImpl. Any conforming compiler from this century should be perfectly capable of providing a proper operator delete, since it's a fundamental requirement for all the standard containers. This check is thoroughly obsolete. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2209) Remove HAVE_LSTRING
Roger Leigh created XERCESC-2209: Summary: Remove HAVE_LSTRING Key: XERCESC-2209 URL: https://issues.apache.org/jira/browse/XERCESC-2209 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.3.0 Reporter: Roger Leigh Assignee: Roger Leigh Fix For: 3.3.0 HAVE_LSTRING is checked for by both autoconf and cmake. However, it's not used anywhere, so can be safely dropped. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2208) Rationalise XercesIntTypes
Roger Leigh created XERCESC-2208: Summary: Rationalise XercesIntTypes Key: XERCESC-2208 URL: https://issues.apache.org/jira/browse/XERCESC-2208 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Fix For: 3.3.0 We currently have multiple fallbacks for int types from cstdint, stdint.h, inttypes.h etc. However, if we require cstdint then we have most of the basic types guaranteed to be provided, and most of the logic to handle the fallbacks can be eliminated entirely. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2207) Rationalise network accessors
Roger Leigh created XERCESC-2207: Summary: Rationalise network accessors Key: XERCESC-2207 URL: https://issues.apache.org/jira/browse/XERCESC-2207 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Fix For: 3.3.0 We currently support four netaccessors: curl, winsock, socket and cfurl. And also "none" if network support is disabled. This makes the test matrix quite large. Additionally, with the recent push to use HTTPS everywhere, I wonder about the dangers of Xerces using its own plain HTTP implementation over sockets without any SSL support. Would dropping socket and winsock, and requiring curl or cfurl make sense? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2206) Use char16_t and unicode literals to replace various XMLCh types
Roger Leigh created XERCESC-2206: Summary: Use char16_t and unicode literals to replace various XMLCh types Key: XERCESC-2206 URL: https://issues.apache.org/jira/browse/XERCESC-2206 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Assignee: Roger Leigh Fix For: 3.3.0 Currently, XMLCh can be a variety of 16-bit types depending upon the platform, from wchar_t, uint16_t, unsigned short, to char16_t. To reduce the platform-specific variability, fix XMLCh to char16_t, and also permit the use of u"" unicode string literals in the codebase. This will allow replacement of Unicode constants with direct use of literals. This will additionally reduce the size of the test matrix with only one character variant to test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2205) Require std::mutex and std::thread
Roger Leigh created XERCESC-2205: Summary: Require std::mutex and std::thread Key: XERCESC-2205 URL: https://issues.apache.org/jira/browse/XERCESC-2205 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Assignee: Roger Leigh Fix For: 3.3.0 Replace the existing MutexManager with the standard library implementation. This is essentially going to be pthreads or Windows threads under the hood, so it's effectively replacing PosixMutexManager and WindowsMutexManager with a single standard replacement. This is currently StdMutexMgr, but rather than using the MutexManager abstraction, we would be using the standard types directly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2204) Remove message loader
Roger Leigh created XERCESC-2204: Summary: Remove message loader Key: XERCESC-2204 URL: https://issues.apache.org/jira/browse/XERCESC-2204 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Assignee: Roger Leigh Fix For: 3.3.0 We support several different message loaders (inmemory, icu, iconv). However... we don't have any translations to actually warrant all this complexity, and likely never will. We have the basic en_US and that's it. So this code is essentially unused, and I don't see much prospect of it being used in the future given that there have been zero translations written in the last two decades. In order to reduce the size of the test matrix and reduce the maintenance burden, I'd like to ask if this is something we could safely drop? See also XALANC-808 which is the same issue for Xalan-C. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] branch xerces-3.2 updated (89fe151 -> 7173fa7)
This is an automated email from the ASF dual-hosted git repository. rleigh pushed a change to branch xerces-3.2 in repository https://gitbox.apache.org/repos/asf/xerces-c.git. from 89fe151 Some site updates for future builds. new b465b3c XERCESC-2200: AppVeyor image now includes ninja new 160b6e5 XERCESC-2200: AppVeyor uses new ICU GitHub download URL for 67.1 release new 7173fa7 Merge pull request #18 from rleigh-codelibre/XERCESC-2200_appveyor_bugfix-3.2 The 6385 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: scripts/ci-appveyor-setup | 19 +++ 1 file changed, 3 insertions(+), 16 deletions(-) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[GitHub] [xerces-c] rleigh-codelibre merged pull request #18: XERCESC-2200: Appveyor bug fix (3.2)
rleigh-codelibre merged pull request #18: URL: https://github.com/apache/xerces-c/pull/18 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[GitHub] [xerces-c] rleigh-codelibre opened a new pull request #18: XERCESC-2200: Appveyor bug fix (3.2)
rleigh-codelibre opened a new pull request #18: URL: https://github.com/apache/xerces-c/pull/18 ICU have changed their download URLs to GitHub releases. Update accordingly. This is a minimal AppVeyor fix; the base image update will need a newer ICU. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] branch master updated (e345919 -> eddc7b6)
This is an automated email from the ASF dual-hosted git repository. rleigh pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/xerces-c.git. from e345919 Merge pull request #15 from rleigh-codelibre/XERCESC-2201_travis_ci_upgrade new 86554bc XERCESC-2200: AppVeyor image now includes ninja new b3c61b8 XERCESC-2200: AppVeyor uses new ICU GitHub download URL for 67.1 release new eddc7b6 Merge pull request #17 from rleigh-codelibre/XERCESC-2200_appveyor_bugfix The 6411 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: scripts/ci-appveyor-setup | 19 +++ 1 file changed, 3 insertions(+), 16 deletions(-) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[GitHub] [xerces-c] rleigh-codelibre merged pull request #17: XERCESC-2200: Appveyor bug fix
rleigh-codelibre merged pull request #17: URL: https://github.com/apache/xerces-c/pull/17 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
