- Some kind of unwanted optimization going on here ??? And if so, how do I prevent it ??? - 11 Updates
- Can't find overloaded overridden method in base class - 3 Updates
- OT: A non-ASCII characters text file - 2 Updates
- Design patterns with T*, where T is never defined - 1 Update
- what do you think about this? - 4 Updates
- About using auto with class member functions - 3 Updates
- Technical paper in 6 languages (including code comments) - 1 Update
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 26 06:02PM -0700 On 3/26/2020 3:58 AM, David Brown wrote: > not required to be in memory - though a compiler is certainly free to > interpret the fence more generally and use it for ordering result1. > Making result1 volatile /will/ force the desired order. [...] Right. The memory fence can be optimized away because it has no other atomic operations to synchronize with. There needs to be a std::atomic<T> around somewhere to sync with. |
James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 27 12:21AM -0400 On 3/26/20 5:42 PM, David Brown wrote: ... > C and C++ have always had the "as if" rule and the concept of observable > behaviour - and time is not observable. Any re-arrangements that don't > affect the observable behaviour are allowed. C has had the "least requirements" clause ever since it was first standardized - but the term "observable behavior" wasn't used in connection with those requirements until C2011. The actual requirements imposed by C were essentially the same as those imposed by C++, but C++ defined a convenient term for discussing those requirements, while C didn't. The C++ standard remains much clearer than the C standard with respect to the role that observable behavior plays in judging the conformance of an implementation. I've lost my copies of the oldest versions of the C++ standard, but as I remember it, it has defined the term "observable behavior" ever since it was first standardized - but early versions of the standard had a different definition of that term than current ones. The oldest draft of the standard that I have is n2723.pdf (2008?). It says "The observable behavior of the abstract machine is its sequence of reads and writes to volatile data and calls to library I/O functions." The "least requirements" clause was not connected to the term "observable behavior" in that version. The next oldest draft version I have is n3035.pdf (2010?). In that version, the connection between the "least requirements" and "observable behavior" is essentially the same as in the current standard. |
"Öö Tiib" <ootiib@hot.ee>: Mar 27 01:03AM -0700 On Thursday, 26 March 2020 23:57:59 UTC+2, David Brown wrote: > > Unless they *deprecate* and *break* the volatile as they seemingly > > plan to. > Did you read the paper linked (P1152r4) ? Yes, like I did read the paper where they deprecated constexpr detection compile time. It is typical programmer does not know what programmer is doing lie following with taking away the essential tool. > which doesn't exist. This removes a significant foot-gun and removes > unintuitive corner cases from the languages. > """ Basically it is saying that C++17 library was implemented volatile-incorrect in implementations and so lets remove volatile as fix. Lets take away the possibility that someone may have something implemented volatile-correctly at all. > Did you look at the votes? The solid majority of the working groups > were in favour. Do you think they /all/ forgot that people use C++ in > embedded programming? Popular votes in this world have left me always indifferent. And those are votes of wormtongues counted. They certainly *know* that now embedded programming in C++ is double tedious if not impossible. > Can you give an example of a use of volatile that you think is good, > solid programming practice in pre-C++20 but is not deprecated? At > worst, you have to write "x = x + 1;" instead of "x++;". Basically I read it that instead of member functions of volatile unions I now have to use inline assembler again since it will be more readable than C++, even if it is somehow possible to write in C++ at all (should invest tens of man-days into research). And with next standard they most likely break even that "somehow". |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 27 09:47AM +0100 On 27.03.2020 05:21, James Kuyper wrote: > remember it, it has defined the term "observable behavior" ever since it > was first standardized - but early versions of the standard had a > different definition of that term than current ones. C++98 §1.9/6: "The observable behavior of the abstract machine is its sequence of reads and writes to volatile data and calls to library I/O functions" C++17 §4.6/7 (via final draft N4659): "The least requirements on a conforming implementation are: — Accesses through volatile glvalues are evaluated strictly according to the rules of the abstract machine. — At program termination, all data written into files shall be identical to one of the possible results that execution of the program according to the abstract semantics would have produced. — The input and output dynamics of interactive devices shall take place in such a fashion that prompting output is actually delivered before a program waits for input. What constitutes an interactive device is implementation-defined. These collectively are referred to as the /observable behavior/ of the program" > The next oldest draft version I have is n3035.pdf (2010?). In that > version, the connection between the "least requirements" and "observable > behavior" is essentially the same as in the current standard. - Alf |
David Brown <david.brown@hesbynett.no>: Mar 27 12:22PM +0100 On 27/03/2020 09:03, Öö Tiib wrote: >> Did you read the paper linked (P1152r4) ? > Yes, like I did read the paper where they deprecated constexpr detection > compile time. That must be a different paper. I could not find a reference to anything relevant in a quick search. > It is typical programmer does not know what programmer is > doing lie following with taking away the essential tool. As I couldn't find a paper on "deprecated constexpr detection", I can't comment on it. But AFAICS the "deprecate volatile" paper stands on its own - and should be judged on its own. It makes no sense to me to say it must be a bad thing to deprecate complex volatile uses just because you didn't like a paper on deprecating constexpr detection. > volatile-incorrect in implementations and so lets remove volatile > as fix. Lets take away the possibility that someone may have something > implemented volatile-correctly at all. No one is removing or deprecating volatile. Simple volatile usage is almost invariably compiled correctly, so that the object code does exactly what the programmer expected. Complex cases are riddled with compiler bugs, programmer confusion and misunderstanding, underspecification in the standards, and alternative implementations that are each arguably correct. The change in C++20 has nothing to do with the C++17 library - it is nothing more nor less than an admission that complex volatile usage is ripe with errors, unnecessary in practice, and thus should be removed from the language. > Popular votes in this world have left me always indifferent. And those > are votes of wormtongues counted. They certainly *know* that now > embedded programming in C++ is double tedious if not impossible. You really think the C++ standards groups are /deliberately/ and /knowingly/ sabotaging the language for its use in low-level programming? That is real tin-foil hat stuff. > than C++, even if it is somehow possible to write in C++ at all (should > invest tens of man-days into research). And with next standard they most > likely break even that "somehow". All you have to do is make sure your volatile accesses are simple and explicit. If you think your current code is deprecated by the new standard, please show a small example. If I am wrong here, I would like to know about it! |
"Öö Tiib" <ootiib@hot.ee>: Mar 27 07:58AM -0700 On Friday, 27 March 2020 13:22:19 UTC+2, David Brown wrote: > own - and should be judged on its own. It makes no sense to me to say > it must be a bad thing to deprecate complex volatile uses just because > you didn't like a paper on deprecating constexpr detection. Paper is that removal of deprecated legacy exception specifications. <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html> Basically that: <https://timsong-cpp.github.io/cppwp/n4140/expr.unary.noexcept> notice "unless the call is a constant expression" Was changed to that: <https://eel.is/c++draft/expr.unary.noexcept> notice link to [except.spec] that does not anymore say that constant expressions can not be "potentially throwing". Typical work of wormtongues. > nothing to do with the C++17 library - it is nothing more nor less than > an admission that complex volatile usage is ripe with errors, > unnecessary in practice, and thus should be removed from the language. Yes, and so we should use assembler to write device drivers. > You really think the C++ standards groups are /deliberately/ and > /knowingly/ sabotaging the language for its use in low-level > programming? That is real tin-foil hat stuff. What else explanation there is? Useless tool is useless tool. Who made it useless weren't morons, so they made it specially. > explicit. > If you think your current code is deprecated by the new standard, please > show a small example. If I am wrong here, I would like to know about it! Basically I can not imagine how to write any device driver in C++ without volatile member functions nor operators. Say VGA compatible text mode driver? Basically we have to use old stinky C macros that reinterpret cast constant uint values to volatile pointer values on every step and then do arithmetic with those in large blob functions. Happen to have whole array of such peripherals? Be explicit and copy paste, no way to have volatile objects. And perhaps that reinterpret_cast is undefined behavior as well. Strong pressure seemed to be to screw up std::atomic as well. Meanwhile not all implementations have <stdatomic.h> of C yet as it is C11. Macro assembler or perhaps C (if they do not trash that as well) remain the viable options. |
David Brown <david.brown@hesbynett.no>: Mar 27 04:56PM +0100 On 27/03/2020 15:58, Öö Tiib wrote: > notice link to [except.spec] that does not anymore say > that constant expressions can not be "potentially throwing". > Typical work of wormtongues. This is getting a little out of my depth here, so I hope someone will chime in if I'm wrong. But how could a constant expression be potentially throwing? I can't see anything here that has changed except that the terms have been made a little more general. >> an admission that complex volatile usage is ripe with errors, >> unnecessary in practice, and thus should be removed from the language. > Yes, and so we should use assembler to write device drivers. Do you think that complex, unreliable, under-specified volatile expressions were needed to write device drivers? I certainly don't. Low-level coding is my main job (mainly in C, but that makes no difference here). I use "volatile" regularly. There is nothing in the changes to volatile in C++20 that I dislike or that would cause any hardship in my coding. > is C11. > Macro assembler or perhaps C (if they do not trash that as well) > remain the viable options. I am seeing a great deal of anger and fear here, and very little rational thought or explanation. That is not like you. I am still waiting for concrete examples - not another claim about how this will make low-level programming impossible, but a simple real example. |
James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 27 09:53AM -0700 On Friday, March 27, 2020 at 10:58:56 AM UTC-4, Öö Tiib wrote: > On Friday, 27 March 2020 13:22:19 UTC+2, David Brown wrote: > > On 27/03/2020 09:03, Öö Tiib wrote: ... > > you didn't like a paper on deprecating constexpr detection. > Paper is that removal of deprecated legacy exception specifications. > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html> What does that have to do with "deprecating constexpr detection [at] compile time"? There are seven occurrences of "constexpr" in that paper - none of them involve making it deprecated. Also, what connection do you see between this paper and "volatile". There's only one occurrence of "volatile" in that paper, and it doesn't seem to have anything to do with what you're complaining about. > <https://eel.is/c++draft/expr.unary.noexcept> > notice link to [except.spec] that does not anymore say > that constant expressions can not be "potentially throwing". As david said, how could something that meets the requirements to be described as a "constant expression" be also "potentially throwing"? > Typical work of wormtongues. Removing redundant specification is the "work of wormtongues"? In that case, maybe we need more of them on the committee. ... > > an admission that complex volatile usage is ripe with errors, > > unnecessary in practice, and thus should be removed from the language. > Yes, and so we should use assembler to write device drivers. Can you give a specific example of code that used to be permitted, which will now be deprecated,as a result of which we'll be forced to use assembler instead? ... > > > Popular votes in this world have left me always indifferent. And those Keep in mind that this isn't a simple popularity contest. These are votes of experts serving on the C++ committee. These are people who either implement C++ or use it (roughly equal numbers of each); either way, they are sufficiently interested in C++ to volunteer to spend their free time (unpaid) to work to make it better. Why would such want to destroy C++? They might destroy it unintentionally, but why would they do it deliberately, as you claim? ... > > programming? That is real tin-foil hat stuff. > What else explanation there is? Useless tool is useless tool. > Who made it useless weren't morons, so they made it specially. One alternative explanation is that you do as bad a job of reading English as you do of writing it (which seems quite plausible), and as a result you've misunderstood something about the paper you're complaining about, that made you incorrectly think a useful tool was actually useless. If you could provide a simple example of code that you think would become deprecated if that paper is approved, that would go a long way toward figuring out what you've misunderstood (if you're wrong), or what we've misunderstood (if you're right). ... > > show a small example. If I am wrong here, I would like to know about it! > Basically I can not imagine how to write any device driver in C++ without > volatile member functions nor operators. Say VGA compatible text mode Please give a specific example of a volatile member function or operator that you think is deprecated by that paper. ... > Basically we have to use old stinky C macros that reinterpret cast > constant uint values to volatile pointer values on every step and > then do arithmetic with those in large blob functions. Please provide an example of currently permitted C++ code that would have to be replaced by such C macros if that paper is approved. Note: if you do provide an example, I expect the immediate response will be "Why in the world do you think such code will be deprecated by that paper?". Therefore, it would save everyone some time if you would accompany each example with a citation of the specific words from that paper which left you with the impression that it would deprecate that example. |
"Öö Tiib" <ootiib@hot.ee>: Mar 27 09:59AM -0700 On Friday, 27 March 2020 17:56:48 UTC+2, David Brown wrote: > chime in if I'm wrong. But how could a constant expression be > potentially throwing? I can't see anything here that has changed except > that the terms have been made a little more general. Standard does not say anymore that it cannot be potentially throwing so it can. Look that: #include <iostream> constexpr int foo(int x) {return x;} int main() { std::cout << (noexcept(foo(42)) ? "constant expressions can not throw\n" : "constant expressions may throw\n"); } Demo <http://coliru.stacked-crooked.com/a/7503ebfcc2474e7b> The program does not even say when compiled in -std=c++14 mode anymore that "constant expressions can not throw" yet it did few versions of gcc ago. So these are some rather strong forces behind requirement that constant expressions *should* be throwing. > difference here). I use "volatile" regularly. There is nothing in the > changes to volatile in C++20 that I dislike or that would cause any > hardship in my coding. But it is understandable if you do not write device drivers in C++. You do not consider how C++ features could be used to make those handier so you perhaps see no difference. > rational thought or explanation. That is not like you. I am still > waiting for concrete examples - not another claim about how this will > make low-level programming impossible, but a simple real example. I can't give code since I am not sole owner of it. There are compilers on what it works like was specified by standards. The ongoing events however remove point of considering open sourcing such code. So why should I be happy? |
"Öö Tiib" <ootiib@hot.ee>: Mar 27 10:16AM -0700 On Friday, 27 March 2020 18:53:47 UTC+2, James Kuyper wrote: > Removing redundant specification is the "work of wormtongues"? In that > case, maybe we need more of them on the committee. I replied to David Brown. It is not about debate here who debates better, call that is a constant expression is noexcept(false) since C++17. Both gcc and clang have made it so and rejected to repair: https://bugs.llvm.org/show_bug.cgi?id=15481 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87603 |
David Brown <david.brown@hesbynett.no>: Mar 27 06:59PM +0100 On 27/03/2020 17:59, Öö Tiib wrote: > of gcc ago. > So these are some rather strong forces behind requirement that constant > expressions *should* be throwing. This is either a mistake in the way it is defined (these things happen - the C++ standards folks are not infallible), or intentional. If it is intentional, there will be a reason behind it - perhaps it is because constexpr functions /can/ throw (when evaluated at run-time), and people prefer that noexcept() returns consistent values even if that is pessimistic. Maybe there are other reasons. But I severely doubt that there is someone sitting in a chair, stroking his cat and saying, "How shall we cause trouble for people? Especially those that dare to use C++ for low-level programming? I know, we'll make changes to noexcept() - that will get them!". (Forgetting, of course, that for a lot of low-level and embedded work exceptions are disabled.) > But it is understandable if you do not write device drivers in C++. > You do not consider how C++ features could be used to make those > handier so you perhaps see no difference. So show me! > on what it works like was specified by standards. The ongoing events > however remove point of considering open sourcing such code. So why > should I be happy? I don't want a section of a commercial program. I want a simple, short example case. |
Frederick Gotham <cauldwell.thomas@gmail.com>: Mar 27 02:58AM -0700 On Thursday, March 26, 2020 at 3:50:28 PM UTC, Öö Tiib wrote: > > I thought that the method defined in the base class would be found and called? Do I need to use "using" here in the derived class? > Yes. Or to make all overloads in base class virtual. > Otherwise hiding takes place. I tried making it virtual in the base class but it still fails to compile. I'm using GCC 7.4.0. Try it there on your own compiler. |
Bo Persson <bo@bo-persson.se>: Mar 27 11:33AM +0100 On 2020-03-27 at 10:58, Frederick Gotham wrote: >> Otherwise hiding takes place. > I tried making it virtual in the base class but it still fails to compile. I'm using GCC 7.4.0. > Try it there on your own compiler. Making "it" virtual is not enough. *All* overloads must be present in the base class, otherwise declarations in an inner scope (derived class) hide names in outer scopes (base class). This is the same mechanism as for names inside functions and namespaces. Inner declarations of a name hide all declarations of the same name from outer scopes. Bo Persson |
Cholo Lennon <chololennon@hotmail.com>: Mar 27 02:53PM -0300 On 26/3/20 12:48, Öö Tiib wrote: > That bear trap into what everyone must fall is there > because C++ is designed to *hate* novices. I totally agree with you -- Cholo Lennon Bs.As. ARG |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 27 04:09PM +0100 Someone (I don't recall who) in a recent thread complained about US keyboards lacking e.g. British pound signs. I have a Norwegian keyboard, which lacks Norwegian quote signs, and many other symbols I use. At first I just copied these symbols from the web, or specified them numerically. Then I started on a keyboard helper thing in C++, for Windows. But in the end I just put the most used symbols in a text file, which I switch to whenever I need a symbol. The text file is not super-convenient, in fact it often conflicts with other use of the clipboard. But it works. A semi-practical solution. Herewith, the current version: ----------------------------------------------------------------------- «» "" ❝❞ 『』 – — ' • … ⋯ ⋮ * † ‡ ← ↑ → ↓ ↔ ↕ ↖ ↗ ↘ ↙ ◁ ▷ ◂ ◀ ▶ ▸ ⍅ ⍆ ➲ © ® ™ ° ′ ″ µ − × ⋅ ÷ Σ π √ ≤ ≥ ≈ ∪ ∩ ± ⌈⌉ 𝜋 ⇐ ⇔ ⇒ ≡ ¬ ☺ ☻ 😃 😒 ⚡ 1ˢᵗ, 2ⁿᵈ, 3ʳᵈ, 4ᵗʰ, 6ᵗᵉ Super xᵃ xᵇ xᶜ xᵈ xᵉ xᶠ xᵍ xʰ xⁱ xʲ xᵏ xˡ xᵐ xⁿ xᵒ xᵖ xʳ xˢ xᵗ xᵘ xᵛ xʷ xˣ xʸ xᶻ Super x⁰ x¹ x² x³ x⁴ x⁵ x⁶ x⁷ x⁸ x⁹ x' x⁺ x⁻ x⁼ x⁽ x⁾ Sub x₀ x₁ x₂ x₃ x₄ x₅ x₆ x₇ x₈ x₉ xᵢ ½ ¼ ¾ Soft hyphen Non-breakable space [ ] Non-breakable hyphen [‑] news: 📰 movie: 🎥 music: 🎵 angry: 😠 propaganda: 🐷 idioti: 懵 question: ❓ exclamation: ❗️ /‾‾ File ‾‾\ ----------------------------------------------------------------------- - Alf (off-topic writer's mode) |
David Brown <david.brown@hesbynett.no>: Mar 27 05:42PM +0100 On 27/03/2020 16:09, Alf P. Steinbach wrote: > Someone (I don't recall who) in a recent thread complained about US > keyboards lacking e.g. British pound signs. I guess you might mean me - but I wasn't complaining about it, I was merely surprised that the standard US keyboard layout doesn't have at least ¤ and §. > I have a Norwegian keyboard, which lacks Norwegian quote signs, and many > other symbols I use. You mean « and » ? They have kind of gone out of fashion in modern Norwegian, but perhaps that's just laziness of the modern generation using keyboards without the symbols. > numerically. Then I started on a keyboard helper thing in C++, for > Windows. But in the end I just put the most used symbols in a text file, > which I switch to whenever I need a symbol. I recommend switching to Linux. For me, these are AltGr + z and AltGr + x. Many of the more useful (to me) symbols you have on the list are available as AltGr combinations, and a fair number of the others are available with the Compose key. A good word processor will handle quotation marks automatically, as will LaTeX (with the right setup and packages). A lot of the symbols in your list are only likely to be useful in documents written with a word processor, LaTeX, HTML, markdown, etc. |
Melzzzzz <Melzzzzz@zzzzz.com>: Mar 23 05:19AM > particular HDC (handle to device context), if I recall correctly. > Depending on how it was created such handle must be destroyed by a > corresponding function, but the type does not encode that. Problem with win32 API is because it uses DWORD integer and recently, DWORD_PTR so you must use reinterpret_cast :( -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
alelvb <alelvb@inwind.it>: Mar 27 02:51PM +0100 Il 23/03/20 16:52, David Brown ha scritto: > hard-to-read unicode symbols, is a syntax like: > v1 = a *wedge* b; > v2 = a *dot* b; Is this a particular use of macro substitution? How can I do that? thank you, alessandro |
Christian Gollwitzer <auriocus@gmx.de>: Mar 27 03:47PM +0100 Am 27.03.20 um 14:51 schrieb alelvb: >> v1 = a *wedge* b; >> v2 = a *dot* b; > Is this a particular use of macro substitution? How can I do that? It's an optical trick. It is just a multiplication by three objects, a times wedge times b. If you define "wedge" as an instance of a suitable object, and overload the multiplication operator on it, you can get this to compile to your wedge product. Christian |
David Brown <david.brown@hesbynett.no>: Mar 27 03:57PM +0100 On 27/03/2020 14:51, alelvb wrote: > Is this a particular use of macro substitution? How can I do that? > thank you, > alessandro Here is a simple example, with a "Vect" of three doubles and an imaginary operation "*wedge*" that takes two Vects and returns a new Vect. The details of the operation don't matter - that's your job! First, a simple class and operation with traditional function-like syntax for using the operation: class Vect { private : double vs_[3]; friend Vect wedge_product(const Vect &a, const Vect &b); }; Vect wedge_product(const Vect &a, const Vect &b); Vect test1(const Vect &a, const Vect &b, const Vect &c) { Vect ab = wedge_product(a, b); Vect abc = wedge_product(ab, c); return abc; } Then we make a class for the "wedge" object. This has no data or operations in itself - it exists just to provide overloads to the * operator, and to hold an intermediary proxy class Wedge::ProductHelper. This class holds a reference to a Vect and exists to provide another overload to the * operator, this time passing its reference and the other operand on to the real wedge_product function: class Wedge { class ProductHelper { public: const Vect& v_; ProductHelper(const Vect& v) : v_(v) {} }; friend Vect operator*(Wedge::ProductHelper w, const Vect& a); friend Wedge::ProductHelper operator*(const Vect& a, Wedge); }; const Wedge wedge; inline Vect operator*(Wedge::ProductHelper w, const Vect& a) { return wedge_product(a, w.v_); } inline Wedge::ProductHelper operator*(const Vect &a, Wedge) { return Wedge::ProductHelper(a); } Now we can use the code like this: Vect test2(const Vect &a, const Vect &b, const Vect &c) { return a *wedge* b *wedge* c; } As far as the language is concerned, this is handled by taking "a" and the "wedge" object and applying operator *, giving a Wedge::ProductHelper that holds "a". This is is then used as a parameter to another operator * along with b, and that overload leads to a call of the real function wedge_product, returning a new vector ("ab" from the first test function). The process is then run again to multiply in "c". Your challenge now is: 1) Get all the boiler-plate in templates. 2) Make sure everything that can be hidden from public use, is hidden. 3) Turn it all into expression templates for run-time efficiency. |
Melzzzzz <Melzzzzz@zzzzz.com>: Mar 22 10:04PM > mixed results). Too bad all the code will be generated by AI bots by > that time... Nope, on current computers, impossible. Unless someone figures out how brain works by then. -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
Melzzzzz <Melzzzzz@zzzzz.com>: Mar 22 03:11AM > Is it a good idea to use auto -return value with all class member > function, or use the return type? No, auto is not good for that. In haskell, one writes funtion signatures for all functions, only for local functions signature is not needed. That's just convention and makes better compiler errors. -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
Melzzzzz <Melzzzzz@zzzzz.com>: Mar 22 04:16AM > For anything more complex than a trivial getter I would do without auto > and use some typedefs or aliases to reduce the clutter instead. This. -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
JiiPee <no@notvalid.com>: Mar 22 08:22PM Ok so most answers say that better to type the type and not use auto. I was also thinking that might be better, so I think I ll go with this as well. |
James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 27 12:33AM -0400 On 3/26/20 3:51 PM, Frederick Gotham wrote: ... > Is there any translation firm which is held in particularly high regard for translating technical papers (e.g. to do with mathematics or computing). This newsgroup has readers all around the world. Do you care which country(s) the translation firm operates in? If so, you should specify your preferences. I recommend getting prepared for some sticker shock when looking for a highly regarded technical translating firm. Such firms tend to charge correspondingly high prices. In your first message you said "I'm hoping to purchase a package deal for all 6 languages which won't leave me too much out of pocket." If your budget is sufficiently small that you're worrying about such things, you probably can't afford a "highly regarded" firm - you should set your target a little lower than that. I have no recommendations of my own - the only translator I know personally could handle your need for a Russian translation, but I've never actually used her services, so I can't vouch for how good she is. |
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment