This is an experiment in decision making. The amount of money you and other participants in the experiment earn will depend upon decisions that participants make.
This experiment has 3 parts. Your total earnings will be a sum of your earnings in these parts and a participation fee.
Your earnings will be given in points which will be translated into real money at the end of the experiment. The point-to-currency ratio is given by:
100 points = €1.00
Everyone will be paid in private at the end of the experiment and you are under no obligation to tell others how much you earned.
The data from the experiment will be kept confidential and anonymous. The choices you make or the views you express will not be used to reveal your identity to anyone, including the experimenters.
{% include Constants.submit_button_template %}
{% endblock %}


How Colleges Learn
In 1994 Stewart Brand published an eye-opening book, How Buildings Learn, that explores how people shape buildings through time. I wish he’d write a follow-up called How Colleges Learn to capture college as a similarly dynamic medium ripe for reframing.
Until that happens, you can play a game of “find/replace” to get a preview. Swap the word “college” for “building” and large swaths of the book hold up surprisingly well. Here’s a nice articulation of the problem from the intro:
Almost no
buildingscolleges adapt well. They’re designed not to adapt; also budgeted and financed not to, constructed not to, maintained not to, regulated and taxed not to, even remodeled not to. But allbuildingscolleges (except monuments) adapt anyway, however poorly, because the usages in and around them are changing constantly. [pg.2]
Colleges are facing enormous pressures to adapt -- from financial viability, to eroding public trust to equitable access. And Olin College of Engineering, the small project-based engineering college where I’m writing from, is no different. So how might a college reframe its world view to adapt to this new climate? In How Buildings Learn, Brand asks the question differently.
What would a
buildingcollege look like and act like if it was designed for easy servicing by the users themselves? Once people are comfortable doing their own maintenance and repair, reshaping comes naturally because they have the hands-on relationship with their space, and they know how it actually works and will have ideas about how to improve it. [pg. 189]
Olin’s curriculum has been designed for easy servicing by faculty and students alike. And consequently, reshaping the curriculum has come naturally. But what about adapting our antiquated hierarchies and power dynamics? How might students, staff and faculty maintain, repair and reshape college culture? Compared to curricular adaptation, a college’s operational and organizational adaptation is an undiscovered country ripe for exploration. But where in a college would anyone go to do that work?
At Olin, you’d go to the Greenhouse. The Greenhouse is a different kind of college affordance -- neither a department, center or traditional greenhouse -- but a community of staff, students and faculty from all corners of the college committed to maintaining, repairing and reshaping Olin College. We have our own prominently located studio space with lots of glass to work in public. Open the door to the Greenhouse and you’ll find folks committed to reshaping college culture. We meet Wednesday mornings during Faculty Meeting (catching faculty and leadership on the way to and from). We share a table, a set of values and the belief that college has yet to reach its institutional potential.
Through these meetings coupled periodically producing community-wide experiences, we demonstrated to Olin how our community of staff, faculty and students could come together as people, outside our “lanes” and roles. In the process, we laid a foundation of trust necessary to collaborate at the college scale. And for a few brief moments in the margins, Olin let the Greenhouse and the larger community have the run of the place. And that’s when the magic happens.
Faux-mencement
On Tuesday March 10th at 4:06pm a long email titled “Olin COVID-19 Important Updates” came into the inbox of every staff, student and faculty member at Olin College of Engineering. It came from Olin’s founding President, Rick Miller, informing the community that “...students should not plan to return to campus after spring break.”
About an hour later, at 5:27pm that same day, a brief message came across a very different channel<EMAIL_ADDRESS>—Olin’s student-owned mailing list for last-minute, serendipitous opportunities. This one titled “Group Scream on the great lawn 5:40 EOM”. (EOM = End of Message)
By the time a few students and staff had gathered around a table the next morning, nothing was normal. We were in the Greenhouse, a small creative studio just inside the entrance to our only academic building. We grow young ideas, and some plants. Joining me were Susan Mihailidis, Director of Academic Affairs and Sponsored Programs; Robert Wechsler, Olin’s Artist in Residence; and a quartet of students: Matt Brucker ’20, Ana Krishnan ’20, Evan New-Schmidt ’20, and Sam Kaplan ’24. For these few students who had made it out of bed, emotions ran high. The feelings deserved airtime, and the best thing we could do as staff in the Greenhouse was to honor them by listening.
After about an hour, a heaviness set in and Susan, a senior member of the administration with the respect of everyone across the college, was ready to act. “How about a time capsule?” she challenged. As the idea bounced around the energy shifted. That’s when Evan ‘20 chimed in: “How about a fake commencement?” Those five words sucked the air out of the room.
Within minutes, and with giddy purpose, we strode over to the Campus Center to pitch the idea to the Interim Provost and frequent collaborator, Mark Somerville. The Campus Center houses Olin’s only dining hall, which most mornings doubles as Mark’s office. And there he was, on the far side of the room, back to the wall, reliably in his black turtleneck. Ana ‘20 took the lead and pitched the idea as the rest of us looked on. Mark’s reply, “What can I do to help?” gave us the green light to get moving.
Walking back to the Greenhouse, Matt ‘20, who not an hour before was rightly consumed by the shock of a senior spring evaporating, turned with a vigorous grin and a shrug of disbelief, “We’ve got something to do!”
From that moment a spirit of co-creation consumed the campus. Faux-mencement was a community-owned affair. Matt and Ana sent out a pitch-perfect Commencement Announcement that looked a little like a ransom note. Olin hadn’t rented the caps and gowns yet, so someone found an origami mortar board “how-to” and a decision was made for garbage bag gowns. Diplomas that read “☻ congratulætions Olin student💥…” were sent along to the Registrars’ Office so names could be matched with almost-earned degrees. After checking and re-checking for accuracy, the faux-diplomas earned the imprimatur of our Registrar Linda Canavan and Adam Novotny ‘21 rubber stamped ‘em with a freshly laser cut “GO Olin!” stamp.
Late that night at Stay Late and Create (SLAC), Olin’s weekly festival of creativity students folded origami mortar boards and trimmed trashbag gowns.
Meanwhile, the commencement speakers - President, Provost, honored faculty, staff and students - who thought they had three months to write remarks, worked overtime.
As for the Faux-mencement itself, the sincerity was palpable. Emotions were as raw as they were joyful. The Olin Conductorless Orchestra played video game themes as leadership marched down the aisle. Somewhere between the candid remarks of the Senior Greeters, the ceremoniously applied hand sanitizer between handshakes and the ritual moving of hand-made yarn tassels across origami caps, the rite of passage was vivid. It was “the best commencement we’ve ever had,” according to Mark.
Faux-mencement matters because it was a pure expression of “Olin-ness” at the very moment we needed it most. It was also a demonstration of our institutional agility and agency. On the eve of exile we came together to co-create the ritual of closure we could’ve lost. We took commencement back for ourselves, leaving Olin with a story.
Age plus adaptivity is what makes a building college come to be loved. The
buildingcollege learns from its occupants, and they learn from it. [pg.23, italics are original]
Demonstration
In the Greenhouse we stage demonstrations, or “demos.” We don’t demo products, we demo culture. Greenhouse demos are explicitly designed human experiences in space to honor and reinforce a set of values and a way of being in college together as a community of participants. Faux-mencement was a demo.
What would a
buildingcollege look like and act like if it was designed for easy servicing by the users themselves? [pg. 189]
I think Faux-mencement, and the two other stories below, Build Week and Olin Workshop on the Library are candidate moments.
MARK CLIP
We stage our demos in the margins -- the less contested times outside the academic calendar and curriculum. Often the demos are a kind of “pop-up” re-programming of a familiar space with unfamiliarly convivial activity. And while marginal, they’re high-leverage - for the brief time they’re happening they take center stage at Olin.
 Ask an activist, and she’ll describe “a public meeting or march protesting against something.” Greenhouse demos lie somewhere between. They exhibit the practical reality of how our community might occupy a familiar space committed to a set of values that promote repair and reshaping ourselves. To us that meant explicitly designing human experiences that embody generous hospitality, listening, and to leaving roles and titles at the door.
So how do you make an organic, compelling demonstration of culture? This is the Greenhouse process:
- Invite Everyone to the Table
early, often and without agenda - Find Room in the Margins
of the curriculum and the academic calendar - This is Show Business
not “tell business,” we are designing experiences to be felt in the body
Though compressed into 26 hours, Faux-mencement follows these steps. It began with students and staff around a table, drawing in the Interim Provost when we had a plan. It was staged on the lawn over lunch, in the margins of space and schedule. With homemade garb, diplomas, and a live-stream for the parents back home -- Faux-mencement was a show -- it was meaningful entertainment for us all.
How Colleges Learn documents three stories -- Faux-mencement, Build Week, and Olin Workshop on the Library -- to share both the process, but also the virtue and value for all constituents of doing this work at a college today.
Build Week
The opposite of adaptation in
buildingscolleges is graceless turnover. The usual pattern is for a rapid succession of tenants, each scooping out all trace of the former tenants and leaving nothing that successors can use. [pg. 23]
In early December 2019, just a few weeks before winter break, I was driving to Olin listening to National Public Radio. Because Olin is an underwriter, occasionally their promotional messages are read by the radio hosts. Somewhere along I-90 that morning, as I listened to the Olin message being read, I realized it had changed. The new version announced Olin’s 20/20 celebration and it dawned on me how big a deal it was for the college.
January is a quiet moment in Olin’s academic calendar. Students are at home, the college is calm -- there’s room. Since Olin’s founding, the idea of doing an on campus January intersession experiment had been in the air but never happened. With Olin 20/20, we had an opening.
I went to the Greenhouse, made some coffee and made a pitch: let’s honor Olin 20/20 with a “back to our roots” January experiment in student, faculty and staff co-creation! Y’all want to do it?
The students were in and I stepped back. It’d be a heavy lift considering it was December 10th. The idea was to add seven days of “open space” to the calendar beginning January 15th. Fortunately the idea would be a win for the Advancement folks -- it was an audacious and authentic way to kick-off the Olin 20/20 campaign.
A meeting was called in the Greenhouse and Olin’s leadership was excited. If students could demonstrate interest and commitment to executing all student-facing dimensions of the experience, there was a possibility. That week, while finishing up classes for the semester, the Greenhouse students took on the notion, called it “Build Week,” and made it their own. To convince administration, they drafted the Build Week Constitution: A Case for Build Week:
We’re approaching the year of Olin 2020, which calls for additional contemplation and planning for the future of Olin as a community and institution. Reflection during the semester schedule is encouraged and valuable, but the hectic nature of the semester doesn’t allow in-depth time for it. Olin Build Week is a time dedicated solely toward building community, reflection, and goals for the next 20 years of Olin.
THE BUILD WEEK CONSTITUTION
In a month that included the winter break, what began in the Greenhouse quickly became an Olin-wide idea that the students made a reality. Spaces filled up in a snap, and forty students returned to campus for a seven-day performance of institutional co-creation. What we found was that students were actually craving the opportunity to lend a hand. It was a way to manifest their feelings for the place.
MATT ON MAINTENANCE
Maintenance
More is being spent on changing
buildingscolleges than on building new ones. [pg. 5]
Colleges are constantly performing maintenance. They spend a lot on it too. Large teams of folks manage the buildings, staying atop a never-ending backlog of repairs while fielding crises as they inevitably emerge. But what about culture and community maintenance -- true college maintenance? Who takes care of that?
The Greenhouse saw this opportunity and made it our business. We make the rounds to check in with folks. We called it “gardening.” We try to catch concerns or issues before they bubble-over. We’re a college resource to swiftly respond to the needs of culture and community, opportunities and crises alike. Between us we have the access to organize immediate action. In the case of Faux-mencement, between us we can text the Interim Provost; the Registrar; the Facilities Manager; first years on up through seniors -- and expect immediate response.
Time and again, the most powerful things we did were the most hands-on. Every project where we made room for students to renovate learning and departmental spaces has rewarded us with much more than just improving the physical plant:
- Students appreciate the sense of ownership that comes with maintenance.
- In the process, a vitality of place emerges
Here's the illustrator, Doyung Lee '16.5, while still a student at Olin, reflecting on the Library in 2016
Here are some reflections on how our spaces worked communicated by Izzy Harrison and Annie Barrett, Barrett Architecture Studio
The opposite of adaptation in
buildingscolleges is graceless turnover. The usual pattern is for a rapid succession of tenants, each scooping out all trace of the former tenants and leaving nothing that successors can use. [pg. 23]
Olin Workshop on the Library
The Olin College Library sits at the front door of the college. As you walk into the Atrium of Milas Hall, to your left is admissions and just to your right are the glass doors of the Library propped open during the day with student-made hexagonal planters. Passing through the doors, reclaimed wood tables of new and interesting books greet you, themselves lit by the curved bank of double-height windows lining the western wall. A bit further in you realize the floor plate has been cut away, revealing the lower level beneath. It is perhaps the most beautiful space on campus.
Across the Center
But when I came to Olin as Library Director in 2014, the library was a ghost town. Aaron Hoover, Associate Professor of Mechanical Engineering, was the faculty lead appointed to chart a new future for the library. Aaron was on my hiring committee and fortunately we hit it off immediately. Just a few weeks after arriving, with the backing of Olin’s leadership, Aaron and I set off on a campaign to invigorate the Library. We called it OWL, Olin Workshop on the Library. Our pitch to the students was simple: Every one of us is at Olin because we believe in project-based learning. Now it’s for real, reinventing the Library is our project, wanna help?
Team Rooms
That first semester we began by inviting students to the Library for weekly lunchtime discussions. At the outset, we gathered data. The students created an open-ended form and interviewed peers in the Dining Hall. A strong signal came back: “A Room of Requirement” was requested in multiple independent interviews. I was in the dark so I had to ask. According to the Harry Potter Lexicon, the Room of Requirement is “a magical room which can only be discovered by someone who is in need.” If you have a need, the room satisfies. What the students wanted was “open space” of their own.
There was a large room at the back of the lower level of the library with no natural light. This was the “Storage Room,” approximately 700 square feet of space off limits to students. Up to that point, the OWL meetings had been a lot of talk. The prospect of clearing out the Storage Room was action. The OWL students brought a bunch of friends and with a little archival guidance from the Library team and disposal guidance from facilities we had our Room of Requirement within a week or two.
The Room of Requirement
Word of the room spread quickly and then-senior Chris Lee ‘15 came by the Library. Chris ran a student organization called Stay Late and Code (SLAC). They wanted to welcome more forms of creativity so SLAC was becoming Stay Late and Create. To kick off the new identity they wanted a new venue.
It didn’t take long for SLAC to become a fixture of Olin culture—and five years in, it’s as strong as ever. If you’re a Faculty member kicking off a new initiative - head to SLAC. If you’re a student looking to co-work with friends while enjoying a few free snacks and some music - head to SLAC. The only requirement for a successful Room of Requirement was a willingness to give students the benefit of the doubt and say yes and to give the requirements a little time to come out of the woodwork.
In January 2015, not long after that first SLAC, Aaron and I hosted the faculty retreat, “Making Space for Making Culture,” on the future of the library, this time to listen and learn from the Faculty. Four themes came through loud and clear:
- Community — people wanted a cross-roads that facilitated more staff, faculty and student interaction.
- Flexibility — we needed to employ Olin’s commitment to prototyping and iteration in our pursuit of the Library. We needed maximum flexibility to try things.
- Action — There was an energy in the room that day, a chance to try something new at the College. We needed to act fast to keep that energy alive.
- Coffee — the word coffee came up with enormous frequency.
The first floor of the Library was spacious but inflexible. Strung together in long rows in the center of the space, the bookshelves consumed the main floor. Inspired by the retreat, we wanted to let the community “borrow” the room to host an event, and then reset the space, returning it to a functional library. How might the main floor be its own room of requirement for the faculty and larger college community? By putting everything on wheels.
In one afternoon, fueled by the best bagels and cream cheese money could buy, the students mounted swivel casters to the bottom of the bookshelves. It was a safe and scrappy retrofit. If you wanted to put a date on when a new culture of the Olin Library was born, that Friday, February 19th 2015, would be it. The community came together turning The Library into a verb.
In the process, we hit on the summer’s formula:
- Pitch students on making a dramatic change to a public space
- Make it a party, encourage folks to play music, hang out and have fun
- Spend hundreds feeding them memorable food
- Save thousands by retrofitting existing resources with our own hands
- Buy a nice camera (that students can borrow) to document everything
- Review with Facilities beforehand to ensure safety and feasibility
That summer, emboldened by what we saw students could do in one day, we created OWL Summer Design/Build. For eight weeks we set seven students free to create the library the community wanted. We played music, took a field trip, swam in Wellesley’s lake, brewed coffee and called it learning.
This is Project Based Organizational Change
When we claim maintaining and adapting the college as project-based learning we foreground the unique “do-learn” opportunities embedded in the practice. Olin’s engineering coursework revolves around teams making things. Organizational change, college change, focuses on teams making things happen. This work requires collaboration across all constituents, engaging the broadest spectrum of folks.
Introducing anything new amidst today’s health & safety concerns, insurance policies, fire codes, shrinking budgets and competing agendas is hard work. It also makes for rich learning.
If a team of students wants to work with staff and leadership to make something happen in college, they need to understand how college works. They’re motivated to look behind the curtain. And there they see the college for what it is: a universe unto itself complete with its own issues and idiosyncrasies, people and politics. This is “do-learn” organizational change. To make any headway takes careful thinking and planning.
- How do we frame x?
- How do we do x with the resources at hand?
- Who should we talk to first?
- How do we satisfy students and administrators simultaneously?
- How might we measure success?
It’s hard to teach this kind of thinking, this kind of hustle, inside the curriculum. Walk out of the classroom and into the halls of power and there’s a whole other universe of learning waiting. Making change at Olin is good practice for making change in the world.
Beginning
So where do you start? Perhaps you begin with a commitment to conversation across the community. Maybe it’d look like ACRONYM.
- Free Coffee & Tea
- Wednesday’s 12:30-2pm
- Milas Hall Atrium
- Fresh-brewed
- Served by Students
ACRONYM is a pop-up cafe with all the details. A chalkboard, a playlist, mugs courtesy of the “play with clay” co-curricular. The coffee’s delicious and it takes forever - turns out pour-over coffee delivered by novice baristas is a slow, inefficient proposition.
And while at first the long lines seemed a bug, they quickly proved a feature. What folks don’t pay in money, they pay in time. Time spent in line chatting, listening, spacing out -- building community. Each Wednesday ACRONYM pops up, makes a convivial cafe, and is gone in three hours. But for those three hours once a week, our college is a different place.


from __future__ import absolute_import
try:
from sklearn.model_selection import cross_val_predict as _orig_cross_val_predict
except ImportError:
from sklearn.cross_validation import cross_val_predict as _orig_cross_val_predict
import pandas as pd
from .._xy_estimator import make_estimator, make_xy
from .._utils import verify_x_type, verify_y_type
from .__init__ import _sklearn_ver
[docs]def cross_val_predict(
estimator,
X,
y=None,
groups=None,
cv=None,
n_jobs=1,
verbose=0,
fit_params=None,
pre_dispatch='2*n_jobs',
method='predict'):
"""
Generate cross-validated estimates for each input data point.
Arguments:
estimator: estimator object implementing 'fit' and 'predict'
The object to use to fit the data.
X: :class:`pandas.DataFrame`
The data to fit.
y: The target variable to try to predict in the case of
supervised learning.
groups : array-like, with shape (n_samples,), optional
Group labels for the samples used while splitting the dataset into
train/test set.
cv : int, cross-validation generator or an iterable, optional
Determines the cross-validation splitting strategy.
Possible inputs for cv are:
- ``None``, to use the default 3-fold cross validation,
- integer, to specify the number of folds in a `(Stratified)KFold`,
- An object to be used as a cross-validation generator.
- An iterable yielding train, test splits.
For integer/``None`` inputs, if the estimator is a classifier and ``y`` is
either binary or multiclass, :class:`StratifiedKFold` is used. In all
other cases, :class:`KFold` is used.
Refer :ref:`User Guide <cross_validation>` for the various
cross-validation strategies that can be used here.
n_jobs : integer, optional
The number of CPUs to use to do the computation. -1 means
'all CPUs'.
verbose : integer, optional
The verbosity level.
fit_params : dict, optional
Parameters to pass to the fit method of the estimator.
pre_dispatch : int, or string, optional
Controls the number of jobs that get dispatched during parallel
execution. Reducing this number can be useful to avoid an
explosion of memory consumption when more jobs get dispatched
than CPUs can process. This parameter can be:
- ``None``, in which case all the jobs are immediately
created and spawned. Use this for lightweight and
fast-running jobs, to avoid delays due to on-demand
spawning of the jobs
- An int, giving the exact number of total jobs that are
spawned
- A string, giving an expression as a function of n_jobs,
as in '2*n_jobs'
method : string, optional, default: 'predict'
Invokes the passed method name of the passed estimator.
Returns:
:class:`pandas.DataFrame` or :class:`pandas.Series` (depending on ``y``).
Example:
>>> import pandas as pd
>>> from ibex.sklearn.linear_model import LinearRegression
>>> try:
... from ibex.sklearn.model_selection import cross_val_predict
... except: # Older sklearn versions
... from ibex.sklearn.cross_validation import cross_val_predict
>>> df = pd.DataFrame({
... 'x': range(100),
... 'y': range(100),
... },
... index=['i%d' % i for i in range(100)])
>>> cross_val_predict(
... LinearRegression(),
... df[['x']],
... df['y'])
i0 ...
i1 ...
i2 ...
i3 ...
i4 ...
i5 ...
...
"""
verify_x_type(X)
verify_y_type(y)
est = make_estimator(estimator, X.index)
X_, y_ = make_xy(X, y)
if _sklearn_ver > 17:
y_hat = _orig_cross_val_predict(
est,
X_,
y_,
groups,
cv,
n_jobs,
verbose,
fit_params,
pre_dispatch,
method)
else:
if groups is not None:
raise ValueError('groups not supported for cross_val_predict in this version of sklearn')
if method != 'predict':
raise ValueError('method not supported for cross_val_predict in this version of sklearn')
y_hat = _orig_cross_val_predict(
est,
X_,
y_,
cv,
n_jobs,
verbose,
fit_params,
pre_dispatch)
if len(y_hat.shape) == 1:
return pd.Series(y_hat, index=y.index)
else:
return pd.DataFrame(y_hat, index=y.index)


Hello there! Remember LaserBox 2.0 a couple blog posts ago? Well, we finally started building the full scale version, aka. The Laser Maze 3000! We took the sketch models that we made last sprint and scaled it up to fit the average adult human. As Mary mentioned, we got several sheets of cardboard last Sprint from Sara Hendren that we are using to assemble our box. In order to make our box easy to break down and store, we decided to make it modular. We bought several 10' PVC pipes and cut it down to the following sizes: six that are 7', eight that are 4', and four that are 5'. Along with the pipes, we bought fittings to hold our PVC pipes together and take apart to store away so that it doesn’t take up a lot of space.
We attached the cardboard to the PVC with velcro to make the structure very strong. In addition we added a cloth covering to the top of the structure to keep it as dark as possible so that the player can see the lasers when going through the maze.
You are probably wondering why we have two sheets of cardboard attached to the PVC pipes. There are two reasons. First, the extra cardboard increases the structural stability of the maze. In addition, we needed a place to house all of the electronics that we use to power and control the lasers. We took the four lasers from our previous sketch model and evenly spaced them across the side of maze. The inner two lasers are attached to servos and will be moving up and down in a vertical line. The outer two lasers are stationary and will be bounced across two mirrors each to create a total of 10 beams throughout the maze.
In order to enhance the laser beams from each of the lasers, we used a fog machine. You can see the laser being bounced off one of the mirrors creating another beam.


DT CARDS
Get a digital transportation card online for any city. Travelling by public transportation has never been so convenient.
Get a digital transportation card online for any city. Travelling by public transportation has never been so convenient.


Doc. no. J16/03-0058=WG21/N1475
Date: 25 April 2003
Project: Programming Language C++
Reply to: Beman Dawes<EMAIL_ADDRESS>1. C99 Library Additions to C++
2. Type Traits
3. Regular Expressions
4. General Purpose Smart Pointers
5. Random Numbers
6. Rational Numbers
7. Threads
8. Hash tables
9. Iterator adaptors
10. Operators header
11. Function object wrappers for deferred calls or callbacks
12. Enhanced Binder
13. Tokenizer
14. Tuples
15. Add file I/O functions taking filename arguments as
std::strings
16. Date Time
17. Mathematical Special Functions
18. Enhanced Member Pointer Adaptor
19. Reference Wrapper
20. Uniform method for computing function object return types
21. Fixed Size Array Wrapper
22. New Iterator Requirements
The Library Technical Report (TR) Proposals and Issues List serves as memory of actions past and actions needed. It is modeled on the highly successful Library and Core issues lists.
The Library Working Group (LWG) is responsible for evaluating most proposals. Proposals identified by the LWG or Evolution Working Group (EWG) chairs as raising language related issues will be evaluated first by the EWG. Working group schedules will be set so that LWG members can participate in EWG discussions of these proposals.
TR Proposals and Issues List entries often contain references to detailed proposals rather than the proposals themselves. Detailed proposals are usually lengthy. They may contain actual library specifications, plus introductions, rationale, history, acknowledgments, reference implementations, example programs, tutorials, and more.
Early in the lifetime of a proposal, it is acceptable that references may be to world-wide web pages under control of the submitter rather than the LWG. As a proposal progresses, it will take the form of a regular numbered committee document.
Final acceptance of a proposal requires specific TR wording in full standardese.
Library developers would be discouraged from submitting proposals if the initial proposal had to be written in standardese, since the submitter would not yet know if the proposal stood even a chance of acceptance. To avoid this problem, the LWG does not require preliminary proposals be written in standardese. Actual acceptance, however, always requires full TR wording in standardese.
New - The proposal or issue has not yet been reviewed by the LWG. The proposal should not be construed as the view of LWG.
Open - The LWG has discussed the proposal but is not yet ready to move the proposal forward. There are several possible reasons for open status: for example, the LWG may wish to study the proposal further, is awaiting additional material from the submitter, has requested modifications to the proposal, or is awaiting final TR wording. Italicized notes by the list maintainer serve to remind the LWG of the details of the current status.
Dup - The LWG has reached consensus that the proposal is a duplicate of another proposal, and will not be further dealt with. A Rationale identifies the duplicated proposal number.
Hold - Work on a formal proposal is not underway at this time. The LGW will devote no more time to the proposal until the proposal is re-opened.
Rejected - The LWG has reached consensus that the proposal should not be accepted for the TR. A Rationale discusses the LWG's reasoning.
Review - Exact wording for the TR is now available for review.
Ready - The LWG has reached consensus that the proposal is ready to forward to the full committee for inclusion in the TR.
TR - The full committee has accepted the proposal for inclusion in the Library Technical Report.
Pure - The proposal is not expected to break source or binary compatibility for existing uses or implementations of the standard library.
Impure - The proposal is expected to break source or binary compatibility for existing uses or implementations of the standard library.
If there is some doubt, a proposal should be classified as impure.
Std C++ - Both the interface and a reasonable implementation require only standard C++ as defined in ISO/IEC 14882:1998.
Extension - Either the interface or reasonable implementations require a core language change or extension.
Compiler - The interface is standard C++, but no reasonable implementation is possible without compiler support. For example, a function template which determines if a structure is a POD requires compiler support but not a core language change.
Native - The interface is standard C++, but implementations will normally use platform dependent native libraries. Thus such a proposal may not be implementable on all hosted C++ platforms.
For proposals representing substantial existing practice, list suppliers (in abbreviated form). For widely available extensions like hash tables, specify "Many".
None - Indicates there is no widely available existing practice.
Yes - There is a working reference implementation available. [What does "available" mean? Does it include "available for a million dollar fee", "if you sign an obnoxious NDA", or "if you aren't a competitor"? I'd say "no" to all of those. On the other hand, I certainly would expect the reference implementation to be copyrighted and not necessarily freely available for all uses. Perhaps "available for inspection by LWG members?"]
No - Doesn't meet the above criteria.
One or more references to the documentation and reference implementation, preferable in the form of URLs. URLs should be spelled out in full so that they are readable on printed copies of this Proposals List.
One or more references to the actual numbered committee document which contains the formal proposal in full standardese, preferable in the form of URLs. URLs should be spelled out in full so that they are readable on printed copies of this Proposals List.
Left blank if a formal proposal has not yet been received.
Most formal proposals go through several revisions. The document number for each revision should be listed, with the most recent first.
Section: 18.7 Status: Open Submitter:
P.J. Plauger Date: 3 Feb 2002
Type: Pure Requires: Std C++
Existing-practice: Many Implementation: Yes
Reference:
www.dinkumware.com/refxc.html,
ISO/IEC 9899:1999 Programming Language C
Formal Proposal: Revised:
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1372.txt,
Original:
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1354.txt,
The revised C standard ISO 9899:1999 (a.k.a. C99) makes extensive additions to the Standard C library. The most obvious ones live in six new headers, but the 18 existing headers (15 from C89 and 3 from Amendment 1) also have a host of additions. Document 02-0012/N1354 summarizes what has been added since the C++ Standard froze (ISO 14882:1998), along with some suggestions for appropriate C++ machinery to accompany the new stuff. For a more complete description, see the Dinkum C99 Library Reference at www.dinkumware.com/refxc.html, which closely reflects the material summarized in the proposal. Note that Dinkumware has been shipping a combined C99/C++ library for the past year, so all of the proposed C++ additions have been implemented.
The proposal falls into the Standards Coordination and Infrastructure categories identified in 01-0028/N1314 as targets for the TR.
[Redmond: After an initial Boost proposal query covering a portion of the C99 additions, PJP said that he wished to make a comprehensive proposal based on his experience implementing the C99 additions for Dinkumware.]
[Pre-Curaçao: PJP submitted his comprehensive proposal, and Dawes withdrew the Boost proposal.]
[Curaçao: The EWG and LWG jointly discussed the proposal. The decision was to proceed on separate but parallel LWG and EWG tracks, and thus request that PJP break the document into separate Library TR C99 and Evolution C99 proposals.
The TR proposal should cover components which can be implemented today using only standard C++, without any compiler support or language extensions. Although the LWG will look at each component in detail, there is general support for adding C99 library additions to the TR. While it may be a bit premature to supply standardese for the entire proposal, it might be useful to begin work, such as deciding which portions can be specified by reference to C99, and which will require full standardese.
The Evolution proposal should cover components which require compiler or language support (such as long long), and need not contain more detail than the current document; the need is for a checklist with recommendations rather than a detailed proposal.
Although those present indicated much interest in the library additions described, there was concern about how some (particularly math functions) would work within the spirit of C++. PJP will be asked to present a technical session in Santa Cruz to increase the committee's knowledge of C99 compatibility issues in general, but with primary focus on math related headers.]
[pre-Santa Cruz: Per the request of the EWG and LWG, the proposal was revised and included in the post-Curaçao mailing.]
[Santa Cruz: The key aspects of the revised proposal were presented at an evening technical session. PJP and Matt Austern will work toward a formal proposal for the Oxford meeting.]
Section: 18 Status: TR Submitter:
John Maddock Date: 4 Oct 2001
Type: Pure Requires: Compiler
Existing-practice: Boost Implementation: Yes
Reference:
www.boost.org/libs/type_traits/index.htm
Formal Proposal:
Revised: N1424/03-0006
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1424.htm
Original:
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1345.html
[N1424 was accepted at the Santa Cruz meeting.]
Section: 21 Status: TR Submitter:
John Maddock Date: 4 Oct 2001
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference: www.boost.org/libs/regex/index.htm
Formal Proposal: Revised: N1429/03-0011
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1429.htm
Original:
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1386.htm
[N1429 was accepted at the Santa Cruz meeting.]
Section: 20 Status: TR Submitter:
Peter Dimov, Greg Colvin, Beman Dawes Date: 4 Oct 2001
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference:
www.boost.org/libs/smart_ptr/shared_ptr.htm
Formal Proposal: Revised: N1450/03-0032
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1450.html
Original: N1431/03-0013
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1431.html
[N1450 was accepted at the Santa Cruz meeting.]
Section: 26 Status: TR Submitter:
Jens Maurer Date: 4 Oct 2001
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference: www.boost.org/libs/random/index.html
Formal Proposal: Revised: N1452/03-0034
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1452.html
Original: N1398/02-0056
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1398.html
[N1452 was accepted at the Santa Cruz meeting.]
Section: 26 Status: Hold Submitter:
Paul Moore Date: 4 Oct 2001
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference: www.boost.org/libs/rational/index.html
Formal Proposal:
This proposal includes class template rational, and related support such as exception class bad_rational, and function template rational_cast.
The current specification assumes the availability of the boost/operators.hpp header (see Proposal ?). If that header doesn't become part of the TR, additional operations will have to be specified for the class rational interface.
Rational numbers are important both in theory and practice. Questions and bug reports indicate that the class sees actual use. It falls into one of the domains (numerics) identified in 01-0028/N1314 as a target for the TR.
[Redmond: Some LWG members thought rational numbers were close to the boundary between what should and shouldn't be part of the standard library. They would like to see a few more clear cut cases.]
[Pre-Curaçao: Paul comments on rationale for inclusion; from a mathematical point of view, having complex numbers, but not rationals, seems odd. From a practical computing position, I have never needed complex numbers, but have occasionally wanted rationals.
Paul also comments that without an unlimited-precision integer type on which to base the rational class, the usefulness of rational<> is drastically diminished. Both double and rational<int> have subtle rounding, precision, and other issues. With double, these properties are fairly well-known, especially by the sort of people who are likely to hit them. With rational<int>, they are *not* well known. On the contrary, the sort of people who might use rational<int> are very likely to completely miss the fact that there are such problems.
It's arguable that these sort of issues make rational<> inappropriate for the standard library. And it's *definitely* arguable that unlimited-precision integers are more appropriate, and should be considered first. On the other hand, there is no significant real-world experience to indicate how likely the issues with using limited-precision integers would be to cause problems in practice. This makes assessing the risks difficult.]
[Curaçao: Beman presented Paul's Pre-Curaçao comments (above). The LWG did not indicate great concern about the unlimited-precision integer question.
There is still considerable concern as to the usefulness of rational numbers in the context of the standard library. A straw vote was taken: "Is the LWG interested enough to make it worthwhile for a formal proposal to be submitted?" 7-yes, 2-no, 6-abstain.
Given the level of concern, the next step might be a paper "explaining the explicit motivation for the usefulness of rational numbers in the context of the standard library."]
[Pre-Santa Cruz: Given that a credible unlimited-precision integer type is now progressing through Boost, Paul asks that his proposal be tabled until unlimited-precision integers are ready for standardization. See Pre-Curaçao comments above.]
Section: ? Status: Open Submitter:
William Kempf Date: 4 Oct 2001
Type: Pure Requires: Native
Existing-practice: Boost Implementation: Yes
Reference: www.boost.org/libs/thread/doc/index.html
Formal Proposal:
This proposal provides basic multithreading functionality, in a form designed specifically for the C++ Standard Library.
The very public development process, with over one hundred people contributing comments and insights, ensured that a wide-range of concerns were exposed, and resulted in a much stronger library. The documentation includes a great deal of rationale for important design decisions.
The proposal is suitable for a wide range of hosted C++ environments, but is intended to be an optional component of the C++ Standard Library since implementors may not wish to support platforms where concurrent programming support is limited, non-existent, or unimportant. The proposal has been implemented on UNIX using POSIX threads, and Windows using both the native Win32 threads and POSIX threads.
The proposal falls in the filling gaps and systems programming domain categories identified in 01-0028/N1314 as targets for the TR.
[Redmond: Bill presented the Boost Thread Library to the LWG. There was considerable interest and encouragement.]
[Pre-Curaçao: Since Redmond, Bill Kempf has done considerable work on the documentation, Mac Murrett has contributed a port to the Mac, and Dave Moore has pending read/write lock, thread pool, and barrier contributions, all of which were known needs. Significant ongoing work includes addressing known issues with boost::thread, and adding cancellation and thread-attribute support.
There's been an increase in public awareness, including an article on Boost.Threads in CUJ, and non-Boost users and MT experts are offering both criticism and praise; evaluating that feedback continues. One of the byproducts of the feedback will be a list of features which might better be supported by language extensions.]
[Curaçao: Dinkumware reports they are about to ship a multi-threading library, with the C++ portions based on the Boost Threads library. Pete Becker said that they view the need as for a "toolkit" approach, and Boost threads met that need.
The EWG and LWG jointly discussed the proposal. The decision was to proceed on separate but parallel LWG, CWG, and EWG tracks, and thus formal proposals and requests should be submitted as separate documents.
The proposal to the LWG for the TR should cover components which can be implemented today using only standard C++ with native threads libraries, without any compiler support or language extensions, but assuming that the CWG supplies appropriate standardese to describe uniform C++ execution in threaded environments.
The request to the Core Working Group should identify areas of concern to ensure uniform C++ execution in threaded environments. Although full standardese isn't discouraged, the point of asking the CWG for help is to tap their expertise in writing standardese affecting the core portion of the language.
The request to the Evolution Working Group should identify areas where a future C++ standard might better support multi-threading by adding language extensions. Although full standardese isn't discouraged, the point of asking the EWG for help is to tap their expertise in adding language enhancements.]
[Pre-Santa Cruz: A formal proposal is planned in time for the Oxford meeting.]
[Post-Oxford: A formal proposal has been delayed by work on refinements dealing with usage issues such as thread priorities. Two additional developers are now helping with the project.]
Section: 23 Status: TR Submitter:
Matt Austern Date: 17 Oct 2001
Type: Pure Requires: Std C++
Existing-practice: Many Implementation: Yes
Reference:
Formal Proposal: Revision 4: N1456/03-0038
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1456.html
Revision 3:
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1443.html,
Revision 2:
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1399.html,
Original:
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1326.html
[N1456 was accepted at the Oxford meeting.]
Section: 24 Status: Open Submitter:
Dave Abrahams, Jeremy Siek Date: 8 Apr 2002
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference:
www.boost.org/libs/utility/iterator_adaptors.htm
Formal Proposal: N1476/03-0059
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1475.html
The Iterator Adaptor library allows you transform an arbitrary ``base'' type into a standard-conforming iterator with the behaviors you choose. Doing so is especially easy if the ``base'' type is itself an iterator. The library also supplies several example adaptors which apply specific useful behaviors to arbitrary base iterators.
``Policy Adaptors and the Boost Iterator Adaptor Library'' (www.boost.org/libs/utility/iterator_adaptors.pdf) is a technical paper describing this library and the powerful design pattern on which it is based. It was presented at the C++ Template Workshop at OOPSLA 2001.
The proposal falls in the filling gaps category identified in 01-0028/N1314 as a target for the TR.
[Pre-Curaçao: The submitters plan to refactor header files to meet the needs of the committee.]
[Curaçao: Dave, with help from Jeremy, briefly presented Iterator Adaptors. If there is a LWG concern, it is that Iterator Adaptors are hard to get a handle on initially.
It was noted that Iterator Adaptors would benefit from named template parameters, although such a language feature is not a part of the proposal. There was concern that library based solutions for named template parameters be consistent across the entire standard library.
Straw vote: "Is the LWG interested enough to make it worthwhile for a formal proposal to be submitted?" 12-yes, 0-no.]
[Pre-Santa Cruz: Dave and Jeremy plan to review and revise Iterator Adaptors.]
[Post-Oxford: A formal proposal (N1476) is promised for the Post-Oxford mailing.]
Section: 20 Status: Hold Submitter:
Dave Abrahams, Jeremy Siek Date: 8 Apr 2002
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference:
www.boost.org/libs/utility/operators.htm
Formal Proposal:
This proposal supplies several sets of class templates which define operators at namespace scope in terms of a minimal number of fundamental operators provided by a template parameter class.
Overloaded operators for class types typically occur in groups. If you can
write x + y
, you probably also want to be able to write x +=
y
. If you can write x < y,
you also want x > y, x >=
y,
and x <= y
. Moreover, unless your class has really
surprising behavior, some of these related operators can be defined in terms of
others (e.g. x >= y <=> !(x < y)
). Replicating this boilerplate for
multiple classes is both tedious and error-prone. The operators header
templates help by generating operators for you at namespace scope based on other
operators you've defined in your class.
The proposal falls in the filling gaps category identified in 01-0028/N1314 as a target for the TR.
[Curaçao: Dave, with help from Jeremy, briefly presented the operators header.
Straw vote: "Is the LWG interested enough to make it worthwhile for a formal proposal to be submitted?" 9-yes, 0-no.]
[Post-Oxford: Dave reports there are no plans to continue with this proposal due to lack of time/interest on his part. He says that the need is "definitely not redundant or replaced. If someone else cares enough, they should propose it."]
Section: 20.3 Status: TR Submitter: Douglas
Gregor Date: 9 Apr 2002
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference:
www.boost.org/libs/function/index.html
Formal Proposal:
Revised: N1402/02-0060
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1402.html,
Original: N1375/02-0033
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1375.html
[N1402 was accepted at the Santa Cruz meeting.]
Section: Status: TR Submitter: Peter
Dimov, Doug Gregor, Jakko Järvi, Gary Powell Date: 16 Apr 2002
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference: www.boost.org/libs/bind/bind.html
Formal Proposal: Revised: N1455/03-0037
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1455.htm
Original: N1438/03-0020
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1438.htm
[N1455 was accepted at the Oxford meeting.]
Section: ? Status: Open Submitter: John
Bandela Date: 16 Apr 2002
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference:
www.boost.org/libs/tokenizer/index.htm
Formal Proposal:
The tokenizer
class template provides a container
view of a series of tokens contained in a sequence. The sequence to parse and
the TokenizerFunction which performs the parse are supplied either upon
construction or via the assign member function.
The tokenizer
class template provides a flexible
and easy way to break of a string or other character sequence into a series of
tokens. For example, to break a phrase into words.
string s = "This is, a test"; tokenizer<> tok(s); for(tokenizer<>::iterator beg=tok.begin(); beg!=tok.end();++beg) { cout << *beg << "\n"; }
TokenizerFunctions escaped_list_separator
,
offset_separator
, and char_delmiters_separator
are provided
as part of the proposal.
The proposal falls in the filling gaps category identified in 01-0028/N1314 as a target for the TR, and eliminates the need to use std::strtok, with its associated problem of global state.
[Curaçao: Jeremy Siek briefly presented the proposal.
Ichiro Koshida asked if tokenizer can handle multibyte character strings. The tentative answer is "yes"; a request has been made for test cases to verify that assertion.
There was a question as to performance compared to strtok().
Straw vote: "Is the LWG interested enough to make it worthwhile for a formal proposal to be submitted?" 10-yes, 0-no.]
[Post-Curaçao: John Bandela reports raw strtok calls are typically four times faster than raw tokenizer calls, while a strtok based application (copying the tokens to a vector) is typically twice as fast as the same code using tokenizer. Results vary a lot from compiler to compiler.]
Section: ? Status: TR Submitter: Jaakko
Järvi Date: 16 Apr 2002
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference:
www.boost.org/libs/tuple/doc/tuple_users_guide.html
Formal Proposal:
Revised: N1403 std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1403.pdf,
Original: N1382
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1382.pdf
[N1403 was accepted at the Santa Cruz meeting.]
Section: 27.8 Status: Hold Submitter: Beman
Dawes Date:
15 Apr 2002
Type: Impure Requires: Std C++
Existing-practice: None Implementation: No
Reference:
Formal Proposal:
The I/O functions identified below have signatures taking filename arguments
s
as const char*
. This is most inconvenient for modern
C++ programs working with filenames as std::strings, and is a constant source of
compile time errors. Although the fix is trivial (adding a call to
std::string::c_str()
), it irritates users that the standard library
doesn't provide for this common usage.
This problem was originally identified in library issue 105 from AFNOR.
Note that this proposal does not include std::wstring
overloads. Discussion on the library reflector indicates such overloads would be
extremely controversial, because there are no agreed upon semantics for the
common case where the underlying operating system has no concept of wide
character filenames.
Proposal:
To the member functions identified below, add a signature taking a
const std::string& s
, with effects defined as a call to the current
function, with an s
argument of s
.c_str()
.
[lib.filebuf] <IP_ADDRESS> Template class basic_filebuf
[lib.filebuf.members] <IP_ADDRESS> Member functions
basic_filebuf open()
[lib.ifstream] <IP_ADDRESS> Template class basic_ifstream
[lib.ifstream.cons] <IP_ADDRESS> basic_ifstream constructors
[lib.ifstream.members] <IP_ADDRESS> Member functions
basic_ifstream constructor
basic_ifstream open()
[lib.ofstream] <IP_ADDRESS> Template class basic_ofstream
[lib.ofstream.cons] <IP_ADDRESS> basic_ofstream constructors
[lib.ofstream.members] <IP_ADDRESS> Member functions
basic_ofstream constructor
basic_ofstream open()
[lib.fstream] <IP_ADDRESS> Template class basic_fstream
[lib.fstream.cons] <IP_ADDRESS> basic_fstream constructors
[lib.fstream.members] <IP_ADDRESS> Member functions
basic_fstream constructor
basic_fstream open()
[depr.ios.members] D.6 Old iostreams members
Three places; no change proposed.
[Curaçao: Beman briefly presented the proposal.
There was discussion of various options for semantics for interpreting
argument
const std::string& s
:
1) s.c_str()
2) Treat s as multibyte character string if supported by operating system, else s.c_str().
3) Also provide std::wstring overload.
4) Generalize as a template< typename S > where s of type S must support s.c_str() returning a type convertible to const char *.
There was no support for options (3) and (4) because no one has been able to propose reasonable semantics. These options are listed here only as a record of discussion; they are dead-on-arrival without semantics applicable to all platforms.
Ichiro Koshida raised the question of multibyte character strings; the LWG was supportive of the intent but must consult I/O experts as to whether this is possible or makes sense.
Straw vote: "Is the LWG interested enough to make it worthwhile for a formal proposal to be submitted?" lots-yes, 0-no.]
[Pre-Santa Cruz: This proposal is on hold, pending the outcome of a couple of related projects:
[Santa Cruz: Although no formal vote was taken, there was considerable support in the LWG for not making piecemeal changes to existing Standard Library components in the first Library TR. Thus the proposal remains on hold.]
Section: ?? Status: Open Submitter:
Jeff Garland Date: 22 Sep 2002
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference:
www.boost.org/libs/date_time/index.html
Formal Proposal:
This proposal includes classes and functions for the manipulation of dates and times. The library separates the domain into the following concepts:
This separation of concerns allows the library to support consistent extensions for different date-time systems. In addition to the type representing the domain concepts, the library builds on these concepts by providing programming aids such as iterators and algorithms useful for building date and time applications.
The current library provides an implementation of a concrete date system based on the ISO 8601 standard calendar system with a date range extending back to 1400 A.D. Some of the key classes include: date, date_duration, date_period, day_clock, and gregorian_calendar. For time programming the library offers a non-adjusted counted time system. Some of the key classes include: ptime(posix time), time_duration, time_period, and others.
The manipulation of dates and times is an extremely common problem in building applications. Many date-time libraries are available and are utilized widely by C++ programmers.
This proposal would benefit from the adoption of a 64-bit integer type.
The proposal falls in the filling gaps category identified in 01-0028/N1314 as a target for the TR.
[Santa Cruz: Jeff Garland presented the Date Time library to the LWG. There was considerable interest, and Jeff was asked to submit a formal proposal. In addition to the current Boost components, civil time was of interest to LWG members.]
[Pre-Oxford: A formal proposal is still planned; no target date has been set yet.]
Section: ? Status: TR Submitter:
Walter E. Brown Date: 24 Feb 2003
Type: ? Requires: ?
Existing-practice: ? Implementation: ?
Reference:
Formal Proposal: N1422/03-0004
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1422.html
[N1422 was accepted at the Oxford meeting.]
Section: 20.3 Status: TR Submitter:
Peter Dimov Date: 28 Feb 2003
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference:
www.boost.org/libs/mem_fn/
Formal Proposal: N1432/03-0014
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1432.html
[N1432 was accepted at the Oxford meeting.]
Section: 20.3 Status: TR Submitter:
Douglas Gregor Date: 28 Feb 2003
Type: Pure Requires: Std C++
Existing-practice: Boost Implementation: Yes
Reference:
www.boost.org/libs/bind/ref.html
Formal Proposal: Revised: N1453/03-0035
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1453.htm
Original: N1436/03-0018
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1436.htm
[N1453 was accepted at the Oxford meeting.]
Section: 20.3 Status: TR Submitter:
Douglas Gregor Date: 27 Feb 2003
Type: Pure Requires: Std C++
Existing-practice: Yes Implementation: Yes
Reference:
www.boost.org/libs/lambda/,
spirit.sourceforge.net/index.php?doc=docs/phoenix v1 0/index.html.
Formal Proposal: Revised: N1454/03-0036
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1454.htm
Original: N1437/03-0019
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1437.htm
[N1454 was accepted at the Oxford meeting.]
Section: 23 Status: New Submitter:
Alisdair Meredith Date: 25 Apr 2003
Type: Pure Requires: Std C++
Existing-practice: Yes Implementation: Yes
Reference:
www.boost.org/libs/array
Formal Proposal: N1479/03-0062
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1479.htm
This is Nicolai Josuttis' Boost version of the fixed-size array wrapper described by Bjarne Stroustrup, Matt Austern, and Nicolai Josuttis in their respective books.
[N1479 is promised for the post-Oxford mailing]
Section: 24 Status: New Submitter:
Jeremy Siek Date: 25 Apr 2003
Type: ? Requires: Std C++
Existing-practice: ? Implementation: ?
Reference:
Formal Proposal: N1477/03-0060
std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1477.html
Also see [9] Iterator adaptors proposal.
[N1477 is promised for the post-Oxford mailing]
Revised April 25, 2003
--- End ---


{% extends "base.html" %} {% block title %}
Medieval catalogues > SECULAR INSTITUTIONS: Secular Colleges > Winchester College > Inventory of the library, 30 July 1428 × 24 August 1429
{% endif %}83 identified entries found.
All data was derived from the List of Identifications by Professor Richard Sharpe.
{% if not printing %}
A key to codes used in the List is available (opens in new tab).{% endif %}


Lesson
0 .Creating a scene with bare javascript
1 .A cube with an axis
2 .A Scene with rotating items - bare javascript
3 .A Scene with rotating real 3d objects - bare javascript
4 .Using geometry shape ThreeJS


{% extends "horizon/common/_modal_form.html" %} {% load i18n %} {% block modal-body-right %}
{% trans "Add an allowed address pair for this port. This will allow multiple MAC/IP address (range) pairs to pass through this port."%}


Stars attend 'The Mandalorian' premiere in LA(26 images) The cast arrives for the premiere of Disney+'s "The Mandalorian" at the El Capitan Theatre in Los Angeles, Calif., on Wednesday. 14 Nov 2019, 14:07 Pedro Pascal. Photo by Chris Chew/UPI | License Photo Director and actress Bryce Dallas Howard. Photo by Chris Chew/UPI | License Photo Ming-Na Wen. Photo by Chris Chew/UPI | License Photo Showrunner and executive producer Jon Favreau. Photo by Chris Chew/UPI | License Photo Director Deborah Chow. Photo by Chris Chew/UPI | License Photo Andre Meadows. Photo by Chris Chew/UPI | License Photo Seth Green. Photo by Chris Chew/UPI | License Photo Sofia Wylie. Photo by Chris Chew/UPI | License Photo Executive producer and director Dave Filoni. Photo by Chris Chew/UPI | License Photo Director Rick Famuyiwa (R) and his wife Glenita Mosley. Photo by Chris Chew/UPI | License Photo Editor Borja Luzuriaga (L) and his wife Lana Holmes. Photo by Chris Chew/UPI | License Photo Influencer Mari Takahashi (R) and husband Peter Kitch. Photo by Chris Chew/UPI | License Photo Tait Fletcher (R) and guest. Photo by Chris Chew/UPI | License Photo Casting director Sarah Finn. Photo by Chris Chew/UPI | License Photo "The Mandalorian" marquee. Photo by Chris Chew/UPI | License Photo Gina Carano. Photo by Chris Chew/UPI | License Photo Director Werner Herzog (R) and his wife Lena Herzog. Photo by Chris Chew/UPI | License Photo Herzog. Photo by Chris Chew/UPI | License Photo Carl Weathers (R) and Christine Kludjian. Photo by Chris Chew/UPI | License Photo Aidan Bertola. Photo by Chris Chew/UPI | License Photo Emily Swallow. Photo by Chris Chew/UPI | License Photo Omid Abtahi (L) and guest. Photo by Chris Chew/UPI | License Photo Executive producer Kathleen Kennedy. Photo by Chris Chew/UPI | License Photo Composer Ludwig Goransson (R) and his wife, violinist Serena McKinney. Photo by Chris Chew/UPI | License Photo Brian Posehn (L) and guest. Photo by Chris Chew/UPI | License Photo Julia Jones. Photo by Chris Chew/UPI | License Photo


This application requires Javascript which is used to make your web browser more interactive. If this message does not go away, please consider enabling Javascript. Here are instructions on how to enable JavaScript in your web browser.
Small loan data for Minnesota provided by Minnesota Department of Commerce.


WQMY
St John house rentals in the US Virgin Islands many choices for your ...
St. John House Rentals has it. We offer rental homes and villas, affordable island cottages and condominiums in one of the prettiest places in the Caribbean; St.
http://stjohnhouserentals.com/
| petosky by the bay festival michigan/butler creek hot lips loader ebay/ facts on sir francis drake |
|
|---|---|
| bessmer michigan 146.76 repeater | Williamsport |
| Branding | MyNetworkTV gecko house st john |
| t o k hot | remote codes for vcr dvd combo: 29 (adair county kentucky court dockets) & discounted cheap domestic airfare-DT 45.3 (UHF) |
| comercial premises and surrey | see article |
| Owner | New Age Media, LLC All about St. John, USVI, vacation, house rentals, wedding ... |
| First air date | December 30, 1988 |
| photos 50 calaber rifle wind runner | MYNetworkTV |
| good eats power bars | WOLF-TV, prestige motors long island city |
| forms of phosphorus stormwater | WILF (1988-2006) |
| Former channel number(s) | Gecko House Saint Croix Inns |
| ristes 2010 phpbb group | lease apartment bordeaux france (1988-1998) low carb alcoholic beverages / dirty shadows in art (1998-2006) |
| bt yahoo premium mail | 50 la graciosa lanzarote photos 420 kW (WOLF-DT3) |
| trnsmission adpaters for plymouth 218 motor | 243 m 488 m (WOLF-DT3) |
| humminbird 383c lowest price | 52075 73375 (WOLF-DT3) |
| Transmitter coordinates | utah murray edger dealers bankruptcy david hunt jersey new (WOLF-DT3) |
Apartments & Condominiums on St. John, USVI - StJohnUSVI.Com
Gecko House Fish Bay St. John, U S Virgin Islands 00831. Artist owned retreat, very quiet, beautiful views. This charming house is surrounded with tropical .
http://www.stjohnusvi.com/condos.html
St. John Gecko House a St John Virgin Island rental cottage
Gecko House is a Fish Bay, St. John rental cottage.
http://stjohnhouserentals.com/Gecko-House.htm
Fish Bay Vacation Rental - VRBO 102069 - 1 BR USVI - St. John ...
Location: Fish Bay, USVI - St. John, Caribbean (3 miles from Cruz Bay ) View Map. Accommodations: Cottage, 1 Bedroom, 1 Bath (Sleeps 2). Gecko House is .
http://www.vrbo.com/102069
Contents |
[hi speed trolling gulf] History
1 Bedroom Cottage Rental in Fish Bay, Saint John - Gecko House, a ...
Dec 11, 2012 . Rent Gecko House, a romantic cottage with ocean views! from Andrea Leland Vacation Rentals: See large photos, guest reviews and find great .
http://www.flipkey.com/fish-bay-cottage-rentals/p314164/
Soul Island Villa - About
We have been visiting St. John for about 20 years and this vacation house is . and goats wandering free and right at Soul Island Villa you can see deer, geckos, .
http://www.soulislandvilla.com/about.html
Gecko House: St. John US Virgin Islands Rental
Welcome to Gecko House, Walk to the Beach from your Private Retreat! --- Located in lovely St. John, in the US Virgin Islands, you'll love this eco-friendly, .
http://stjohngeckohouse.com/
Gecko House (St. John, U.S. Virgin Islands) - Guest house Reviews ...
Gecko House, St. John: See 15 traveler reviews, 10 candid photos, and great deals for Gecko House, ranked #5 of 8 B&Bs / inns in St. John and rated 4.5 of 5 at .
http://www.tripadvisor.com/Hotel_Review-g147409-d1101344-Reviews-Gecko_House-St_John_U_S_Virgin_Islands.html
Information Chart - St John House Rentals
Offering St. John, Virgin Island accommodations, house rentals .
http://stjohnhouserentals.com/information-chart.htm
GECKO HOUSE, St. John, US Virgin Island | Facebook
GECKO HOUSE, St. John, US Virgin Island. 68 likes · 0 talking about this.
http://www.facebook.com/stjohngeckohouse
Accommodations - ST John Rental
Fish Bay, St. John. Located in peaceful Fish Bay on the islands' south shore, this secluded & romantic retreat is cool, comfortable, and eco-friendly. Gecko House .
http://www.stjohnessence.com/accommodations.html
St. John again? 1 bedroom house? | Caribbean Islands Forum ...
Soryy, don't know any "1 bedroom" cottages" on St. John but suggest you look at Gallows Point Resort; Estate Lindholm or Gecko House - they .
http://www.fodors.com/community/caribbean-islands/st-john-again-1-bedroom-house.cfm
Private Vacation Home Rental St. John U.S. Virgin Islands
St. John Vacations, vacation rentals, rental properties, Vacation homes, Caribbean . The house sits on a promontory of land within the National Park boundaries, . We enjoyed the donkeys, chickens, goats, geckos, iguanas, and bannaquits.
http://www.windspree.com/home.php/2/Estate%20Fortsberg%20
Gecko Moon Restaurant - Port St Johns Restaurants
Voted top eating spot in Port St Johns, Gecko Moon Restaurant transports the palate on a culinary retreat in a tropical . The guest house is situated in Port St J. .
http://www.safarinow.com/destinations/port-st-johns/Restaurants/Gecko-Moon-Restaurant.aspx
USVI St. John Rental Villa Blue Tang Guest Comments
The home is beautiful, the views are magnificent. Your veranda is . The gecko that lives behind the TV set is fast! See if you can . St. John is the best island in the Caribbean and you're lucky to have such a beautiful place in it. Ed and Martha .
http://www.bluetang.vi/guest_book.htm
[zarelli carson street pittsburgh pa] Digital channels
| Channel | Name | tobacco regulation june 2009 msnbc | time off request update | Programming |
|---|---|---|---|---|
| 53.1 | gecko house st john DT | utah murray edger dealers | remote codes for vcr dvd combo | Main gecko house st john programming / MyNetworkTV |
| 53.2 | WOLF DT | triple flex nature made | bed n breackfast hove brighton | Simulcast of winnipeg free press birth announcements |
| 53.3 | WSWB DT | 480i | 4:3 | Simulcast of marine i love you |
St. John USVI Vacation Villa - Gecko House - Arts Opportunities
St. John USVI vacation villa - private artist's retreat, only 10 minutes from Cruz .
http://stjohngeckohouse.com/artsopps.shtml
[s t o p organization] References
[fiction books on cancer] External links
- what's my budda made of
- food burn in mouth
- iron condor option defined
- zinc how many protons
- oreo and black stools
- dairy goats and willow run
|
|